DDoS Attacks against PIM-SM Control Plane

Transcription

1 DDoS Attacks against PIM-SM Control Plane Jean-Jacques PANSIOT University Louis Pasteur LSIIT-CNRS Strasbourg, France Benoit HILT University of Haute Alsace MIPS/GRTC Colmar, France Abstract In this paper we investigate different types of DDoS attacks against a multicast infrastructure. We then look more closely at attacks against the PIM-SM routing protocol, how they could be detected, and then propose a mechanism to mitigate their impact by using a feedback mechanism which could be integrated in the PIM-SM protocol to allow trace back and downstream filtering. I. INTRODUCTION When studying DDoS and multicast it may seem that multicast is a perfect tool for attacks against the network data plane. This is because multicast IP is a mechanism which duplicates a single data packet from a sender to an arbitrary number of receivers. Also multicast congestion control is not as well implemented as in the case of unicast with TCP for example. However this assumption could be largely overestimated since a multicast sender can only send to receivers that agreed to receive beforehand. On the other hand, the multicast routing control plane could be the easy target of severe attacks with denial of the multicast service, and possible impact on the unicast service as well. This paper is organized as follows. Section II gives some useful background on multicast routing. In Section III we classify different types of attacks against multicast. In Section IV we propose some mechanisms to detect DDoS attacks against the multicast routing control plane and in Section V we give some mitigation mechanisms. Finally we give some conclusion and perspectives. II. MULTICAST ROUTING BACKGROUND The original multicast model defined by Deering [1], now called ASM (Any Source Multicast) is a very general and open model. Defined later by Holbrook, the SSM [3] (Source Specific Multicast) model offers fewer features and can be viewed as a subset of ASM. Both models may be deployed simultaneously through PIM-SM [2] (Protocol Independent Multicast - Sparse Mode), by the use of disjoint multicast address ranges. In the current architecture, two different levels of signaling mechanisms are used. A subscription protocol, IGMP [4] (Internet Group Management Protocol) with Ipv4 or MLD [5] (Multicast Listener Discovery) with Ipv6, is responsible for signaling between receivers and neighboring multicast routers in the local area or leaf networks, while a multicast routing protocol is responsible of signaling between multicast routers. In this paper we consider only one multicast routing protocol, PIM-SM, since it is by far the most widely used. Multicasting for Ipv4 and Ipv6 are very similar, so we will present here only the Ipv4 context except in some particular cases. In this setup, receivers, senders and routers are rather independent of each other, and share very few information. In the ASM model, two packets having the same IP group address (i.e. IP destination multicast address) are supposed to be sent to the same group. Whereas in SSM, two packets must have the same IP source AND group addresses so they can be considered to be sent to the same channel. The PIM-SM receiver behavior can then be summarized as follows: A host joins a group G (ASM case) by sending an IGMP- Report specifying group address G. It joins a channel (S,G) (SSM case) by sending an IGMPv3/MLDv2-Report specifying both source S and group G addresses. These reports are sent periodically as long as the host belongs to this channel/group. The host Designated Router (DR) receives this IGMP/MLD-Report which triggers a PIM-Join(*,G) message to the next hop toward the RP for the group G or a PIM-Join(S,G) toward source S for a channel. Intermediate routers basically forward PIM-Join messages toward RP or S by using the RPF (Reverse Path Forwarding) check method. The branch terminates then at the RP or at the first hop router (FHR) of the source S. Finally, all on-tree routers maintain, through periodic PIM-Join signalization, a routing entry for this tree as long as the channel/group has at least one downstream requester. In the SSM model, this defines a tree from the source to receivers. In the ASM model a shared tree rooted at the RP is constructed toward receivers. In this second case, data from any source is initially sent to the RP through the register mechanism, and then forwarded in the shared tree. After that, triggered by the data received from a source S, the RP or the DR of a receiver may send PIM-Join(S,G) messages toward this source, building a shortest path tree (or branch) toward this source. This tree is maintained as long as data comes from this source. For inter-domain multicast routing, additional protocols are needed. Multicast extensions to BGP (Border Gateway Protocol) provided with MBGP [6] (Multiprotocol BGP) are

