Secure Multi Cast Transmission

Anirudha Kumar Pandey*, Dr. Sipi Dubey

Dept. of Computer Science & Engineering, RCET, Bhilai, Chhattisgarh,  India

*Corresponding Author E-mail: ani.kumar.pandey@gmail.com; drsipidubey@gmail.com

 

 

ABSTRACT:

Multicast networking support is becoming an increasingly important future technology area for both commercial and military distributed and group-based applications. Integrating a multicast security solution involves numerous engineering tradeoffs. The end goal of effective operational performance and scalability over a heterogeneous internetwork is of primary interest for wide scale adoption and application of such a capability. Various techniques that have been proposed to support multicast security are discussed and their relative merits are explored. A common simple criterion was established that can be used to evaluate multicast keying architectures. The criteria focus on the efficiency and scalability of the keying solution. Using these criteria, several keying architectures are evaluated and compared to determine their strengths and weaknesses.

 

KEYWORDS: Multicast, Datagram, Unicast, UDP.

 

 


INTRODUCTION:

Multicast communication as defined in [1] is an efficient means of distributing data to a group of participants. In contrast to unicast communications, multicast routing permits a single IP datagram to be routed to multiple hosts with minimal redundant transmission within a network. Membership in a multicast group is often highly dynamic, with receivers entering and leaving the multicast session without the permission or explicit knowledge of other hosts. The inherent cost and resource benefits of multicast routing and data delivery are clear; however, the group-oriented communication paradigm presents new and unique technical challenges beyond traditional network security approaches. Potential security threats to multicast communications are similar to those encountered in unicast transmissions. Threats include the unauthorized creation, alteration, destruction, and illegitimate use of data [5]. In the case of multicast traffic, because of the inherent broad scope of a multicast session, the potential for attacks may be greater than for unicast traffic. It is desirable to secure these vulnerabilities while maintaining some of the efficiency and performance benefits of multicast service.

 

The field of multicast networking and related security issues is a broad technical subject. Within the space limitations allowed, we discuss some relevant technical issues and performance tradeoffs to consider when applying security and key management techniques in support of multicast networking. First, we provide a brief background of multicast technology  and potential network security threats and issues. Second, we explore the application of existing and proposed security techniques for multicast networking, including key distribution, dynamic key management, and reliability issues. Throughout this paper we hope to summarize performance and security policy considerations within the context and impact of overall architectural performance. Multicast communications is an efficient means of distributing data to a group of participants. In contrast to unicast communications, multicast routing permits a single IP datagram to be routed to multiple hosts simultaneously. Membership in a multicast group is dynamic, allowing hosts to enter and leave the multicast session without the permission or knowledge of other hosts. The inherent benefits of multicast routing may also present some vulnerability making it susceptible to attack unless they are secured. The goal is to secure these vulnerabilities while maintaining the benefits of multicast service. In many cases, cryptographic techniques such as encryption may be used to provide some of these security services. In this paper, issues related to the cryptographic keys supporting these techniques are shown to be crucial to the security of a multicast session. Many multicast security problems may be abstracted into a key distribution and management problem. In order to secure a multicast session, a generic outline for multicast session registration and key distribution can be followed. Using this outline as a model, this paper establishes a set of criteria useful in evaluating several recently proposed multicast key distribution architectures. Each architecture focuses on methods designed to efficiently distribute keys to a multicast group. The techniques used to achieve this goal are different in each example.

 

I.    Overview of multicast service

Group communication [1], as opposed to the classical one-to-one communication, is a way to send a set of data to multiple receivers simultaneously. An increasing number of applications, such as audio-on-demand, video-on-demand, IP-TV, tele-conference, distance-education, multi-player gaming and file update or distribution, inspire the development of multicast technology [9]. Short-term and long-term solutions have been proposed, and a lot of progress has been made in research, implementation and deployment [2]. IP multicast was first introduced by Steve Deering in 1988, and it was first widely applied to “audiocast” at the 1992 IETF meeting [10]. To support multicast on top of traditional networks, the Multicast Backbone (MBone) was created, which consisted ofhost-to-host unicast tunnels [11]. With the development of group communication, most newly produced routers naturally support multicast. In unicast, when multiple receivers require the same data, a sender has to send out multiple copies of data to them one by one, as shown in Figure 2.1(a). However, in case of multicast, the sender sends out only one copy of the data to immediate multicast routers, and the routers in the network forward the data only to the ports that connect to interested receivers, as shown in Figure 2.1(b).

 

