Using IGMPv3 to manage multicast access

Download PDF
19 downloads 42459 Views 491KB Size Report
Comment
(LNR) are the best place to implement receiver filtering functions [MAFIA] [MCOP] ... point all available multicast host information of the managed domain. This is ...
Using IGMPv3 to manage multicast access Benoît HILTα and Jean-Jacques PANSIOTβ α

IUT de Colmar, BP 50568, F-68008 Colmar cedex – France E-Mail: [email protected]

β

LSIIT, BP10413, F-67412 Illkirch cedex – France E-Mail: [email protected]

Today the most widely accepted multicast architecture is an open model based on the PIM-SM and IGMP or MLD protocols. In this architecture the routing protocols in the multicast network core are driven by the hosts of the leaf networks. This can cause several security problems in case of host misbehavior. This communication model, in its basic definition, involves neither management nor security functionalities. In this paper we first analyze some multicast communication basic security and management needs. We describe then a multicast management and accounting architecture based on the filtering and extension capabilities of hosts management protocols last version (IGMPv3/MLDv2). Keywords: Multicast, Management, Access control, Network management

1. Introduction Nowadays, the research effort in multicast routing is focused onto the PIM-SM and IGMPv3/MLDv2 protocols based model [RFC2362] [RFC3376] [RFC3810]. Because of scalability and management potential, this model is today certainly the best that can be adopted by an ISP to offer a multicast service [MAFIA]. One advantage of this model is its scalability in the number of groups or group members. But on another side, in this model, the core of the network (the routers executing the multicast routing protocols) is entirely driven by the hosts of the leaf networks. The lack in end-node management such as access filtering and accounting stands in the way of multicast deployment. Let us see some significant examples to illustrate the need of a multicast management and accounting tool involving sources and receivers. When a source starts to send, it transmits its multicast data, most often UDP datagrams, to its local network. Then its first hop router forwards these data to the core of the network directly in the multicast tree, if it exists. No mechanism permits today to block a source or the emitting capabilities of an entire network. Such a filtering mechanism could both save bandwidth and secure the core of the network by forbidding unwanted traffic. When a host joins a multicast communication, it doesn't know if a source is sending toward the selected group. A centralized management tool that makes this information available for an entirely managed domain can avoid building useless tree branches and saving signaling bandwidth. Receivers joining numerous multicast communications can produce DoS attacks by overloading their first hop router and over them, the core of the network. Because of technical considerations, like available technology and/or bandwidth, or for policy considerations, it may be necessary to deny the access to selected hosts. In such cases, an access control filtering tool can both protect the core of the network and reduce router load. These examples illustrates that a multicast security and management (i.e. access filtering and accounting) tool can provide a reduction in both, the LAN bandwidth consumption and the amount of signaling messages in routing protocol by limiting un-trustworthy join request and invalid or unavailable routing tree construction [MAFIA].

Using IGMPv3 to manage multicast access The goals of multicast management are to manage the access to the multicast services and to provide accounting for their use. The multicast management concerns network policy and security. If we consider a situation in which a Network Service Provider is responsible for network management and particularly multicast management, this NSP makes its multicast service available for the Content Owners and the End Users [MACCNT]. The NSP is then the natural manager of the access to its multicast network resources. Because we study only this type of management, the scope of our multicast management architecture is restricted to the NSP domain. The management of transit multicast traffic is not supported by the presented architecture and will be the subject of a further study. To manage the access to its multicast service with the most efficiency, a NSP must act on its network elements as close as possible to the End Users (EU). Therefore its Leaf Network Routers (LNR) are the best place to implement receiver filtering functions [MAFIA] [MCOP] [GOTHIC]. Because the LNR is the first point where the source traffic is available for the NSP, we use it also to provide source traffic filtering1 [MCOP]. Due to this, all the filtering functions (for receivers and sources) can be gathered in the LNRs. In order to make multicast access decisions and accounting, it is necessary to centralize in one point all available multicast host information of the managed domain. This is indeed a common point of several proposed architectures [MAFIA] [MCOP] [GOTHIC]. The elements of our architecture are presented in figure 1. All multicast events from the networks connected through a LNR are concentrated to the Multicast Manager (MM) which is the core point of this architecture and of the managed domain. Signaling between LNRs and the MM is based on IGMPv3 like messages. Src.