2 used to construct the MRIB (Multicast Routing Information Base). The MRIB contains an unicast routing table used to find a route while sending PIM-Join messages to other domains. In the ASM model with IPv4, for a given group there is a RP and a shared tree in each participating domain. MSDP [7] (Multicast Source Discovery Protocol) is needed to learn about active sources in other domains. When a RP running MSDP receives a register packet from a source inside its domain, it floods a source announcement to all other MSDP RPs. This, in turn, triggers inter domain PIM-Joins from these RPs to the new source, creating inter-domain source trees. In the ASM model with IPv6, an Embedded-RP address [8] is an IPv6 ASM group address that contains explicitly the unicast address of the RP. Therefore an inter-domain shared tree rooted at this RP can be constructed. When using the SSM model, such additional mechanisms are superfluous because sources are explicitly identified in the channel information. The most important point of the PIM-SM protocol in the context of DDoS is that the shared tree from RP to receivers as well as the source tree from source to receivers, are mainly receiver driven (no receiver, no tree). Tree building is driven by a source only when data trigger shared to shortest tree switching. III. TYPES OF ATTACKS AGAINST MULTICAST In this section we analyze what kind of attacks may be launched against multicast capable networks. Attacks may be launched by senders or by receivers and they can target the data plane with the aim to increase the multicast traffic or the control plane with the aim to increase the number of signalling messages. Of course, attacks may combine several cases. A. Attacks against the Data Plane The goal of a data plane attack could be to increase traffic in order to create points of congestion in intermediate routers, or possibly in receivers. 1) Sender Attacks against the Data Plane: The goal of a sender data plane attack could be to increase traffic on existing groups/channels. With SSM, only S 1 can send data to the channel (S,G). Therefore a distributed data attacks from senders does not appear to be very powerful. With intra-domain ASM, the default behavior and greatest weakness is that anybody can send to a group. So many attackers could send to the same group, overwhelming receivers and/or on-tree routers. Due to the Register mechanism, this could also yield a control plane attack toward the RP, since register messages are usually processed as signaling messages by the CPU. Such an attack will be limited to the multicast domain of the concerned RP. Moreover in the inter-domain case with MSDP (IPv4) these data packets will also create signaling through MSDP source announcements and possibly PIM-Joins if there are receivers in other domains. Therefore this attack could be amplified by 1 or possibly some host in the same LAN as S spoofing its address generating a control plane attack. In fact this type of attack already occurred with the Raben worm [11], and is very easy to launch: it suffices to send packets to randomly generated IPv4 ASM group addresses. This is one reason why MSDP is considered as an interim solution and has not been ported to IPv6. 2) Receiver Attacks against the Data Plane: Another possible data attack could come from receivers: it suffices to join many active groups/channels. However note that if attackers join the same groups, the attack will not be very effective since multicast is precisely designed to reduce the cost of transmitting the same packet to multiple recipients. So attackers must join as many different groups as possible. Moreover since a domain (say a provider of IPTV channels) provides only a limited number of channels and is hopefully correctly dimensioned for them, this attack would not be very good if targeted at a content provider. On the other hand it could be efficient as a global attack against the Internet, since operators may not have provisioned sufficient bandwidth to cope with a huge number of channels on the same link/router (say all the IPTV channels of the world). To summarize, attacks against the data plane would be most effective with ASM and even more so in IPv4 with MSDP. This is why multicast content providers should switch to SSM whenever possible or use IPv6 ASM with the Embedded- RP mechanism otherwise. Note that with Embedded-RP, it is possible to have many RPs, each one used for a small number of groups, so it becomes possible to implement a fine grained sender filtering on the RP. For example an IPTV channel provider may have its own global RP and filter any unauthorized source. B. Attacks against the Control Plane 1) Sender Attacks against the Control Plane: With PIM- SM in SSM mode, senders do not trigger any signaling message. On the contrary, a data packet sent to an ASM address: is encapsulated into a Register message from its DR toward its RP, when received by a RP, in the inter-domain case, may trigger a MSDP source announcement message, may trigger PIM-Join(S,G) messages while a DR or RP is switching from a shared to a source tree. As already seen, MSDP is very vulnerable and should not be used anymore. In the case of Ipv6 ASM (with Embedded- RP), the weakest point is the RP. Therefore a RP should be used only for a limited number of groups, and associated to a filtering policy. This is quite easy for groups with a small number of well known sources. But this setup is much more difficult for open groups, for example a video-conference with participants all over the Internet. This setup indicates that the RP should not be considered as a pure network level service, but more accurately as a session level service. 2) Receiver Attacks against the Control Plane: A receiver uses IGMP messages to join or leave a channel/group. These