Figure 2.1 Unicast and Multicast

 

The efficiency of multicast comes from two factors: fewer packets sent from a source and fewer packets forwarded within the network [12]. A considerable amount of time and bandwidth could be saved when the number of receivers is large enough. Multicast is based on the concept of a group, which consists of an arbitrary number of interested participants. The group is open to everybody, having no physical or geographical boundaries [1]. Anybody can join in a multicast group, without any authorization; a host can belong to many different groups without any restriction; a source can send multicast data to a group at any time, even though it is not a member of the group; the group is dynamic and one can join or leave a multicast group at any time; the number and identity of group members are known neither to the sources nor to the receivers [1]. A Multicast group is identified by an IPv4 class D address or an IPv6 address starting with “0xFF.” Ipv4 class D addresses fall in the range from 224.0.0.0 through 239.255.255.255 [1]. These addresses only appear as destination addresses in IP packets. Unlike a unicast address, a multicast address is dynamically assigned to a group at present [1].

 

IP multicast is the transmission of IP datagrams to a host group [1]. A host group is a collection of multicast capable hosts that either transmit IP datagrams to or receive datagrams from a particular Class D IP address. Class D addresses are reserved specifically for multicast communications and can be dynamically assigned among multicast groups. Within the multicast group, membership is also dynamic. Hosts may enter and leave the group at will without permission from other group members. In a non-secure or public group, only knowledge of the multicast address is required for membership. Several protocols are necessary to route IP datagrams to a multicast group. Hosts identify their desire to become part of a multicast group to their local router using the Internet Group Management Protocol (IGMP) messages defined in [1]. In order to deliver multicast IP datagrams to group members, routers may use one of several  routing protocols that define the network routing topology [2, 3, 4]. The MBONE is an example of a multicast network overlaid on top of the traditionally unicast Internet by using the Distance Vector Multicast Routing Protocol (DVMRP) [2, 5]. Some properties of these routing topologies may prove beneficial in multicast key distribution architectures. For example, in [7], Ballardie describes a key distribution architecture centered around a core router defined for the Core Based Tree (CBT) multicast routing protocol [4].The scope of a multicast group can be limited by restricting the routing of its IP datagrams. By manipulating the time-to-live field in each IP datagram [6], hosts can limit the scope of their traffic by controlling the number of hops a datagram travels before routers discard it. By restricting the time-to-live field of a datagram, we create basic form of confidentiality for the group by limiting the potential audience of the data. This may be considered at best a very weak form of confidentiality that is difficult to enforce. Therefore, stronger mechanisms are required if we want greater assurance.

 

Multicast application layer data is typically encapsulated by the transport layer UDP protocol. The combination of UDP and IP protocols create an unreliable datagram service without error correction capabilities. Protocols such as the Real- Time Transport (RTP) protocol are designed to correct some of these deficiencies [8]. RTP runs on top of UDP and the underlying network protocol to provide end-to-end network transport functions for multicast audio and video conferences or sessions. A session is defined as the exchange of multimedia data (e.g., an audio conference) within a multicast group [9]. Several sessions may be active within a single multicast group (e.g., one for audio and another for video). The type of host participation in a multicast session can further define the nature of the session. In a many-tomany type application, multiple group members may receive and transmit data simultaneously during the session. In contrast, a one-to-many or push application typically has only one transmitter and many receivers for the session. The type of application may influence the design of a security architecture. For example, a one-to-many application is inherently centralized and may benefit from a security architecture centered around a single trusted host. Distributed many-to-many applications may benefit from distributed security architectures with multiple trusted hosts performing registration and key distribution functions. Multicast sessions may also be described in terms of their membership. In general, a session is defined as either public or private. Both types are defined by the level of access control required to join the multicast group [10]. Public sessions are typically encountered on the MBONE and are supported by the dynamic nature of multicast communications (i.e., knowledge of the multicast address is the only requirement for membership). We can further restrict public sessions by requiring users to register and pass an authentication check in order to participate. In order to limit the scope of a private multicast session, both registration and authentication are required for participation [10]. To limit the visibility of the secure session, the session traffic is usually encrypted. In this paper, we define a secure multicast session as a private session with encryption. Multicast applications can benefit from the addition of security services. Commercial applications that use public networks can limit user access to services and control user participation. Without these security features, user participation cannot be tightly controlled. Access control mechanisms applied during registration can limit participation to only paying customers. Military applications such as command and control have obvious benefits from the application of security. By tightly controlling access during registration, only users with the proper credentials can join the session. In both arenas, access control is the important initial step in defining the multicast group. Once the group is established, we can argue that most of our security concerns can be abstracted into a key management problem.

 

