32nd IEEE Conference on Local Computer Networks
Sender Access Control in IP Multicast Salekul Islam
J. William Atwood
Department of Computer Science and Software Engineering Concordia University, Montreal, Quebec, Canada Email: {salek is, bill}@cse.concordia.ca
that hole is lack of access control over the multicast groups. This is caused by the classical “anyone can send, anyone can receive” model that is defined for IP multicast. This is preventing the Network Service Providers and the Content Providers (CP) from generating revenue by supporting multicast based applications. Access control is used in this paper to mean authentication, authorization and accounting (AAA functionalities) of both sender(s) and receivers of a multicast group. AAA protocols [3] are being used very successfully to ensure revenue generation in unicast communication, by controlling access to network resources. AAA protocols can be used for multicast based applications, to authenticate the users, to authorize them and to account their group activity. We have already designed an overall architecture for secure and accountable multicasting [4]. We have specified how to deploy AAA protocols for receiver access control in IP multicast [5]. We have also developed the Internet Group Management Protocol with Access Control (IGMP-AC) [6], an extended version of IGMPv3 [7]. In this paper, we have broadened the scope by adding sender access control to our architecture. The rest of the paper is organized as follows: section 2 defines the requirements of our architecture that we have proposed, section 3 briefly presents the existing methods and their limitations, section 4 presents the proposed architecture for intra-domain multicast group in detail, section 5 extends the architecture for inter-domain group, section 6 explains different benefits of the proposed architecture and finally, section 6 will be the conclusion and the work that we have planned to accomplish in future.
Abstract—Multicasting has not been widely adopted until now, due to lack of access control over the group members. The Authentication, Authorization and Accounting (AAA) protocols are being used successfully, in unicast communication scenarios, to control access to network resources. AAA protocols can be used for multicast applications in a similar way. However, without an effective sender access control, an adversary may exploit the existing IP multicast model, where a sender can send multicast data without prior authentication and authorization. Even a group key management protocol that efficiently distributes the encryption and the authentication keys to the receivers will not be able to prevent an adversary from spoofing the sender address and hence, flooding the data distribution tree. This can create an efficient Denial of Service attack. In previous work, we have proposed a framework for the use of AAA protocols to manage IP Multicast group membership. To prevent DoS attacks and other known attacks (e.g., replay attack), we propose in this paper an extension for sender access control. Our solution will authenticate and authorize each sender, and account for sender behavior by deploying AAA protocols. Moreover, a multicast packet will be forwarded to the distribution tree only if it is cryptographically authenticated at the entry point by the Access Router. The proposal we have presented provides a flexible authentication framework, supporting different authentication mechanisms, and is independent of the underlying routing protocol. Finally, we have extended our model to support inter-domain multicast groups.
I. I NTRODUCTION IP multicast, with all its advantages, is not widely deployed yet, although it was standardized by the IETF many years ago [1]. A growing number of applications, from different categories, can benefit from the use of multicast. Multimedia conferencing, distance learning, multi-player games, news headlines, stock quotes, weather updates, etc., are common applications that rely on one-to-many or many-to-many communications [2]. Streaming video to hundreds or thousands of listeners is a newer application where the Network Service Provider (NSP) can achieve very large savings in resource requirements through the use of multicast data distribution. However, to ensure the generation of revenue from such a data stream, the data must be encrypted, to ensure that they are only received by legitimate customers. There are two orthogonal planes to be considered when securing multicast traffic: the data plane and the control plane. Data plane security protects multicast data whereas control plane security involves multicast routing messages. However, it is evident that in spite of significant progress in these two areas, large scale deployment of multicast has not materialized yet. This fact suggests the existence of a hole in the security of multicasting, and
0742-1303/07 $25.00 © 2007 IEEE DOI 10.1109/LCN.2007.53
II. R EQUIREMENTS OF OUR DESIGN Our goal is to develop a generic architecture with minimum overhead. For better understanding of our work, we clarify some definitions that we have used in this paper. In [6], we have introduced the notion of two types of multicast groups: open group, to/from which data can be sent/received any time, and secured group, to/from which only authenticated and authorized member(s) can send/receive data. On the other hand, a multicast group can be classified according to the distribution of its group members (both sender(s) and receivers). In an intra-domain group, all the members reside inside a single domain or Autonomous System (AS), whereas an inter-domain group consists of members distributed among more than one domain or AS. We have defined the following requirements that our proposed architecture should meet:
79
•
•
•
•
•
•
•
•
other attack due to its amplification of data packets enroute. The best way to prevent such an attack is to establish a checkpoint at the entry point or Access Router (AR) of a DDT while the Core Routers (CR) are being trusted. In the literature, only a few attempts have been found to provide sender access control ([11]–[14]). The first two methods ([11] and [12]) had design goals similar to the architecture presented in this paper. The later two methods ([13] and [14]) attempted to solve the sender access control by controlling the construction of DDT of a multicast group only for authenticated/authorized senders. In [11], Ballardie and Crowcroft first defined the sender (and receiver) access control mechanism for CBT, where an Authentication Server (AuthS) authenticates each member and supplies an Authorization Stamp for successful authentication. A sender includes this stamp in each multicast packet and digitally signs the packet. A control router from DDT will forward these signed packet to the AuthS to check the sender identity. The AuthS also adds a lifetime to each Authorization Stamp to prevent replay attack. Ishikawa et al. [12] deployed AAA architecture to authenticate each user (sender and receiver). They proposed a challenge-response protocol with shared secret for sender authentication. In this model, a host willing to send data should communicate with the nearest ingress router, which will start a challenge-response session with the sender. The ingress router collects authentication information and forwards it to a backend AAA Server (AAAS) to perform the actual authentication. Shiels and Garcia-Luna-Aceves [13] designed the Keyed Hierarchical Multicast Routing Protocol (KHIP), an extension of the Hierarchical Multicast Routing Protocol, which protects the multicast routing protocol from untrusted routers and provides sender and receiver access control as well. KHIP authenticates and authorizes hosts and trusted routers, and distributes encryption keys. In each sub-branch of the DDT, a packet is processed by the root router of the sub-branch, which will introduce delay in delivering data and high deployment cost. The model burdens the Designated Routers (DR) and the CRs with multiple processing of digital signatures for hosts’ subscriptions, and hence, is vulnerable to possible DoS attack [15]. Wang and Pavlou [14] developed a scalable sender access control policy mechanism for bi-directional shared trees to check and discard unauthorized data when it arrives at an ontree router. All senders must register with the core first. When an on-tree router forwards a registration message to the core, it adds the downstream sender address to its local Sender Access Control List (SACL). On receiving a registration message, the core contacts a Source Authorization Server (SAS) for deciding whether to accept the new sender. If the join is approved by the SAS, the core will send back to the sender an activating packet, which will activate the previously added sender address in the SACL of each on-tree router. A data packet will be forwarded to the upstream interface if it comes from a sender address having an entry in the SACL and if the packet comes from the same interface as the one recorded in the entry.
We must authenticate and authorize a sender before allowing him/her to send data to the data distribution tree (DDT) of a secured group. Depending on the business model and the relationship between an NSP and a CP, accounting may also be required. For example, a CP may lease the resource of an NSP for a period of time or a maximum amount of data. Authentication of a sender should be optional so that the architecture will support open groups that operate following the classical IP multicast model. Security never comes free of cost, and is not even required sometimes. The required level of security depends on the specific application, the value of the information being delivered, available hardware and software resources, etc. The proposed model should be able to provide a wide range of authentication mechanisms from simple password to asymmetric keys (digital signature). An adversary, acting the role of a true sender, is able to mount a replay attack or sender address spoofing with little effort. These two attacks eventually become a Denial of Service (DoS) attack. We have to implement per-packet cryptographic protection to develop a solution that is free from these three attacks and other known attacks. The most appealing features of multicast are simplicity and bandwidth conservation. We should not overload the DDT routers or the hosts, and the key concern must be to deliver a packet as fast as possible in a secured way. The architecture will be independent of the underlying routing protocol. For example, the way the DDT is constructed by the routing protocol will not affect our solution, multicast data may be distributed through either a unidirectional (e.g, in case of PIM-SM [8]) or a bidirectional (e.g., in case of CBT [9]) tree. The proposed model should not be restricted to intradomain groups, and should be practicable for interdomain groups as well. Finally, both Source-Specific Multicast (SSM) and AnySource Multicast (ASM) groups should work in our architecture. III. R ELATED WORK AND THEIR LIMITATIONS
Sender access control is different from source authentication or data origin authentication. Source authentication allows a receiver to validate the identity of the source, i.e., to confirm that a received packet is coming from a source that belongs to the same multicast group to which the receiver has joined. A number of group key management protocols (e.g., [10]), which provide source authentication with great variety, have been developed for multicast applications. However, we cannot prevent an adversary from spoofing a legitimate sender address and sending bogus packets to flood the DDT. Thus, the DoS attack even exists with the presence of a secured group key management protocol. A DoS attack is one of the strong attacks that it is not possible to completely eliminate. However, we can take different prevention steps to minimize this attack. Multicast suffers from DoS attack more severely than any
80
TABLE I S UMMARY OF EXISTING METHODS WITH RESPECT TO REQUIRED PROPERTIES
Method Auth. Stamp
AAA Authentication functions mechanism Authentication Digital signature Authorization
Possible attacks
Overhead
DoS attack at control router
High—control router forwards each packet to AuthS Low—between host and ingress router
Challenge- Authentication Challengeresponse Authorization response using password KHIP Authentication Digital signature Authorization + encryption
Dictionary attack, source address spoofing DoS attack at DRs and core
SACL
Replay attack, source address spoofing
Authorization
No explicit authentication
High—each subbranch root decrypts and re-encrypts data Medium—multiple routers on DDT check SACL
Routing protocol CBT
Intra/interdomain Both
Any protocol
Intradomain
CBT, OCBT
Both
Any bi- Both directional
A. Threat model and assumption
However, a data packet coming from the upstream interface will always be forwarded to the downstream interfaces with group state without performing any verification. In Table I, we have summarized how these four methods fulfill different requirements mentioned in the last section. None of them provides accounting and meets all the requirements. They have other limitations such as being confined to a specific authentication mechanism, dependency on the routing protocol, not free from different attacks and slow packet delivery due to processing of authentication information in many places. Hence, it is clear that a sender access control framework is needed, which will satisfy the requirements we have identified.
In our model, we are assuming that a host can be compromised while a router is a trusted entity. Thus, a compromised host may capture, modify and replay any data packet inside a subnet. The proposed architecture must defend against such attacks. A router is usually less vulnerable to attack and expected to behave correctly. This is a reasonable assumption for an intra-domain group, as it is expected that the network administrators have better control over the routers and will be able to detect a compromised router more quickly than a compromised host. However, for an inter-domain group, perpacket protection is not guaranteed by this assumption. We have to believe that the upstream routers of an adjacent domain are trusted. Thus, we are depending on the trusted behavior of some entities, which are maintained by other administrators. When we present the inter-domain architecture in section V, we will show two different architectures. The first one depends on this assumption and the other assumes that both hosts and routers can be compromised.
IV. P ROPOSED ARCHITECTURE The problem to add sender access control by deploying AAA protocols is not trivial. It is distributed in nature and composed of different entities and protocols. The AAA framework has two components: AAAS and Network Access Server (NAS). AAA is a client-server protocol, where a NAS acts as a client and communicates with the AAAS using one of the AAA protocols. The AAAS—multiple servers can be used for resiliency—is attached to the network and it serves as a central repository for storing and distributing AAA information. The NAS acts as the point of entry into the network, and contains an AAA client. The NAS collects authentication data of a user and forwards these data to the AAAS, which checks its database and returns an “accept” or “reject” in response. The architecture we have developed is shown in Figure 1. The Content Server (CS) will reside in the CP, which will send multicast data through its nearest AR. The CR will construct the DDT using one of the multicast routing protocols. A receiver will join a secured group using the IGMP-AC [6] protocol and his/her nearest AR will extend the DDT up to that AR. Thus, multicast data will reach from a sender to multiple receivers by traveling multiple hops of the DDT.
B. Role of different entities A successful sender access control requires interactions of three entities: a host or sender, the closest AR to the sender and the AAAS. This AR is commonly known as DR and will act as the NAS. With the help of an AAAS, it will authenticate and authorize a sender. It is important to clarify that the AR will perform access control only if the sender wants to send data to a secured group. The architecture shown in Figure 1 works for an intradomain multicast group only. This is a restricted assumption, and in reality, the receivers may be distributed in different domains or ASes. An architecture is always dependent on the specific business model and the trust relation between the CP and the NSP. We will extend the intra-domain architecture in section V for inter-domain multicast groups. An AR will maintain a list consisting of three items: sender or host address, multicast group address and type of the group
81
Sender
of data). The AR will communicate with the AAAS using the Diameter [16] protocol. The construction of the Diameter messages is out of the scope of this paper. Note that all data in Diameter messages are delivered in the form of Attribute Value Pairs (AVP), and it is possible to extend the Diameter protocol by defining new Attribute Value Pairs. If the AR receives a non-empty multicast data packet (destined to a secured group) from a sender, who is not authenticated yet, the AR can either silently discard the packet or start a security protocol session to authenticate the sender. Once the sender is authenticated by the AAAS, an authentication key will be established between the sender and the AR to accomplish per-packet cryptographic protection. The sender must send authentication information with all multicast packets, which will aid the AR to authenticate each packet before forwarding it to the DDT. This authentication key will be maintained by the sender and the AR as long as the sender has authorization to send data.
CP CS
AAA protocol
Data sent through SA
AR / NAS
NSP Sender AAAS Database
CR
CR
AR / NAS
IGMP-AC
C. Authentication protocol
End Users
Fig. 1.
One of our design goals is to develop a flexible authentication framework to support various authentication mechanisms. Hence, the administrator of the network will have freedom to pick the appropriate authentication mechanism. The Extensible Authentication Protocol (EAP) [17] will be a good choice for this purpose. 1) Extensible Authentication Protocol (EAP): EAP is an authentication framework to provide some common functions and a negotiation of the desired authentication mechanism, which is called an EAP method. EAP runs between an authenticator and a peer. The authenticator may act as a passthrough, with a backend authentication server (or EAP server) connected with the authenticator. The actual authentication will be performed by the backend server. The pass-through authenticator is nothing but a NAS and the backend server is an AAAS. In such an environment, EAP will be used by the sender (or host) and the NAS (or AR), and the Diameter-EAP [18] protocol will be used by the NAS and the AAAS. EAP has not been developed for a specific authentication mechanism. There are currently about 40 different EAP methods. Although EAP is standardized in RFC 3748 [17], it only supports MD5-Challenge, One-Time Password (OTP) and Generic Token Card (GTC) based authentications. All these methods are commonly known as “legacy methods”. These methods have some shortcomings: support for one way authentication only, no key derivation is possible, vulnerable to some known attacks, etc. To satisfy present needs, a number of EAP methods have been developed, which have better security properties and provide more flexibility. Each EAP method defines its own messages, which are sent inside EAP packets. However, EAP does not run directly over the IP layer, and a EAP lower-layer is required. The IETF is in the process of standardizing the Protocol for Carrying Authentication for Network Access (PANA) [19], a network access authentication protocol that works as an EAP lowerlayer. PANA carries EAP authentication methods encapsulated
Proposed architecture
(secured or open). When the AR receives multicast data from a host that has no entry in the list, the AR will communicate with the AAAS to update the list. If the group is a closed (secure) group, the AR will proceed as described below. If the group is an open group, then given that there is no restriction on sending data to a open group, a sender will send data to such a group as soon as a data packet is generated destined to such a group. On receiving a data packet for a open group, the AR will follow its local policy and thus, either forward the packet or discard it (e.g., in case there is no entry in the routing table to reach the destination group address). Unlike the case for receivers, where IGMP is used to explicitly join a multicast group, a sender does not go through any joining process. However, if we had any protocol like IGMP for multicast senders, we could have better control over the senders. Unfortunately, the IETF has not standardized any such protocol. We have formulated a simple mechanism to solve this problem. A sender should send an empty packet (without data field) to the AR with destination address of the secured group that it intends to send to. This empty packet will trigger a security protocol session between the AR and the sender. Through this session, the sender will send its authentication information to the AR, which will be forwarded to the AAAS. The AAAS will authenticate the sender and for successful authentication, relevant authorization and accounting information will be sent to the AR along with the authentication result. The content of the authorization information depends on a specific application. For example, it may be the duration of time up to which the sender is allowed to send data to a multicast group. The accounting information will provide direction for the AR, how it will keep track of the sender behavior (e.g., the duration of time or the amount
82
PaC
PANA
PAA
RADIUS/ Diameter
Sender / PaC
AS
AAA Server
EAP method
AR / PAA / EP
EAP peer
IKE
EP
Fig. 2.
SNMP / API
EAP layer
PANA framework
EAP peer
EAP Auth
EAP method
EAP Auth
EAP Auth
PANA
EAP layer
EAP layer
EAP layer
UDP / IP
PANA / UDP / IP
AAA / IP
AAA / IP
PANA (EAP)
Diameter / Radius
IKEv2
inside EAP packets between a client node and a server in the access network. 2) PANA framework: The PANA framework [20], comprised of four functional entities, is shown in Figure 2. The PANA Client (PaC) resides on a requesting node, such as an end host, laptop, PDA, desktop PC, etc., and it is connected to a network via a wired or wireless interface. It interacts with the PANA Authentication Agent (PAA) in the authentication process using the PANA protocol [19]. The server implementation of PANA is the PAA, which consults an Authentication Server (AS) for authentication and authorization of a PaC. The AS may reside in the same node as the PAA, or it may be a separate entity, in which case one of the AAA protocols (e.g., Diameter) will be used for their communication. The PAA resides on a node that is typically called a NAS in the access network. The AS is a conventional backend AAAS that terminates the EAP and the EAP methods. The Enforcement Point (EP) is the access control implementation that allows (blocks) data traffic of authorized (unauthorized) clients. An EP is updated with the attributes of the authorized clients from the PAA. When the PAA and EP reside on the same node, they use an API for communication, otherwise, a protocol (e.g., SNMP) is required. When the EP uses cryptographic (may use noncryptographic also) filters for allowing or blocking data packets from a client, a secure association protocol (e.g., IKEv2 [21]) is required to run between the PaC and the EP. If the desired security is to be established at the IP-layer, an IPsec Security Association (SA) [22] is established between these two entities [23]. Thus, per-packet cryptographic protection is possible, which may provide integrity protection, data origin authentication, replay protection and optional confidentiality protection. 3) Use of PANA in our model: The PANA framework exactly resembles our proposed architecture, and the functionalities PANA provides match the requirements we have identified in our design goal. How PANA will be accommodated in our architecture is shown in Figure 3. The host from which a sender is sending a multicast packet will be the PaC and the nearest AR to it will be the PAA. The AAAS will be the AS. Hence, when a sender will send an empty packet with the destination address of a secured group, a PANA session will start between the sender and the AR. PANA will add an extra layer between the UDP and EAP layers in the sender and the AR entities. There will be no PANA layer in the AAAS side, as it will communicate with the PAA using the Diameter-EAP protocol. Thus, PANA will
IPsec SA
Fig. 3.
PANA framework within proposed architecture
be terminated at the PAA and EAP will be terminated at the AAAS, and for authentication any EAP method can be used. We are also assuming that the EP is co-located with the PAA (or AR), and thus, an API is sufficient for their communication. A PANA session consists of five phases. In the following we have explained how the entities will behave in our architecture during these phases: 1) Handshake phase: The sender will send an empty multicast packet and will trigger a new PANA session. 2) Authentication and authorization phase: Immediately following the handshake phase, EAP packets, carrying EAP method messages, will be exchanged between the sender and the AR. The AR conveys the result of authentication and authorization to the sender at the end of this phase. 3) Access phase: After a successful authentication and authorization the sender is allowed to send multicast data through the EP or AR. The cryptographic protection will be performed by the EP in this phase. 4) Re-authentication phase: If re-authentication is required, this phase will trigger a EAP re-authentication, which turns back to access phase again upon successful reauthentication. 5) Termination phase: The sender or the AR may choose to discontinue the access service at any time. At the end of this phase, the AR will gather accounting data of the sender and communicate these data to the AAAS (using Diameter) for updating sender’s database. D. Per-packet cryptographic protection by IPsec SA A number of EAP methods provide mutual authentication and session key establishment between an EAP peer (sender) and an EAP server (AAAS). This key is known as AAA-Key or Master Secret Key (MSK) and can be exported to the PAA (or AR) using a AAA protocol [24]. In Figure 4, how different keys are generated using AAA-Key and how the IPsec SA is established between the sender and the AR are explained. In our model, the EP and the PAA reside inside the same entity, AR. A PAA may be connected with multiple EPs. On receiving the AAA-Key the PAA generates the PaC-EP-Master-Key for each EP. One way of calculating this key is,
83
Sender
AR
Sender/ PaC PANA (EAP)
Diameter (AAA-Key)
PaC-EPMaster-key
PaC-EP-Master-key API IKEv2
CS
Diameter-EAP
AAA-Key
IKE Preshared-Key
CP
AAAS
PAA
EP
NW1
IKE Pre-shared-Key
IKE Pre-shared-Key
BR1
IPsec SA
BR2
Fig. 4.
IPsec SA
AR
AAAKey
AAAS1
Sender database
BGP
IPsec SA establishment after PANA session NW2
PaC-EP-Master-Key = The first 64 octets of prf+(AAA-Key,"PaC-EP master key"|Session ID|Key-ID|EP-Device-Id).
AR
Here, “|” means concatenation of different fields and prf+ is a pseudo-random function defined in [21]. Session ID must be globally and eternally unique. It identifies a PANA session. Key-ID is an identifier of a specific AAA-Key. EP-Device-Id is an identifier of the EP, and it can be an IP address, a MAC address, or an identifier that may not be carried in data packets but has local significance in identifying a connected device. Next, the PAA generates the IKE-Pre-shared-Key using the following method, IKE-Pre-shared Key = HMAC-SHA-1 (PaCEP-Master-Key,"IKE-Pre-shared key"| Session ID|Key-ID|EP-address). Here, Key-ID identifies the PaC-EP-Master-Key within a given session and EP-address is the address of the EP that will participate in the IKE exchange. If the PAA controls multiple EPs, this provides a different pre-shared key for each of the EP. The PAA will communicate the IKE-Pre-shared-Key, Key-Id, the device identifier of the PaC, and the Session-Id to the EP using an API before the IKE exchange begins. The sender will also calculate the IKE-Pre-shared-Key in a similar way. At this moment, the sender and the EP will open an IKEv2 session for mutual authentication, and will eventually establish an IPsec SA, which will be used for per-packet cryptographic protection. Depending on the required security services (i.e., secrecy, integrity, authentication, replay protection, etc.) the appropriate SA protocol (i.e., ESP [25] or AH [26]) will be determined by the network administrator. It should be noted that none of the protocols — IPsec, EAP and PANA — is defined for multicast communication. However, although we have used them in sender access control and in protecting multicast data, they have been used only for unicast communications between two entities.
84
AAAS2
IGMP-AC
Host 1 Host 2 Host 3
Fig. 5.
Inter-domain architecture with limited security
V. I NTER - DOMAIN ARCHITECTURE An inter-domain multicast group is distributed over more than one domain, which makes it quite difficult to design a scalable sender access control solution. In Figure 5, we have shown a simple inter-domain architecture spanning two domains, NW1 and NW2. We have assumed that each domain has an AAAS, and the link between these two AAASes is secured. The sender S sending data to the group G is connected with NW1, while the receivers are connected with NW2. The two domains are linked by two Border Routers (BR), BR1 and BR2. The Border Gateway Protocol (BGP) [27] will be used by the BRs to build the forwarding table. The multicast routing protocol is assumed to work properly, and the DDT is being built by the CRs and the BRs. In Figure 5, the DDT will be distributed over the two domains. The shape of the tree will depend on the underlying routing protocol. For example, in an SSM [28] group, the DDT will be a shortest-path tree rooted at the source and the BRs will be the internal nodes of the DDT. We have designed two inter-domain architectures depending on the security services required and packet processing time at the BRs. We need a tradeoff between security and packet delivery time. The first inter-domain architecture, shown in Figure 5, will provide limited security services with fast packet delivery, while the second one, shown in Figure 6, will enforce per-packet cryptographic protection at the BRs in expense of slower packet delivery. A. Limited security services In this model, an ingress BR (a BR that forwards packets from other domain(s) to its own domain) will maintain a
Sender
similar list to the one the AR maintains in Figure 1, consisting of sender address, group address and group type (secured or open). In Figure 5, when the BR2 receives the first multicast packet from BR1 with (S, G), it will send a query to AAAS2 for (S, G, NW1). The AAAS2 will understand that it will have to communicate with the AAAS of NW1 (i.e., AAAS1) to confirm the existence of such a sender and secured group. AAAS1 will confirm the status of (S, G) and may also send authorization information (e.g., the period of time (S, G) exists) if this is a valid secured group and S has already been authenticated for this group. AAAS2 will update its own database and send this information to BR2. If this is a secured group and the sender S is certified as a valid sender, BR2 will follow the local policies and the existing Service Level Agreement (SLA) between NW1 and NW2. If S is not certified, BR2 will drop the packet and AAAS1 will send an alert message to the administrator of NW1 to inform it of the presence of an adversary inside the network. The architecture shown in Figure 5 is extensible for more than two domains. For example, if another domain, NW3 is connected (through BR3) with NW2, BR3 will contact AAAS3 (the AAAS of NW3) to verify the status of (S, G, NW2). AAAS3 will communicate with AAAS2, which has already updated its own database and thus, will be able to inform AAAS3 without communicating with AAAS1. Thus, the communication between two AAASes of adjacent domains will continue until a data packet has reached the final destination. The major advantage of this model is fast packet processing at the BRs, which is gained by the price of a less secure system. There is no per-packet protection at the BR of a domain. It is assumed that all the involved domains implement intra-domain sender access control. There is a chain of trust, which starts from the access control of sender’s domain.
CP
CS
IPsec SA
AR
AAAS1
NW1
Sender database SA tunnel
BR2
NW2
SA tunnel BR3
NW3 AR
IGMP-AC
Host 1 Host 2 Host 3
Fig. 6.
Inter-domain architecture with per-packet protection
adjacent domains’ routers. From Figure 6, it can be concluded that the number of established IPsec tunnels will be one less than the number of domains on the path from the sender to a receiver. Thus, the longer this distance is (in terms of number of domains) the longer the packet delivery time is.
B. Per-packet cryptographic protection The model we are explaining now is less susceptible to attack and is suitable for an application to which security is the prime concern. Obviously, it will increase packet processing time at the BR of a domain. In Figure 6, we have presented the key idea of this model and detailed description of it is assigned to our future study. In this example, three domains, NW1, NW2 and NW3 are connected. The sender is located in NW1 and the receivers are located in NW3. We are assuming that all domains have implemented the intra-domain sender access control mechanism. In addition to that, two IPsec SA tunnels will be established, one between the closest AR of the sender and BR2 (ingress router of NW2) and the other between BR2 and BR3 (ingress router of NW3). In case an intermediate domain has no receiver for a multicast group (e.g., NW2 in Figure 6), an IPsec tunnel will be established only if the domain had a prior SLA with its adjacent domain to forward data of that group. At this stage of our work, we have not finalized the establishment process of these tunnels. However, these tunnels will provide the desired per-packet protection at the entry point of each domain. More importantly, this model no longer depends on the trusted behavior of the
VI. B ENEFITS OF THE ARCHITECTURE Our goal was to develop a generic framework in terms of authentication mechanism, routing protocol, multicast group types, etc. The existing IP multicast model will benefit by adopting the proposed architecture by a number of ways. It fulfills all the requirements of our design goal, and also provides some additional advantages. We have summarized the contributions of our proposal in the following: 1) Provides AAA functionalities: Our sender access control architecture provides all three AAA functionalities, specially, this is the first model (to our knowledge) to support accounting for sender behavior in IP multicast. 2) Per-packet cryptographic protection: We have decoupled sender authentication and per-packet protection. However, only after successful sender authentication, per-packet protection will be implemented and a strong trust relation exists (through AAA-Key exportation) between sender authentication (EAP authentication) and IKEv2 authentication that establishes IPsec SA.
85
R EFERENCES
3) Minimum overhead and fast packet processing: Our model will only add a minimum workload to the AR of the sender side. The remaining routers of the DDT will still process a multicast packet without extra effort. We can further leverage the packet processing at the AR. When data are sent in encrypted format due to the deployment of a group key management protocol, IPsec SA with AH instead of ESP can be used. 4) Independent of routing protocol: On successful authentication of the first data packet, the AR will take necessary action (e.g., send the first unicast-encapsulated data packet to the RP in case of PIM-SM [8]) it would have taken without the presence of sender access control. Thus, the whole mechanism will remain transparent to the underlying routing protocol. 5) Serves both SSM and ASM groups: Although the list maintained by the AR and the query sent to the AAAS are (S, G) or source-specific type, there is no restriction for the address range of G. Thus, the model is applicable for both SSM and ASM groups. 6) Security services: Sender access control will prevent a number of attacks against the classical multicast model. • A forged packet produced by an adversary will be detected (through integrity protection of SA) and discarded at the AR, and will not be forwarded to the DDT. This will stop a non-member from sending data to a secured group, and therefore, DoS attack will be reduced significantly. • IPsec SA provides optional anti-replay by sliding window protocol. If an attacker stores a valid packet and replays it after a while, the anti-replay mechanism will detect and discard it. • IPsec AH considers all immutable fields of IP header (including the sender address) to calculate the cryptographic hash value, and thus, provides source address authentication. This will prevent the source address spoofing attack.
[1] S. Deering, Host Extensions for IP Multicasting, RFC 1112, August, 1989. [2] B. Quinn and K. Almeroth, IP Multicast Applications: Challenges and Solutions, RFC 3170, September 2001. [3] C. Metz, AAA Protocols: Authentication, Authorization, and Accounting for the Internet, IEEE Internet Computing, 3(6):75-79, December 1999. [4] J. William Atwood, An Architecture for Secure and Accountable Multicasting, The 32nd IEEE Conference on Local Computer Networks, Dublin, Ireland, October 2007. [5] S. Islam and J. William Atwood, A Framework to Add AAA Functionalities in IP Multicast, Advanced International Conference on Telecommunications, Guadeloupe, French Caribbean, February 2006. [6] S. Islam and J. William Atwood, The Internet Group Management Protocol with Access Control (IGMP-AC), The 31st IEEE Conference on Local Computer Networks, Tampa, FL, November 2006. [7] B. Cain, et al., Internet Group Management Protocol, Version 3, RFC 3376, October, 2002. [8] B. Fenner, et al., Protocol Independent Multicast - Sparse Mode (PIMSM): Protocol Specification (Revised), RFC 4601, August 2006. [9] A. Ballardie, Core Based Trees (CBT) Multicast Routing Architecture, RFC 2201, September 1997. [10] R. Mukherjee and J. William Atwood, Multicast Group Authentication, Network Control and Engineering for QoS, Security and Mobility, Lannion, France, November 2005. [11] T. Ballardie and J. Crowcroft, Multicast-specific security threats and counter-measures, IEEE Symposium on Network and Distributed System Security, 1995. [12] N. Ishikawa, et al., An Architecture for User Authentication of IP Multicast and Its Implementation, IEEE/APAN Internet Workshop, Japan, February 1999. [13] C. Shields and J.J. Garcia-Luna-Aceves, KHIP-A Scalable Protocol for Secure Multicast Routing, Applications, Technologies, Architectures, and Protocols for Computer Communication, 1999. [14] N. Wang and G. Pavlou, Scalable Sender Access Control for Bidirectional Multicast Routing, Computer Networks, 43(5): 539-555, December 2003. [15] M. Kellil, et al., Multicast Receiver and Sender Access Control and Its Applicability to Mobile IP Environments: A Survey, IEEE Communications Surveys and Tutorials, Second Quarter, 7(2):46–70, 2005. [16] P. Calhoun, et al., Diameter Base Protocol, RFC 3588, September 2003. [17] B. Aboba, et al., Extensible Authentication Protocol (EAP), RFC 3748, June 2004. [18] P. Eronen, T. Hiller and G. Zorn, Diameter Extensible Authentication Protocol (EAP) Application, RFC 4072, August 2005. [19] Forsberg, D., et al., Protocol for Carrying Authentication for Network Access (PANA), Internet Daraft, Work in progress, June 2007. [20] P. Jayaraman, et al., Protocol for Carrying Authentication for Network Access (PANA) Framework, Internet Draft, Work in progress, June 2007. [21] C. Kaufman, Internet Key Exchange (IKEv2) Protocol, RFC 4306, December 2005. [22] S. Kent and K. Seo, Security Architecture for the Internet Protocol, RFC 4301, December 2005. [23] M. Parthasarathy, PANA Enabling IPsec based Access Control, Internet Draft, Work in progress, July 2005. [24] B. Aboba, et al., Extensible Authentication Protocol (EAP) Key Management Framework, Internet Draft, Work in progress, February 2007. [25] S. Kent, IP Encapsulating Security Payload (ESP), RFC 4303, December 2005. [26] S. Kent and R. Atkinson, IP Authentication Header, RFC 4302, December 2005. [27] Y. Rekhter, et al., A Border Gateway Protocol 4 (BGP-4), RFC 4271, January 2006. [28] H. Holbrook and B. Cain, Source-Specific Multicast for IP, RFC 4607, August 2006. [29] S. Islam and J. William Atwood, A Policy Framework for Multicast Group Control, IEEE Workshop on Peer-to-Peer Multicasting, Las Vegas, NV, January 2007.
VII. C ONCLUSION AND FUTURE WORK We are not very far from the deployment of IP multicast to deliver content to the end users on a commercial basis. Sender access control will solve a key issue of our framework [5] that we have developed to deploy AAA protocols for controlling IP multicast group membership. In future, we want to complete the inter-domain architecture. Furthermore, a sender access control policy, specially a sophisticated authorization and accounting policy is required. We have already designed a policy framework for multicast receiver access control [29], which can be extended for sender access control. Finally, we want to accomplish a performance study of our architecture by using a proper simulation tool. ACKNOWLEDGMENT J.W. Atwood acknowledges the support of the Natural Sciences and Engineering Research Council of Canada, through its Discovery Grants program. S. Islam acknowledges the support of Qu´ebec Government through its Fonds Qu´eb´ecois de la Recherche sur la Nature et les Technologies scholarship program and of Concordia University.
86