3 messages have a scope limited to their LAN (including IGMP snooping switches) or to a collection of LANs using IGMP proxy devices. In all cases, these messages are processed by PIM routers and may trigger PIM-Join/Prune messages. That is, these IGMP messages are not visible from the outside of the extended LAN. This implies that no information concerning the receivers is available outside of the LAN. This could be a problem while trying to trace back an attack. Note that a (malicious) host could also send directly a PIM-Join to a legitimate router, at least located in the same LAN. Currently, PIM-SM is not well protected against fake routers (see [12], [15]). In the next section we will investigate more precisely attacks based on hosts sending IGMP-Report and triggering PIM-Join upstream. Note that a host could increase further the signaling load by sending alternatively IGMP-Report and IGMP-Leave messages, generating respectively PIM-Join and PIM-Prune messages. However for the same number of IGMP messages, this will create less routing entries, so this attack may be less effective. Because of this, in the following we will mainly consider attacks consisting in a large number of IGMP-Report messages resulting in a large number of PIM-Join messages. C. Attacks based on PIM-Join Messages In Table 1 we analyze potential attacks based on PIM-Join messages. As a general comment, in terms of attack efficiency and because of multicast architecture, N distributed PIM-Joins to the same channel/group will be much less effective than N distributed PIM-Joins to different groups/channels. Attacks on the data plane require the knowledge of many active channels/groups whereas control plane attacks do not need this knowledge. Moreover they are easy to target to a given network: it is sufficient to randomly generate SSM (S,G) channels, PIM-Join(S,G), with S located in the target network, or to randomly generate ASM groups (G), PIM-Join(*,G), with G having an Embedded-RP address in the range of the target network. In the case of ASM with IPv4, joining a random group will only create a branch towards the local RP if the group has no active source in other domains. If the group has active sources in other domains, joining the group will trigger the construction of inter-domain trees. Therefore this kind of attack, based on PIM-Join messages seems to be the most serious threat for multicast capable networks. D. Consequences of Receiver Driven Attacks against the Control Plane A DDoS attack against PIM control plane by joining many channels or groups will have the following results. For the sake of this example, assume that channels have been created (this is the maximum number of multicast routing entries in some high end routers) Many PIM-Join messages will be sent (remember that since PIM-SM is a soft state protocol, once a host has joined a group, PIM-Join messages will be sent cyclically, typically every 60s). A 1494 bytes IPv4 packet may aggregate PIM-joins for 73 channels, therefore 28 maximum size PIM-Joins must be sent every second, generating a 335 Kb/s signaling traffic. PIM-Join messages are signaling messages so they will enter the slow path to the router CPU. This may lead to a CPU problem since even high end routers may have relatively slow CPU. In this case, the DDoS attack will downgrade not only the multicast service, but also the global activity of the router. For example, unicast routing updates may be delayed too long, possibliy resulting in a loss of connectivity. If these messages can be processed, they will create (or maintain) many states in routers. The number of possible entries in the TIB and MRIB is obviously limited by the total amount of memory available. For example some low end routers have up to 1000 PIM entries while high end routers may have as much as 120K entries. When the maximum is reached, new PIM-Joins will simply be discarded, resulting in a denial of the multicast service for new legitimate multicast receivers. Moreover, if memory is dynamically allocated from the same pool for unicast and multicast routing tables, there is also a risk of downgrading unicast routing too. We may summarize this section by saying that a DDoS attack against PIM-SM control plane is quite easy. For example 2000 compromised hosts 2 each joining 60 channels (Si, Gi) where Si is taken in the prefix of the victim will create about 120K routing entries in the access router of the victim. IV. DETECTING DDOS ATTACKS AGAINST PIM-SM A. Detection of DDoS attacks against the Control Plane A single PIM-Join from a DDoS attack can hardly be distinguished from a legitimate one; therefore detection will be based on series of PIM-Joins. In the following we suggest some DDoS indicators. Rate of New PIM-Joins threshold (RNJ) A first criterion is the number of new PIM-Joins (that is PIM- Joins creating new entries, in contrast with cyclic PIM-Joins refreshing existing information). If more than N PIM-Joins per period of T seconds are received, an attack may be underway. Note that T must be sufficiently small to deal with precisely synchronized DDoS attack. A refinement would be a threshold RNJi per interface i (especially useful in the case of a directed attack). Number of Multicast Entries threshold (NME) Note that a low-rate DDoS may never exceed rate RNJ (or RNJ may have been overestimated in the first place). If attackers add new groups without leaving old ones, the number of trees may slowly grow arbitrarily large. To avoid this, a threshold on the number of multicast entries should be checked. This 2 A huge IRC botnet controlling more than 10,000 machines has been shut down by the security staff of Norwegian provider Telenor in 2004, according to the Internet Storm Center