II.   Security in multicasting

Several technical and security policy issues must be considered prior to placing security mechanisms in the protocol stack for a secure multicast session. Varying levels of security can be achieved through placement of security mechanisms at different levels of the stack. For multicast communications, it is important to consider the impact of security mechanisms on  nonsecurity related functions at other layers of the stack, particularly reliability protocols running above UDP. At the network layer, IP Security mechanisms can provide an important supporting role in helping to maintain secure multicast sessions. ESP and AH provide a framework for providing confidentiality, integrity, and authentication services  to IP version 4 (IPv4) and IP version 6 (IPv6) protocols. Both security protocols are flexible and can support a variety of security mechanisms. They are not restricted to a specific cryptographic algorithm or other security standard. This flexibility may help resolve security implementation problems when overlapping security policies cover a multicast group [12].

 

For example, conflicting security policies may arise when a multicast session extends across international boundaries. In this situation, the separate policies might dictate different cryptographic algorithms with different key lengths. In both IP security protocols, the combination of the Security Parameter Index (SPI) and its destination address uniquely identifies a particular security association [13]. In a multicast session, senders can identify a particular multicast security association using the SPI for the session and addressing its Class D address. This combination identifies the datagram as belonging to a particular multicast session but does not positively identify the originator. Because only authorized users have access to group key material, a correctly encrypted datagram is proof of membership in the group. However, in order to provide data origin authentication, a separate security association may be required for each sender to the multicast group [13]. In large groups, the additional requirement of source authentication may introduce a great deal of additional complexity to the overall system security architecture. In some applications, network layer security may not be the best solution. Some reliable multicast protocols operating above UDP/IP may impose a level of hierarchy that may complicate a security design. For example, the Reliable Multicast Transport Protocol II (RMTP-II) builds a local recovery hierarchy at the application layer for handling receiver acknowledgments. In this case, network layer security may impose some restrictions on RMTP-II unless intermediate nodes are trusted and given the group key material. Only with access to this key material can they perform their assigned duties (e.g local caching and aggregation of control information). Therefore, it becomes a policy issue whether to extend the definition of the secure group to include others who are not the intended end-recipients of the data. Although placing security at the application layer may improve the performance of higher level protocols, it may also weaken the security of the system leaving it open to attacks which are normally protected with lower layer security (e.g., traffic analysis). As introduced previously, through the use of encryption and digital signatures, we can achieve desired levels of confidentiality, integrity, and authentication for a network multicast session. Assuming the use of strong security mechanisms that cannot be easily defeated by frivolous cryptanalytic attacks, we can focus our security concerns on protecting the key material. Therefore, we focus our security concerns and the rest of our technical discussion around key management, key distribution, and access control for key material. With this in mind, a secure multicast session is defined by its Class D IP address or addresses and the required keying material. The size, type (e.g., asymmetric vs. symmetric), and number of keys required to secure a multicast session is determined by the encryption mechanism, the employed security policies, and the keying architecture. For private multicast sessions, access to these keys must be restricted in order to maintain the security of the overall session. Therefore, during the session registration process, it is necessary to require strong