Multicast Manager LNR

MM Src.

LNR

Rec.

LNR

Figure 1

Leaf Network Router

: Global Multicast Management architecture

2. Background and related work As presented above, today the most deployed multicast architecture is based on an open model made, on one hand, of routers running one of the PIM-SM family multicast routing protocols. These form the core of the multicast network. On the other hand, to manage the receivers in the connected leaf networks, several routers run one of the IGMP/MLD family group management protocols. In this model, hosts sending or receiving data are located in leaf networks, while the network core ensures the building of distribution trees and the multicast data forwarding along these trees between the leaf networks.

1

Do not confuse with IGMPv3/MLDv2 per group source filtering.

B.HILT and J-J.PANSIOT In this part of this paper we define the basic management and security goals of our architecture. Then we take a look at the available protocols for multicast, and show how some of them are suitable for multicast management. Finally we position our architecture with respect to other architectures proposed in the literature. In a multicast network, one of the goals of management is to avoid the waste of bandwidth due to useless traffic or unused trees. Another of these goals is to produce accounting information workable for billing, traffic study and network management [MAFIA] [MACCNT]. To reach these goals, it is necessary to make available in a central point the information concerning the multicast host activity: the starting and leaving time for a host receiving a group, how long a source sends traffic to a particular group, etc…[MACCNT]. The first security point concerns the denying of unwanted hosts such as malicious sources or hosts receiving numerous high bandwidth groups. This includes the protection from DoS attacks. A second security point concerns the application of administrative or policy filtering needed to manage the network. If we summarize the basic needs of a multicast management and security tool, we can list the following elements: - the selection of hosts that are allowed to receive and/or send multicast data can preserve bandwidth, - the logging of the access requests and their results can be used to produce billing information, statistics and more generally for accounting information about hosts and/or groups and/or sources, - the dynamic setting of access rights based on bandwidth consumption, number of group membership, etc… is an answer to network DoS attacks, - a global view of groups and group membership allows managing multicast resource usage and dynamically adapting multicast access rights. Notice that, if a multicast flow without additional protection like encryption is received by one host of a network, it is available for all the multicast capable hosts of this network. Therefore, on the way from sources to receivers, the main benefit of receiver access filtering concerns bandwidth usage, not confidentiality. Security and management of a multicast networks needs the centralization of, as much as possible, information about host activity. Due to this, let us take a look at the leaf networks for multicast suitable source and receiver management protocols. For source management, only the MSNIP protocol was recently proposed. MSNIP is specially designed for cases where there is a multicast server offering a large pool of potential flows that map onto separate multicast destination addresses but receivers exist only for a small subset of these flows [MSNIP]. MSNIP is an IGMPv3/MLDv2 extension which allows, after a registration phase, a source membership notification which can be seen as a notification in pull mode. Thus a MSNIP capable first hop router pilots locally registered sources. This control is triggered by receiver joining or leaving events. The goal of the MSNIP source management is to reduce bandwidth waste due to useless source traffic. From the beginning of the multicast, receivers are managed through protocols gathered in a family called Group Management Protocol. The latest version of these protocols, IGMPv3 for IPv4 and MLDv2 for IPv6 [IGMPv3] [MLDv2], offer very interesting source filtering functionalities. Thereafter we'll show how these functionalities make these protocols suitable for access filtering. The protocols from the Group Management Protocol family are primarily designed to report to the multicast routing protocol the wishes of the local receivers (joining and leaving multicast communications). If this information is exported from the LAN to a global domain multicast management entity and if the filtering possibilities are usable by this management entity, these protocols become suitable for receiver access control. This makes the LNR acting as a multicast firewalling tool. Its basic access filtering function is to block, for security or policy reasons, unwanted groups and/or sources traffic for selected hosts. If