4 TABLE I RECEIVER DRIVEN ATTACKS WITH SSM OR EMBEDDED-RP ASM Destination PIM-Join Active channels. of SSM Inactive or unexisting SSM channels. Active Inactive unexisting ASM or ASM Data plane impact Control plane impact Ease to launch Depends on the number of active channels. None Depends on the number of active None States in routers from attacker to first on tree router. Possible state concentration around source. Same as above. May create one source tree per active source in addition to shared tree. Concentrate state in and toward RP. Effective only with Embedded-RP. May be hard to find sufficiently many active channels. Very easy with random channels. May be hard to find sufficiently many active Easy with random Embedded-RP addresses. Possibility of Directed attack Yes, both data and control plane. Requires many active sources in the same area. Yes, select a random channel (S,G) with S in the prefix of the targeted network. Difficult to find many active groups with RPs in the same direction. Yes, select a random RP address in the prefix of the targeted network. Comment Most effective if different attackers join different channels. Same as above. Most effective if different attackers join different Requires IPv6. Same as above. threshold should be chosen such that, at this level, the router has still enough resources with a security margin (that is enough time to react before all resources are exhausted). Note that parameters RNJ and NME should not be too small to avoid false alarms. Also they give a warning but no information on which joins are suspicious. Rate of Useless PIM-Joins threshold (RUJ) As we have seen, the simplest way to launch a DDoS attack is to randomly generate PIM-Join(S,G) or PIM-Join(*,G) messages. Some of these PIM-Joins may be detected as malicious or useless PIM-Joins if they do not connect to existing sources. PIM-Joins should be considered as malicious/useless if: + No route to S (or to RP of G) exist. This could be detected in intermediate routers, for example the first one without a default route. + Host S does not exist. This could be detected by the first hop router (FHR) of S. Note that in the current multicast architecture this is not detected since the FHR does not send packets to S. However a simple extension in FHR consisting in source snooping 3 or source pinging 4 could check the existence of S. + There is no RP for G. This may occur with randomly generated Embedded-RP group addresses G containing an RP address A. It can be detected by A if A is a PIM router but not an RP for G, or it can be detected by a router B such that A is an address in a local network but A is not a PIM neighbor of B. + S exists but the channel (S, G) does not exist. Again, currently, a router has no information on potential channels, so this is impossible to check. However the MSNIP [10] proposition had a similar goal (sources register to their FHR in order to be informed of receivers on the other side of the router). With this type of mechanism, one could require that potential sources register in advance to their FHR. 3 passive service which could list active hosts in a multicast active LAN. 4 active service which could determine host presence in a LAN. + The channel or group is silent. This case is somewhat similar to the previous one. A router can easily determine if a channel or a group is silent or not. Obviously this is not an error since a receiver can join a group or channel before a source starts sending data. However, a large number of channels/groups without data should be suspicious. So for RUJ one can take as an approximation the rate of joins (on FHR or RP) for channels/groups without active source. Number of Useless PIM-Joins threshold (NUJ) Again to cope with low-rate useless PIM-Joins, a threshold on the absolute number could be useful. Some similar indicators can be recorded on the receiver side (Last Hop Router - LHR) and will be helpful in DDoS attackers localization. Note that a compromised host could send IGMP Reports with spoofed IP source addresses (and possibly MAC source addresses) so per host counters are not sufficient. Rate of IGMP-Reports per Host (RIR-H) Number of IGMP-Reports per Host (NIR-H) Rate of IGMP-Reports per Interface (RIR-I) Number of IGMP-Reports per Interface (NIR-I) In fact these counters are the first building block of a DDoS mitigation architecture, and they can be readily implemented without new protocols. B. Cost of Detection Usually a router has a rather slow CPU compared to its switching capability, so detection inside routers must have the lowest cost in terms of memory and processing overhead. The memory cost of our proposition is composed of a small number of counters and associated threshold. It is also useful to have a flag in the Tree Information Base (TIB) to record the fact that a channel/group has been detected as malicious. This way, one may avoid sending multiple warnings for the same entry. The processing cost consists in updating these various counters and flags, so it adds a few instructions per received or sent