authentication mechanisms to establish the identity of potential participants prior to distributing key material. When these personal attributes are bound to a signed digital certificate, the certificate’s digital signature and its relationship in a certificate hierarchy may verify the identity of a participant and their assigned permissions. Depending on the network or application security policy and the amount of traffic encrypted under a particular key, it may be necessary to periodically issue a new key or “rekey” a multicast session. A rekey may also be required in the event of a suspected or detected key compromise. In this case, depending on the governing security policy, it may be necessary to exclude the compromised site from future communications. Therefore, a rekey may be targeted to specifically prohibit a compromised site from engaging in future communications without adversely affecting the rest of the group membership. Depending on the security policy in place, the definition of compromise might include the voluntary exit of a participant from a secure session. If this occurs, the entire group may require a rekey to prevent a previous participant from rejoining the group at a later time without re-registration. In addition, the keying architecture should prevent collusion by a group of disbanded members from generating or recreating the new group key.

 

III.            Proposed methodology for multicasting transmission

In AOMDV each RREQ, respectively RREP arriving at a node potentially defines an alternate path to the source or destination. Just accepting all such copies will lead to the formation of routing loops. In order to eliminate any possibility of loops, the “advertised hopcount” is introduced. The advertised hopcount of a node i for a destination d represents the maximum hopcount of the multiple paths for d available at i. The protocol only accepts alternate routes with hopcount lower than the advertised hopcount, alternate routes with higher or the same hopcount are discarded. The advertised hopcount mechanism establishes multiple loop-free paths at every node. These paths still need to be disjoint. For this we use the following notion: When a node S floods a RREQ packet in the network, each RREQ arriving at node I via a different neighbor of S, or S itself, defines a node-disjoint path from I to S. (For proof see [5]).In AOMDV this is used at the intermediate nodes. Duplicate copies of a RREQ are not immediately discarded. Each packet is examined to see if it provides a node-disjoint path to the source. For node-disjoint paths all RREQs need to arrive via different neighbors of the source. This is verified with the firsthop field in the RREQ packet and the firsthop_list for the RREQ packets at the node.

 

At the destination a slightly different approach is used, the paths determined there are link-disjoint, not node-disjoint. In order to do this, the destination replies up to k copies of the RREQ, regardless of the firsthops. The RREQs only need to arrive via unique neighbours

 

IV.            Experimental result

The entire topology has been divided in three groups G1, G2, G3. A node can receive or transmit packet on when it is the member of a group. For G1 node 5 is working as router. And for G2 node 3 is working as router. And for G3 node 4 is working as router.

Simulation starts at time t=0.5.

At t= 24, node 6 joins group G1. At this time node 5 updates it's routing table and constructs a route from 5 to 6 via node 4.

At time t=25 node 6 leaves group G1. And hence there is no transmission from 5 to 6.

At t=29 node 6 joins group G1, and router 5 again transmit packets to node 6 via node4. At t=40, node 6 moved out.

At t=40.5 node 6 moved-in.

At t=70 node 2 joins group G1. Router 5 forwards packet to node 2 via route 5-4-6-2.

At t=78 node 2 leaves group. At t=80.5 node 2 again join group G1, and router forwards packet to it through route 5-4-6-2.

At time t=84 node 2 leaves group G1.

At t=84.5 node2 join group G1.

At t=88 node 2 leave group G1.

At t=89 node 2 joins group G2. At this time router 3 starts transmission to node 2.

At t=90 node 2 joins group G1, at this time router 5 and router 3 both transmit packets to node 2.

At t=93 node 4 joins group G3. For G3 node 6 is working as router and transmit the packet to node 4.

At t=96.5 node 2 joins group G3. Router 6 computes a route for transmitting packets to node 2 via node 4.

At t= 102 node 2 leaves group G3.

At t= 102 node 4 leaves group G3.

At t=106 node 2 leaves group G1.

At t=110.5 node 2 joins group G1.

At t=112.5 node 2 leave group G1

and node 4 join group G3.

At t=115.5 node 3 join group G3, and router 6 updates it's routing table and reconstruct a route  rom router to node 3 via node 4 as 6-4-3.

At t=118.5 node 6 leave group G1.