Using IGMPv3 to manage multicast access more confidentiality is needed (i.e. in selection of the receivers), simple access filtering becomes insufficient and techniques like encryption are necessary [MGS]. As described in several architectures propositions [MAFIA] [MCOP] [GOTHIC] the collection and the centralization of the wanted and forwarded groups in a multicast domain can enhance the efficiency of the multicast communication by avoiding building unused trees if desired sources or groups are unavailable. Bandwidth can also be saved in leaf networks if a source knows that no receiver exist for its multicast flow. When the traffic from a source is filtered, it is dropped by its LNR. This produces bandwidth gain for the network core, but not for its "home" network. If the MSNIP protocol is available, it can then be used to stop a registered source so the bandwidth gain can be extended to the leaf network. Source filtering is therefore a low level security tool checking each multicast flow in a fully passive mode. Additionally to produce bandwidth saving, this mechanism can be useful in the prevention of edgesenders attack [MAFIA]. How can receiver filtering be achieved? The multicast routing protocol builds its trees based on information made available by group management protocols. A simple way for a multicast router to avoid forwarding traffic towards of a particular group is to filter the IGMP/MLD report messages concerning this group [MAFIA] [MCOP]. In such architectures, this task is achieved using additional filtering tool like Iptables. We present here how it is possible to use directly IGMPv3/MLDv2 filtering possibilities to achieve such filtering. This will produce a gain in efficiency because no piloting of an additional tool [IPEMCOP] is needed. Moreover, since an IGMPv3 report may contain membership information for many groups, filtering can be done with a finest grain. A complete multicast communication filtering tool must offer receiver and source access filtering. The first can be based on IGMP/MLD report messages information, while the second can use UDP messages information. The best place to gather these two filtering functionalities is LNR of each managed network. This choice allows the proposed architecture to stay independent from the multicast routing protocol (i.e. PIM-SM, PIM-SSM) unlike the MAFIA architecture which is mostly based on the ASM model [MAFIA]. To provide a global management and monitoring tool for an entire multicast domain (i.e. NSP domain), the best way is to centralize the membership and source behavior of each managed network. The next part of this paper explains in more details our architecture.

3. The Multicast Management Architecture As described at the beginning of this paper (figure 1), the proposed architecture for multicast management in a domain is based on two main entities. The first is the Leaf Network Router (LNR) of each connected leaf network. The second is the Multicast Manager (MM) which is the core point of the architecture. Because of the domain based localisation of this architecture, only one MM is planed. Of course, by using additional mechanisms, a backup Manager can be added. The domain policy is defined and checked in this manager. Its core position and the availability of the multicast activity of the managed domain are used for accounting. In this part of the paper, we describe first the mechanism of the LNRs. We show then how to gather leaf network information on the MM using a relaying function. We then present how the MM deals with access rights. We finally explain the additional mechanism for architecture operation and how the access policy can be defined on the MM.

3.1. A proposition for multicast access filtering In the proposed architecture, the multicast access filtering concerns receivers and sources. We assume that the group management protocol used on LNRs is version 3 of IGMP or version 2 of MLD. In the following description, numbers placed inside parenthesis refer to figure 2, which presents the detailed structure of the architecture. We start with the case of receivers and follow with source's ones.

B.HILT and J-J.PANSIOT

3.1.1. The case of receivers In a leaf network a receiver expresses its multicast reception needs with IGMPv3/MLDv2 report messages (1). On the LNR these report messages are intercepted by a Communication Control process placed between the IP multicast level and the IGMP/MLD process (figure 2). To avoid processing several copies of the same report, the control process maintains a relaying table with entries of the form R  FR, where R is a report received from a local network and FR is the corresponding report as filtered by the MM (or empty if R should be completely filtered out). During the processing of a report R, all identical incoming messages are discarded. The first copy of R is relayed (2) in unicast to the MM. Because this relaying is connectionless, to ensure its robustness, an associated timer is used to retransmit the relayed messages in the case of message loss. When the MM receives the relayed message (2), it checks out its content (3) and compares it to the locally stored domain policy. According to this policy, the MM sends back to the LNR a message FR (4) containing the intersection between the relayed receiver request and the receiver rights. When FR comes back to the LNR (4), it is used to build the rule R  FR in the relaying table. A flag is positioned to indicate that the message was treated by the MM and the associated timer is now used to indicate the lifetime of the message received from the MM. This timer is positioned by each incoming report message to a value higher than the IGMP/MLD Query interval * Robustness variable. If it expires, the corresponding entry is cleared from the LNR relaying table. When a received IGMPv3/MLDv2 report message R matches a relaying table R  FR entry, the report FR is transmitted to the local IGMP/MLD process. To summarize, an entry R  FR of the relaying table can express 3 situations: either FR = R and R is fully accepted, or FR is empty and the report is completely refused, or FR is a proper subset of R. Multicast routing protocol