5 PIM message. We will see in the next section how to use this detection mechanism in a global architecture. V. MITIGATING DDOS ATTACKS AGAINST THE MULTICAST ROUTING SYSTEM How is it possible to mitigate DDoS attacks using the previouly listed indicators? A first possible action is to inform a network manager by sending a trap to a management station or by logging the detected event. However this is hardly sufficient, since the available information is poor: the address of the suspicious channels and the address of the PIM neighbors sending the join messages. The network manager must then act in order to reduce the impact of that detected DDoS attack. Contrarily to such human action, an automated DDoS attack mitigation possiblity can be to filter suspicious PIM- Joins. This helps reduce the load, especially for upstream routers, but could also filter legitimate PIM-Joins and therefore create a Denial of Service by itself. Moreover detecting useless PIM-Joins is best done in FHRs or RPs, and filtering at this stage is not very useful since these PIM-Joins have reached their last hop anyway. It would be more efficient to filter PIM-Joins as close as possible to attackers, and/or to locate these attackers [14]. Note that the source address of a PIM- Join message is the address of the sending downstream PIM neighbor, not the address of the receiver nor of the LHR. So what we need is to trace the attacker back down the tree. A way to achieve this is to incorporate a feedback mechanism in PIM. In an ongoing work we have proposed such an extension of PIM [13]. A. A Feedback Mechanism for PIM-SM PIM-SM is a one way protocol: all messages (PIM- Join/Prune) flow upstream to the root, and there is a need to have some feedback flowing downstream. The principle of this feedback mechanism is based on a new general purpose PIM- SM error message called PIM-TU (PIM-Tree Unreachable). This message is generated when a PIM-SM router detects a problem with a channel/group, for example when a PIM- Join cannot be forwarded upstream. This message basically contains several debugging information such as the failed group address, the source address (in SSM case), the RP address (in the ASM case), an error code indicating the reason of the failure, and the address of the router detecting the problem. This message is then propagated hop by hop downstream in the corresponding tree. That is, it is sent to PIM routers on the outgoing interfaces of the failed channel/group. While PIM-TU messages are triggered by PIM-Join messages, they re rate limited by the total amount of these PIM-Join messages. Note that in the case of a DDoS attack with randomly generated group addresses, a router will usually have only one downstream neighbor, since there is only one attacker per channel/group. To be more efficient PIM-TU messages may aggregate information for several failures. In order to avoid sending many times the same PIM-TU message, they are cached for a duration depending on the type of error. A router with a cached PIM-TU stops sending periodic PIM- Joins upstream. In effect the upper part of the tree will be flushed for the caching duration. Because PIM-TU message is generated by PIM-Joins, our system is designated Therefore permanent errors (or PIM-Joins pertaining to DDOS attacks) should have a very long caching duration. Note however that too long a caching time may be a problem if these PIM- Joins are legitimate. Caches should be implemented as far downstream as possible. This means whenever possible the cache should be located in the LHR of receivers. If PIM-Joins were received from untrusted neighboring domains (or from domains not implementing this mechanism), caches should be implemented in border routers. Assuming that the above briefly described mechanism is available, we propose in this paper to use it to mitigate DDoS attacks against PIM-SM. We need to add a new DDoS flag to the PIM-TU message indicating that the corresponding groups/channels are suspected to participate in a DDoS attack. The normal failure field is also filled in if the corresponding PIM-Join failed (no RP for example). Our proposition can be described in three steps: -attack detection, -downstream warning, -filtering and/or logging. B. Attack Detection As seen before, detection is based on thresholds associated to PIM-Join message counters. Assuming that these thresholds are correctly set (for a given router or network), the attack will be detected only some times after its beginning because of PIM-Join statistics collection. When an attack is detected, all suspicious new PIM-Joins will be flagged, and a PIM-TU message will be sent down the tree with the DDoS flag set. This message will be called PIM-DDoS for short afterwards. Note that one cannot be sure that a given PIM-Join participates in an attack even if we are sure that there is an attack. If the attack has been detected by an overall number of PIM- Joins, one cannot distinguish between legitimate and malicious PIM-Joins. For example if the attack has been detected with the useless PIM-Join threshold RUJ, all new useless joins are suspicious. C. Downstream Warning When a router R2 receives a PIM-DDoS message from an upstream neighbor R1, R2 keeps it in cache and forwards it to its downstream neighbor for the concerned channel/group. Additionally, for this channel/group, R2 may stop sending PIM-Joins for a duration depending on the failure reason. So the corresponding routing entry will disappear upstream and resources will be released. It is also possible that intermediate routers (such as R2) receiving a high rate of PIM-TU messages (without DDoS flag) decide that an attack occurs. This would be the case if thresholds on upstream routers are too high or this DDoS mechanism is not implemented/activated. This could be also the case in a global attack (not a directed attack), if the router is at the crossroad of many useless trees. Remember that useless trees are best detected at the RP or FHR, but in a global attack the number of useless trees may