At t=121 node 6 join group G1.

At t=123 node 6 leave group G1.

At t=124 node 4 leave group G1.

At t=128 node 4 join group G1.

At t=136 node 3 and 4 leave group G3.

At t=138.5 node 2 join group G3, router 6 recomputes route from 6 to 2 as 6-4-2.

At t=140.5 node 4 leave group G3, and node 2 join group G1.

At t= 157 node 2 leave group G1.

At t= 163.5 node 2 join group G1.

At t= 167.5 node 2 leaves group G1.

At t= 167.5 node 4 join group G3.

At t= 170.5 node 4 leaves group G3.

At t= 170.5 node 2 join group G1.

At t= 179 node 4 leaves group G3.

At t= 187 node 6 leaves group G1.

At t= 188 node 6 join group G1.

At t= 195.5 node 4 join group G3.

At t= 195.5 node 2 leaves group G1.

At t= 198 node 3 join group G3.

At t= 199 node 3 leaves group G3.

At t= 200 Simulation END

 

Figure 5.1  : Multicast Transmission

V.  CONCLUSION:

In this paper we propose a Multicast transmission with describe topology.

 

VI. REFERENCES:

1.       Host Extensions for IP Multicast, S. Deering, RFC 1112, 1989.

2.       Distance Vector Multicast Routing Protocol, S. Deering, C. Partridge, and D. Waitzman, RFC- 1075, 1 November 1988.

3.       Multicast Extensions to OSPF, J. Moy, RFC 1584, Proteon, Inc., March 1994.

4.       Core Based Trees (CBT) Multicast Routing Architecture, A. Ballardie, Internet-Draft, May 1997.

5.       Routing in the Internet, C. Huitema, Prentice Hall, 1995.

6.       Internet Protocol, J. Postel, , RFC-791, USC/Information Sciences Institute, September 1981.

7.       Scalable Multicast Key Distribution, A. Ballardie, RFC-1949, May 1996.

8.       RTP: A Transport Protocol for Real-Time Applications, H. Schulzrinne et al, RFC- 1889, January 1996.

9.       SAP: Session Announcement Protocol, M. Handley, Internet-Draft, 19 November 1996.

10.     Distributed Registration and Key Distribution (DiRK), R. Oppliger and A. Albanese, Proceedings of the 12th International Conference on Information Security (IFIP SEC ‘96), Island of Samos (Greece), May 21-24, 1996, Chapman & Hall, London, pp. 199-208.

11.     Computer Communications Security: Principles, Standard Protocols and Techniques, W. Ford, Prentice Hall, 1994.

12.     Key Management for Multicast: Issuesand Architecture, D. Wallner, E. Harder, and R. Agee, Internet-Draft, draft-wallnerkey- arch-00.txt, 1 July 1997.

13.     Security Architecture for the InternetProtocol, R. Atkinson, RFC-1825, Naval Research Laboratory, August 1995.

14.     IP Encapsulating Security Payload (ESP), R. Atkinson, RFC-1827, Naval Research Laboratory, August 1995.

15.     IP Authentication Header, R. Atkinson,RFC- 1826, Naval Research Laboratory, August 1995.

16.     Internet Security Association and Key Management Protocol (ISAKMP), D.Maughan, M. Schertler, M. Schneider, J. Turner, Internet-Draft, 21 February 1997.

17.     Security Problems in the TCP/IP ProtocolSuite, S. Bellovin, ACM Computer Communications Review, Vol. 19, No. 2,March 1989.

18.     SIP: Session Initiation Protocol, Handley,Schulzrinne, Schooler, Internet-Draft, 31 July 1997.

19.     SDP: Session Description Protocol, M. Handley and V. Jacobson, Internet-Draft, 2 September 1997.

20.     Applied Cryptography, Second Edition: Protocols, Algorithms and Source Code inC, B. Schneier, John Wiley & Sons, Inc., 1996.

 

 

 

Received on 01.06.2012       Accepted on 10.06.2012     

© EnggResearch.net All Right Reserved

Int. J. Tech. 2(1): Jan.-June. 2012; Page 06-10