on behalf of the applications. The applications do not need to be private trigger ido, and sends this trigger back to A over As private and translated by the i3 proxy transparently. As a proof of concept, cannot impersonate e nder's trigger is encrypted, a malicious user modified, and are unaware of the 23 proxy. Packets are intercepted trigger id(. Since th we have implemented the heterogeneous multicast application pre ented in Section 3.2 over 3. The sender sends a MPEG stream, 4.10.2 Trigger hijacking and one receiver plays back with a MPEG player(mpeg -play) and A malicious user can isolate a host by removing its public trigger. the other with a H 263 player(tmndec), as shown in Figure 7 Similarly, a malicious user in a multicast group can remove other In [38], we present a solution using i3 to provide mobility support members from the group by deleting their triggers. While removing for TCP-based legacy applications a trigger also requires to specify the IP address of the trigger, this address is, in general, not hard to obtain 4.10 Security One possibility to guard against this attack is to add another level Unlike IP, where an end-host can only send and receive pack of indirection. Consider a server S that wants to advertise a public ets, in i3 end-hosts are also responsible for maintaining the routing trigger with identifier idp. Instead of inserting the trigger aidpc S), information through triggers. While this allows flexibility for ap. the server can insert two triggers, aidpea) and arcS), where r is an plications, it also(and unfortunately creates new opportunities fo identifier known only by S. Since a malicious user has to know malicious users. We now discuss several security issues and how in order to remove either of the two triggers, this simple i3 addresses them provides effective protection against this type of attack We emphasize that our main goal here is not to design a bullet performance penalties, the receiver can choose a such proof system. Instead, our goal is to design simple and efficient aidpe= )and a cS)are stored at the same server. With the current solutions that make i3 not worse and in many cases better than implementation this can be easily achieved by having id, an oday's Internet. The solutions outlined in this section should be share the same k-bit prefi viewed as a starting point towards more sophisticated and better security solutions that we will develop in the future 4.10.3 DoS attacks The fact that 23 gives end-hosts control on routing opens new 4.10./ Eavesdropping possibilities for Dos attacks. We consider two types of attacks: (a Recall that the key to enabling multicast functionality is to al- attacks on end-hosts, and(b) attacks on the infrastructure. In the low multiple triggers with the same identifer. Unfortunately, a ma- former case, a malicious user can insert a hierarchy of triggers(see ous user that knows a hosts trigger can use this flexibility to Figure 5)in which all triggers on the last level point to the victim eavesdrop the traffic towards that host by simply inserting a trig ger with the same identifier and its own address. In addressing thi will cause the packet to be replicated and all replicas to be sent problem, we consider two cases:(a)private and(b)public triggers to the victim. This way an attacker can mount a large scale D (see Section 4.2) attack by simply leveraging the 23 infrastructure. In the later case, malicious user can create trigger loops, for instance by connecting Private triggers are secretly chosen by the application end-points the leaves of a trigger hierarchy to its root. In this case, each packet and are not supposed to be revealed to the outside world. The lengt of the trigger' s identifier makes it difficult for a third party to use sent to the root will be exponentially replicated! a brute force attack. While other application constraints such as To alleviate these attacks, 23 uses three techniques toring a trigger at a server nearby can limit the identifier choice, 1. Challenges: 23 assumes implicitly that a trigger that points the identifier is long enough (i.e, 256 bits), such that the appli- to an end-host R is inserted by the end-host itself. An 23 cation can always reserve a reasonably large number of bits that server can easily verify this assumption by sending a chal- are randomly chosen. Assuming that an application chooses 128 nge to R the first time the trigger is inserted. The challenge random bits in the trigger's identifier, it will take an attacker 2 27 consists of a random nonce that is expected to be returned by probes on the average to guess the identifier. Even in the face of the receiver. If the receiver fails to answer the challenge a distributed attack of say one millions of hosts, it will take about trigger is removed. As a result an attacker cannot use a hier- per host to guess a private rchy of triggers to mount a dos attack (as described above), lote that the technique of using random identifiers as probabilistic the leaf triggers will be removed as soon as the server secure capabilities was previously used in(28, 371 detects that the victim hasnt inserted them Furthermore, end-points can periodically change the private trig 2. Resource allocation: Each server uses Fair Queueing [7to ers associated with a flow Another alternative would be for the locate resources amongst the triggers it stores. This way receIv th the damage inflicted by an attacker is only proportional to the sender to send packets randomly to one of these private triggers the number of triggers it maintains. An attacker cannot sim- he alternative left to a malicious user is to intercept all private trig oly use a hierarchy of triggers with loops to exponentially gers. However this is equivalent to eavesdropping at the IP level or increase its trafic. As soon as each trigger reaches its fair taking control of the 23 server storing the trigger, which makes 23 share the excess packets will be dropped. While this tech- no worse than IP nique doesn't solve the problem, it gives i3 time to detect With 23, a public trigger is known by all users in the system, and and to eventually break the cycles thus anyone can eavesdrop the traffic to such a trigger. To alleviate To increase protection, each server can also put a bound on this problem, end-hosts can use the public triggers to choose a pair the number of triggers that can be inserted by a particular of private triggers, and then use these private triggers to exchange end-host. This will preclude a malicious end-host from mo- the actual data. To keep the private triggers secret, one can use public key cryptography to exchange the private triggers. To initiate 5Note that an attacker can still count the I onnection, a host A encrypts its private trigger id( under the quests to B. However, this information ery limited use, if any. to the attacker. If. in the future. it that this is un- public key of a receiver B, and then sends it to B via B's public acceptable for some applications, then other security mechanisms trigger.b decrypts A,s private trigger id, then chooses its own such as public trigger authentication will need to be usedon behalf of the applications. The applications do not need to be modified, and are unaware of the ☎✝✆ proxy. Packets are intercepted and translated by the ☎✝✆ proxy transparently. As a proof of concept, we have implemented the heterogeneous multicast application pre￾sented in Section 3.2 over ☎✝✆. The sender sends a MPEG stream, and one receiver plays back with a MPEG player (mpeg play) and the other with a H.263 player (tmndec), as shown in Figure 7. In [38], we present a solution using ☎ ✆ to provide mobility support for TCP-based legacy applications. 4.10 Security Unlike IP, where an end-host can only send and receive pack￾ets, in ☎ ✆ end-hosts are also responsible for maintaining the routing information through triggers. While this allows flexibility for ap￾plications, it also (and unfortunately) creates new opportunities for malicious users. We now discuss several security issues and how ☎✝✆ addresses them. We emphasize that our main goal here is not to design a bullet proof system. Instead, our goal is to design simple and efficient solutions that make ☎✝✆ not worse and in many cases better than today’s Internet. The solutions outlined in this section should be viewed as a starting point towards more sophisticated and better security solutions that we will develop in the future. 4.10.1 Eavesdropping Recall that the key to enabling multicast functionality is to al￾low multiple triggers with the same identifer. Unfortunately, a ma￾licious user that knows a host’s trigger can use this flexibility to eavesdrop the traffic towards that host by simply inserting a trig￾ger with the same identifier and its own address. In addressing this problem, we consider two cases: (a) private and (b) public triggers (see Section 4.2). Private triggers are secretly chosen by the application end-points and are not supposed to be revealed to the outside world. The length of the trigger’s identifier makes it difficult for a third party to use a brute force attack. While other application constraints such as storing a trigger at a server nearby can limit the identifier choice, the identifier is long enough (i.e., ▲✤◆✎❖ bits), such that the appli￾cation can always reserve a reasonably large number of bits that are randomly chosen. Assuming that an application chooses ◗☛▲✬❙ random bits in the trigger’s identifier, it will take an attacker ▲ ■ ✮✁￾ probes on the average to guess the identifier. Even in the face of a distributed attack of say one millions of hosts, it will take about ▲ ■ ✮✁￾ ✺ ✮✄✂ ❏ ▲ ■ ✂☎￾ probes per host to guess a private trigger. We note that the technique of using random identifiers as probabilistic secure capabilities was previously used in [28, 37]. Furthermore, end-points can periodically change the private trig￾gers associated with a flow. Another alternative would be for the receiver to associate multiple private triggers to the same flow, and the sender to send packets randomly to one of these private triggers. The alternative left to a malicious user is to intercept all private trig￾gers. However this is equivalent to eavesdropping at the IP level or taking control of the ☎✝✆ server storing the trigger, which makes ☎✝✆ no worse than IP. With ☎✝✆, a public trigger is known by all users in the system, and thus anyone can eavesdrop the traffic to such a trigger. To alleviate this problem, end-hosts can use the public triggers to choose a pair of private triggers, and then use these private triggers to exchange the actual data. To keep the private triggers secret, one can use public key cryptography to exchange the private triggers. To initiate a connection, a host ✏ encrypts its private trigger ☎✦✸✷ under the public key of a receiver ✑, and then sends it to ✑ via ✑’s public trigger. ✑ decrypts ✏’s private trigger ☎❅✸✷ , then chooses its own private trigger ☎✦✸✓ , and sends this trigger back to ✏ over ✏’s private trigger ☎✦✸✷ . Since the sender’s trigger is encrypted, a malicious user cannot impersonate ✑. 5 4.10.2 Trigger hijacking A malicious user can isolate a host by removing its public trigger. Similarly, a malicious user in a multicast group can remove other members from the group by deleting their triggers. While removing a trigger also requires to specify the IP address of the trigger, this address is, in general, not hard to obtain. One possibility to guard against this attack is to add another level of indirection. Consider a server ✲ that wants to advertise a public trigger with identifier ☎❅✸✣ . Instead of inserting the trigger ✷ ☎❅✸✣ ✹ ✲✻ , the server can insert two triggers, ✷ ☎❅✸✤✣❂✹✡✧ ✻ and ✷★✧ ✹ ✲✻ , where ✧ is an identifier known only by ✲. Since a malicious user has to know ✧ in order to remove either of the two triggers, this simple technique provides effective protection against this type of attack. To avoid performance penalties, the receiver can choose ✧ such that both ✷ ☎❅✸✣✘✹ ✧ ✻ and ✷★✧ ✹ ✲✢✻ are stored at the same server. With the current implementation this can be easily achieved by having ☎❅✸✣ and ✧ share the same ❉-bit prefix. 4.10.3 DoS Attacks The fact that ☎✝✆ gives end-hosts control on routing opens new possibilities for DoS attacks. We consider two types of attacks: (a) attacks on end-hosts, and (b) attacks on the infrastructure. In the former case, a malicious user can insert a hierarchy of triggers (see Figure 5) in which all triggers on the last level point to the victim. Sending a single packet to the trigger at the root of the hierarchy will cause the packet to be replicated and all replicas to be sent to the victim. This way an attacker can mount a large scale DoS attack by simply leveraging the ☎✝✆ infrastructure. In the later case, a malicious user can create trigger loops, for instance by connecting the leaves of a trigger hierarchy to its root. In this case, each packet sent to the root will be exponentially replicated! To alleviate these attacks, ☎✝✆ uses three techniques: 1. Challenges: ☎✝✆ assumes implicitly that a trigger that points to an end-host ✶ is inserted by the end-host itself. An ☎✝✆ server can easily verify this assumption by sending a chal￾lenge to ✶ the first time the trigger is inserted. The challenge consists of a random nonce that is expected to be returned by the receiver. If the receiver fails to answer the challenge the trigger is removed. As a result an attacker cannot use a hier￾archy of triggers to mount a DoS attack (as described above), since the leaf triggers will be removed as soon as the server detects that the victim hasn’t inserted them. 2. Resource allocation: Each server uses Fair Queueing [7] to allocate resources amongst the triggers it stores. This way the damage inflicted by an attacker is only proportional to the number of triggers it maintains. An attacker cannot sim￾ply use a hierarchy of triggers with loops to exponentially increase its traffic. As soon as each trigger reaches its fair share the excess packets will be dropped. While this tech￾nique doesn’t solve the problem, it gives ☎✝✆ time to detect and to eventually break the cycles. To increase protection, each server can also put a bound on the number of triggers that can be inserted by a particular end-host. This will preclude a malicious end-host from mo- ✆ Note that an attacker can still count the number of connection re￾quests to ✑. However, this information is of very limited use, if any, to the attacker. If, in the future, it turns out that this is un￾acceptable for some applications, then other security mechanisms such as public trigger authentication will need to be used