4

IGMP/MLD

5

Communication control

IP unicast

1' 2

Relaying table

IP multicast

1 Source data flow

IGMP/MLD Report

Leaf Network Router architecture Global position of elements Src.

Multicast Manager architecture

Policy Database

LNR

3 MM

Communication management

2

Rec.

IP

4 Figure 2

Multicast management detailed architecture and messages flow

3.1.2. The case of sources When a new multicast data flow is detected by the LNR (1'), it is intercepted by the LNR Communication Control process. Similarly to the IGMP/MLD report treatment of the previous section, the main information of this flow () is stored as the incoming part of a rule in the LNR relaying table. As in receiver's case, a timer is used to ensure robustness. While waiting for a response from the MM, data packets from this flow are discarded. The information about the flow is relayed (2) to the MM in a new IGMPv3 message type called Send. We use here the same IGMPv3/MLDv2 message formalism to deal with receivers and sources. When the MM receives the relayed message (2), it checks in its policy database whether the source is allowed or not to send to this group. Accordingly, the MM sends back to the LNR a

Using IGMPv3 to manage multicast access message (4), which is either a Send message if the source is allowed, or a message of a new type No_Send if the source is denied (figure 3). Record type

Value

Name

Current state record

1

MODE_IS_INCLUDE

Interface have a filter mode of INCLUDE

Current state record

2

MODE_IS_EXCLUDE

Interface have a filter mode of EXCLUDE

Filter mode change

3

CHANGE_TO_INCLUDE_MODE

Filter mode change

4

CHANGE_TO_EXCLUDE_MODE Interface has changed to EXCLUDE filter mode

Source list change

5

ALLOW_NEW_SOURCES

The system wishes to hear from the source list

Source list change

6

BLOCK_OLD_SOURCES

The system no longer wishes to hear from source list

Source management

X

SEND

Source management

Y

NO_SEND

Figure 3

Meaning

Interface has changed to INCLUDE filter mode

The system specified in the Sources address field wishes or is allowed to send to the group specified in Group Record The system specified in the Source address field stops or is not allowed to send to the group specified in Group Record

New proposed source management Group Record Types

When the LNR receives this message back (4), it stores its information in the outgoing part of its LNR relaying table. If the response is a No_Send, it then triggers a filtering tool to discard the source traffic, or modifies directly the MFIB to avoid the forwarding of multicast packets from this source. Like the receiver case, a flag is positioned to indicate that the message was treated by the MM. The associated timer is now used to detect when source stops. Each time a data packet is received, the timer value is positioned to its initial value, which reflects the accepted latency between source stopping and MM information. If the timer reaches zero, the LNR erases the source entry in its table and sends a No_Send message to the MM to inform it that the source has stopped. In the case of shared tree (i.e. PIM-SM) source filtering avoids register branch construction to RP for denied source. In the case of shortest path tree (i.e. PIM-SSM) the deny information should be relayed from LNR to cooperative source to stop useless traffic using for example the MSNIP extensions

3.2. How to centralize leaf network information to the Multicast Manager We consider the case of a multicast network architecture where each LNR is running one of the IGMPv3 or MLDv2 protocols. As described above, a relaying function is used to bring to the MM the pertinent information (multicast flows asked by receivers or sent by sources) derived from local IGMP/MLD report messages and multicast source UDP datagrams. To do this, we choose to stay as close as possible to the original information. Because IGMP/MLD report messages are transported directly over IP, we use this property to forward the message out of its origin network. On the way to destination, routers don’t need to process this message. Therefore, the Router Alert option of IGMP reports can be removed. In the IGMP message itself, the IP source address of the original message is positioned to the router address. Due to that, to inform the manager about the original source of the message, a new option called "Source Address" is added. This operation has two goals. The first is to inform the MM of each receiver identity without explicit IGMPv3/MLDv2 tracking activation on LNR's. The second is to permit the association of the report coming back from the MM with the report stored in the LNR relaying table. Also at the IP level the TTL must be placed at the default value 64 and, of course, the IP destination address is the MM address. To take into account a new sending source, it is necessary to translate into an IGMP/MLD report like message multicast information (i.e. group and source) of UDP multicast data frames. This is made by filling out an IGMPv3/MLDv2 message containing a unique group record type, and using the new proposed group record type as shown in figure 3. Of course the source option is present too (figure 4).

B.HILT and J-J.PANSIOT IGMP report Router alert option

IGMP/MLD report relaying

IGMP report

IP header

Source address option IP header LNR MM

Rec.

UDP message IGMP report

IP header

Source address option Src.

Multicast Data relaying

Figure 4

LNR

IP header MM

The message relaying

3.3. The Multicast Manager When the MM receives an access query, in the form of a relayed IGMP/MLD report message, it first checks its administrative database. This database contains the security policy for the domain and all necessary administrative information about managed networks. If the host is allowed to join a multicast communication or a source is allowed to send, the message is returned to its relaying router without modification. In the case of an unauthorized source, the report type of the response is NO_SEND. This operation will indicate to the LNR to block the source traffic in its connected network. In the case of a reception denied host, the group record type of the message sent back to the router is positioned to be the intersection between what is asked for and what is authorized. Let us explain this in more details. We assume that global access rights can be split into rights applicable to each host. These rights therefore can be expressed with a basic INCLUDE or EXCLUDE filter mode syntax similar to IGMPv3/MLDv2. Because each relayed message concerns a unique receiver, only the rights for this receiver are taken in account to define the filter mode and the source list of the returned message. Figure 5 summarizes the rules that permit to compute the IGMP message returned to the LNR, where the access rights are expressed as a list of authorized sources (IS_IN) or a list of denied sources (IS_EX). This table is given for a pair (receiver, group). Each line defines for an incoming message the outgoing one according to the defined rights. Incoming msg

Rights

Returned msg

Rights

Returned msg

IS_IN (A) IS_EX (A) ALLOW (A) BLOCK (A) TO_IN (A) TO_EX (A)

IS_IN (B) IS_IN (B) IS_IN (B) IS_IN (B) IS_IN (B) IS_IN (B)

IS_IN (A*B) IS_IN (B-A) ALLOW (A*B) BLOCK (A) TO_IN (A*B) IS_IN (B-A)

IS_EX (B) IS_EX (B) IS_EX (B) IS_EX (B) IS_EX (B) IS_EX (B)

IS_IN (A-B) IS_EX (A+B) ALLOW (A-B) BLOCK (A) TO_IN (A-B) IS_EX (A+B)

Figure 5

Report modification rules for the Multicast Manager

For example, assume that a receiver on a managed network sends a report message to add new sources to those it currently receives. Its report message will contain a group record with a record type of ALLOW and a source list A containing the new wished sources (ALLOW(A)). Assume also that the access rights indicate to the MM that only sources from list B are allowed (that is IS_IN(B)). The result returned to the LNR will be a message containing a group record with the

Using IGMPv3 to manage multicast access record type of ALLOW and a source list which is the intersection of list A (asked) and list B (authorized), ALLOW(A*B). In the returned message, an empty source list in include mode means that it is not necessary for the LNR to deliver the message to its local IGMP/MLD process. To indicate this to the router, the group record type of the returned message is left empty. When receiving such a message, the router then knows that the next identical incoming report messages can be discarded. In order to not discard for example the leave report messages (IS_IN({Ø})), which must be forwarded to the IGMP/MLD process, the rule defined above must only be applied to the computed source lists, and not to those received in incoming messages. If the relayed message is in an older version of IGMPv3/MLDv2 (i.e. IGMPv2) the MM responds in a binary form. If the group is allowed for all sources the message is returned without modification. Otherwise it is returned with an empty group address. This will indicate to the LNR how to treat next identical reports (transmission to its local IGMP/MLD process or discarding). Due to this, the access control is transparent for the IGMPv3/MLDv2 process which can act in compatibility mode as described in the RFC3376 and RFC3810. After checking access rights as described above, the MM creates and maintains a local operational database to reflect the state of each of its managed LNR. To maintain this database, the MM must execute the rules described in the part "Action of reception of reports" of the IGMPv3/MLDv2 definition document [RFC3376][RFC3810]. This operation takes into account all the messages it sends back. This database summarizes the multicast activity for the entire managed domain. Records are maintained for each LNR and its connected networks. Such a record has the following structure: . To include receiver tracking, the source record structure has the following format: , in which receiver_records is a list of registered receivers for this source. All this activity is recorded with time stamping to make it suitable for accounting.

3.4. Additional mechanism for architecture operation The addresses of the MM and LNRs are configured by an administrator in each of the devices. In a typical use, the MM starts before LNRs. But if a LNR starts without a running MM, because of the definition of a default policy, the multicast traffic will be blocked altogether in the local network. In a typical start, when a new LNR starts, because of the periodicity of IGMP messages, no specific mechanism is needed to ensure the access filtering of its active managed hosts. Its relaying table will be constructed dynamically. Some MM events, like a warm restart or a policy update, imply an update of its LNRs state. The proposed technique is to delete the necessary entries (all if needed) of the LNRs relaying table. Thus, the next incoming event (report message or source traffic) will be relayed to the MM. To do this, the MM sends in unicast to each concerned LNR an unicast IGMPv3/MLDv2 query message. The group address field is set to 0 if all the table entries must be deleted and set to the address of a group if only entries for a particular group must be deleted. To avoid discarding bursty traffic toward well known groups, forwarding states are created in LNRs through periodically unsolicited FR messages sended out from MM.

4. Discussion and Future Works 4.1. Discussion The main benefit of the architecture presented in this paper is to use the existing IGMPv3/MLDv2 protocol functionalities. Its filtering possibilities avoid using additional tool, like Iptables, to filter receiver accesses [IPEMCP][MAFIA] on the edge routers. The IGMP/MLD relaying needs some minor network layer modifications compatible with IGMP/MLD protocol definitions [RFC3376][RFC3810]. Due to its strong integration in the IGMPv3/MLDv2 protocols, our

B.HILT and J-J.PANSIOT proposition can be seen as an extension of them. The transport without any modification of the IGMP/MLD part of the report messages makes this method entirely scalable for future IGMP/MLD protocols family upgrades. As presented above, this method allows too, maintaining the backward compatibility to older versions of the group management protocol family. The signalling overhead generated by the relaying method is lower that the one used in the MCOP architecture, which needs a permanent TCP connection between the routers and the manager. And this although additional timer mechanism is needed to ensure the robustness of relaying method for managing message loss. Note also that with IGMPv3 (or MLDv2) a single report may contain information for several groups. Therefore a simple filtering of reports (accept or reject the whole report) as in MCOP is well adapted to IGMPv2 but does not allow a fine grain policy per receiver (per group and per source). Our partial filtering of reports allows this fine grain policy. The design of this architecture allows a router to store only the policy needed for its locally active groups and without any special exchange with the manager to define which policy it is necessary to transfer. Note that in this proposition it can not act on a malicious host like a receiver joining numerous groups or a flooding source. Only their effects can be limited to their LAN. The centralization of information in a rough form (IGMP/MLD part of report messages) let the field of accounting fully open. This implies that the future design of accounting functionalities can be made without any repercussion on the architecture part concerning the host access management on the leaf routers. The presented architecture is in concordance with the model suggested in the discussion around the bird of feather (Bof meeting at the IETF) of a Multicast Access Control group [MACCNT]. In this model the Network Service Provider is placed between the Content Owners and End User. Because the proposed architecture filtering functions act at the network layer, it is natural that the NSP is the manager of the accesses to the resources of its multicast network. To ensure fine management tasks, the Content Owner must be able to define access rights at a higher level. To this way, the IGMPv3/MLDv2 messages extension capabilities are an interesting trump. And the architecture can then evolve to one in which the main actors of the policy are the Internet Service Provider and the Contents Owners [MGS].

4.2. Conclusion and future works The building of an access-filtering tool for multicast domains is the first step to a more complete multicast management tool. The presented architecture allows the domain manager to define the policy. To progress in the multicast communications management, and allow contents owner to define their own policy, this architecture must integrate advanced security elements like key sharing. Currently the proposed architecture allows taking into account only static security policy. Because one of the first benefits is bandwidth saving, the taking into account of quality of service elements in access decisions is one of the other extension goals for this architecture. The use of the common open service policy service protocol can be very helpful in this task [COPS] The open nature and extensibility of the presented architecture added to the extension possibilities of the used protocol (IGMPv3/MLDv2) are the best trumps to reach these goals. The study of the possible interactions with existing protocols can make this architecture suitable for improving the global behaviour of a multicast domain by avoiding for example the construction of unnecessary tree branches if no source exists for a group.

5. Bibliography [RFC2362]

D.Estrin, D.Farinacci, A.Helmy, D.Thaler, S.Deering, M.Handley, V.Jacobson, C.Liu, P.Sharma, L.Wei, "Protocol Independent Multicast-Sparse Mode (PIM-SM) : Protocol Specification", Internet Engineering Task Force (IETF), RFC 2362, June 1998.

[RFC2748]

D.Druham, J.Boyle, R.Cohen, S.Hertzog, R.Rajan, A.Sastry, "The COPS (Common Open Policy Service) protocol", Internet Engineering Task Force (IETF), RFC 2748, January 2000.

Using IGMPv3 to manage multicast access [RFC2974]

M.Handley, C.Perkins, E.Whelan, "Session Announcement Protocol", Internet Engineering Task Force (IETF), RFC 2974, October 2000.

[RFC3376]

B.Cain, S.Deering, I.Kouvelas, B.Fenner, A.Thyagarajan, "Internet Group Management Protocol, Version 3", Internet Engineering Task Force (IETF), RFC 3376, October 2002.

[RFC3569]

S.Bhattacharyya, "An Overview of Source-Specific Multicast (SSM)", Internet Engineering Task Force (IETF), RFC 3569, July 2003.

[RFC3810]

R.Vida, L.Costa, "Multicast Listener Discovery Version 2 (MLDv2) for IPv6", Internet Engineering Task Force (IETF), RFC 3810, June 2004.

[MAFIA]

K. Ramachandran and K. Almeroth, "MAFIA: A Multicast Management Solution for Access Control and Packet Filtering", IEEE/IFIP Conference on Management of Multimedia Networks and Services, Belfast, Ireland, September 2003.

[MCOP]

R.Lehtonen, J.Soini, J.Majalainen, H.Vaitiainen, "Multicast Control Protocol", Internet Engineering Task Force (IETF), draft-lehtonen-magma-mcop-02.txt, February 2003.

[MCOPOP]

R.Lehtonen, J.Soini, J.Majalainen, H.Vaitiainen, M.Tammi, "MCOP operation for first hop routers", Internet Engineering Task Force (IETF), draft-lehtonen-mboned-mcop-operation02.txt, July 2004.

[IPEMCOP]

T.Takahashi, M.Tammi, H.Vatiainen, R.Lehtonen, J.Harju, "Implementation and Performance Evaluation of Multicast Control Protocol", The ninth IEEE Symposium on Computers and Communications, Alexandria, Egypt, June 28 – July 1 2004.

[MGS]

T.Hardjono, LR. Donteni, R.Perlman, "Multicast and Group Security", Artech House, Hardcover, Published June 2003.

[MSNIP]

B.Fenner, B.Haberman, H.Holbrook, I.Kouvelas, "Multicast Source Notification of Interest Protocol (MSNIP)", Internet Engineering Task Force (IETF), draft-ietf-magma-msnip-05.txt, March 2004.

[MACCNT]

T.Hayashi, H.He, H.Satou, H.Ohta, "Accounting Issues in Well Managed IP Multicasting Services", Internet Engineering Task Force (IETF), draft-hayashi-maccnt-01.txt, October 2004.

[GOTHIC]

P.Judge, M.Ammar, "Gothic: A Group Access Control Architecture for Secure Multicast and Anycast", IEEE Infocom 2002, New York, USA, June 2002.