6 be low in any RP or FHR. In this case this router may add the DDoS flag before propagating the PIM-TU message. In addition routers may log such messages. This analysis shows that there is a need for a new counter Number of (non DDoS) PIM-TU messages (NTU) D. Filtering When a router receives a PIM-DDoS message for a channel/group such that at least one downstream interface has either a directly connected receiver (i.e. sending IGMP-Reports) or an untrusted neighbor (i.e. in another domain), the message is analyzed more finely. If this message corresponds to a failed PIM-Join (e.g. source not reachable), it is cached for a long time and in the mean time, corresponding periodic joins will be suppressed, thereby flushing the corresponding state in upstream routers and increasing resources. If this PIM-DDoS message does not correspond to a failed PIM-Join (e.g. the PIM-Join could be forwarded but the rate of new PIM-Joins exceeded the NE or RNJ thresholds) the router has to decide whether it is a malicious PIM-Join message or not. Basically this can be done with a threshold on the rate of received PIM- DDoS. This threshold could be relatively low, since we are on the potential attacker side. If the number of PIM-DDoS is low, one can decide that they do not participate in an attack, and do not suppress upstream PIM-Joins: associated states will not be suppressed. If this number is above a threshold one can decide that they do participate in an attack, cache them and suppress upstream joins. Note that it is possible that a fraction of these PIM-Joins were legitimate. In this case they will be denied the service. Among other things that can be done is to log the IP and Mac Address of hosts sending IGMP-Reports corresponding to malicious PIM-Joins. This way the network administrator could rapidly locate participating hosts and filter them out. E. Possible Deployment and other Tools The DDoS mitigation architecture proposed in this paper is based on two parts: counters, threshold, logging and possibly automatic filtering. These tools can be implemented independently by router manufacturers. Note that similar tools are already available for the detection of other types of attacks. a feedback mechanism helping to trace back an attack and position filter as close as possible to attackers. In the current PIM-SM protocol specification this piece is missing. This is why we propose the PIM-TU mechanism. Note that a multicast traceroute has been in the work for some time [9], but it works upstream, from a receiver up to a possible point of failure, and could hardly be used to trace back receivers. In addition, to improve useless PIM-Join detection a signaling mechanism between sources and FHR such as MSNIP [10] would be very helpful although not mandatory. Alternatively, in some environments, a set of legitimate sources could be configured in the FHR, using some kind of access control lists. In this case, a PIM-Join for a source outside of this set would be considered useless, or more precisely administratively prohibited. VI. CONCLUSION AND FURTHER WORK We have shown that the multicast routing architecture with PIM-SM could easily be the victim of a DDoS attack from receivers. This can become a great concern with the increasing use of IP multicast. Since MSDP is very vulnerable to sender attacks it should be abandoned. The other possibility with ASM is to use the Embedded-RP addresses, but this requires using IPv6. Also, sender attacks are better controlled if an RP is used only for a limited number of groups and known sources, which is not possible for all multicast applications. And if sources are known in advance, SSM can easily be used instead of ASM. So it seems that SSM is the best solution to prevent sender attacks. To fight receiver attacks a tracing mechanism is needed and we propose to use a PIM- SM extension to do that. Note that such a mechanism is also useful for other management purposes too. Much work has still to be done. One practical but difficult problem is the definition of the different thresholds, since a high threshold will not detect attacks while low thresholds may block legitimate users. Another point is to analyze the cost of this architecture, since it creates new signaling and new states in routers. REFERENCES [1] S. Deering, Host extensions for IP multicasting, RFC 1112, Aug [2] B.Fenner, M.Handley, H.Holbrook, I.Kouvelas, Protocol Independent Multicast - Sparse Mode (PIM-SM): Protocol Specification (Revised), RFC 4601, Aug [3] H.Holbrook, B.Cain, Source Specific Multicast for IP, RFC 4607, Aug [4] B.Cain, S.Deering, B.Fenner, A.Thyagarajan, Internet Group Management Protocol, Version 3, RFC 3376, Oct [5] R.Vida and L.Costa, Multicast Listener Discovery Version 2 (MLDv2) for Ipv6, RFC 3810, Jun [6] T.Bates, R.Chandra, D. Katz, Y.Rekhter, Multiprotocol Extensions for BGP-4, RFC 2283, Feb [7] D.Meyer and B.Fenner, Multicast Source Discovery Protocol, RFC 3618, Oct [8] P.Savola, B. Haberman, Embedding the Rendezvous Point (RP) Address in an IPv6 Multicast Address, RFC 3956, Nov [9] H.Asaeda, T.Jinmei, W. Fenner, S.Casner, Mtrace Version 2: A traceroute facility for IP multicast - Internet Draft, draft-asaeda-mbonedmtrace-v2-00.txt, Jul [10] B.Fenner, B.Haberman, H.Holbrook, I.Kouvelas, Multicast Source Notification of Interest Protocol - Internet Draft, draft-ietf-magma-msnip- 05.txt, Jun [11] I. Hamadeh, J. Hart, G. Kesidis, V. Pothamsetty, A Preliminary Simulation of the Effect of Scanning Worm Activity on Multicast, Proceedings of the Workshop on Principles of Advanced and Distributed Simulation (PADS 05), Jun. 05 [12] P. Savola, R. Lehtonen, D. Meyer, Protocol Independent Multicast? Sparse Mode (PIM-SM) Multicast Routing Security Issues and Enhancements, RFC 4609, Aug [13] B.Hilt, J.-J.Pansiot, M.Hoerdt, Join failure notification for PIM-SM multicast routing, draft-hilt-pim-tree-unreachability-00.txt, May 2007 [14] C.Gong, T.Le, T.Korkmaz, K.Sarac, Single Packet IP Traceback in ASlevel Partial Deployment Scenario, Global Telecommunication Conference 2005 (GLOBECOM 05), Nov [15] P. Savola, J. Lingard, Last-hop threats to Protocol Independent Multicast (PIM), draft-ietf-pim-lasthop-threats-01.txt, Jun. 2007