1. Criticisms of I3 Zhichun Li

2. General Issues Functionality Security Performance Practicality If not significant better than existing schemes, why bother?

3. Limitations or design principle Subscription based model of communication Must know the IDs to subscribe to Must know of at least one I3 server Unreliable service

4. Functionality Multicast Why people disable IP multicast on their routers? Archive similar functionalities of existing IP multicast. Do not have the advantage on security, billing, quality of service and traffic control etc. Much less efficient than IP multicast Still need to build a multicast tree, but only use i3 overlay nodes as middle nodes, may not be as efficient as some end-to-end multicast. E.g. a group of receivers behind a bottleneck.

5. Functionality Anycast Typical usage: same access point available in different ISPs. Such as a IP4to6 gateway Load balancing, efficiency, policy, easy to use In i3, all the receivers share a same k bit prefix, so map to a SINGLE i3 server. Efficientcy? Load balancing?

6. Functionality Mobility Similar to Mobile IP No new feature compare to Mobile IP Service Composition It is good for service composition But the server needs to identify the type of client itself. Service composition is trivial to do anyway. Such as the server do it self, or use a proxy. Actually, Users can decide what to do. E.g. Google ’ s dynamic web page translation.

7. Usability “Thus, it is important that it not require extensive manual configuration or human intervention.” “…end-hosts wishing to use i3 can locate at least one server using a similar bootstrapping technique; knowledge of a single server is all that’s needed to fully utilize the i3 infrastructure.” This is misleading A lot of their features depend on end hosts knowing about the overlay

8. Security “…our goal is to design simple and efficient solutions that make i3 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.” It may be worse

9. Security Why user should trust the i3 infrastructure? A server claim it is a i3 node, how we verify? Security of i3 infrastructure What if hackers compromise i3 nodes? Can interposition all the packets routed by them! Change the triggers What if hackers DoS some i3 nodes? Cache expose the IP of i3 nodes.

10. Security Security of underlying infrastructure (DHT) DHT itself could have vulnerabilities. There are some attacks specialized for DHT based systems

11. Security Types of attacks on i3 (proposed in ACM PODC ’ 04) Eavesdropping and Impersonation (id,X) (id,H) I3 still allows users to receive anything they want, hiding the channel just makes it harder to find IP does not have eavesdropping capabilities DESIGNED into the system Malicious Linking Point traffic to (id, R) Cycles (id1,id2) (id2,id3) (id3,id1) Confluence Multicast tree & malicious links Easy if the client is in the system (id, R) Dead-ends Point to nothing

12. Security

13. Anonymity Anybody can listen to a common trigger Back tracing to the sender is then possible Solutions: Encryption or trigger chains Adds overhead Nobody knows how much…

14. Performance So how well is this going to work? Well, nobody really knows. They say its only a proof of concept Carrier pigeons have also been proven to work And does it even succeed as a proof of concept?

15. UDP and TCP Supposedly I3 should work with unmodified applications UDP is the only transport mechanism that can use I3. (Section 4.9) TCP would be broken Multiple receivers End host failures aren’t detected Congestion avoidance and flow control don’t work End host failures not detected for 15s on average, up to 30s

16. UDP and TCP Higher RTT, lower throughput

17. Triangular routing For multicast, anycast, or high mobility IP the sample based approach cannot work How well the sampling works depend on the distribution of latency. Latency is not the single metrics the client needs. Loss rate, link available bandwidth, etc. May conflict with load balancing Basically, end hosts are responsible for routing

18. Poor Evaluation Verify the simulator by real experiments? From Results of two generated topologies, may not infer how it works on real Internet 1Gbps link only can archive 261.38Mbps in maximum?

19. Poor Evaluation Multicast? “Since we didn’t enable multicast, in our experiments there was never more than one address.” All they tested was point to point traffic… Why do we need this for point to point? Shouldn’t they have at least checked if it worked for the situations they were trying to address?

20. Poor Evaluation WAN? “The nodes communicated over a shared 1 Gbps Ethernet.” Isn’t this supposed to work over the WAN We see how the overhead effects the system… At least the overhead they implemented…. But that’s it A lot of stuff wasn’t even tested… Triangular routing problems Node failures Trigger chaining

21. Poor Evaluation Comparison(?) Absolutely none, but it is just a proof of concept How well does it work compared to other overlays? How well does it work compared to just regular IP?

22. Practicality “We don’t know what the economic model of would be and whether its most likely deployment would be as a single provider for- profit service (like content distribution networks), or a multiprovider for-profit service (like ISPs), or a cooperatively managed nonprofit infrastructure.” “…i3 faces significant hurdles before ever being deployed.”

23. Single Provider Akamai like service model Akamai has servers all over the world Akamai is transparent to the end user Now end users has install some client to use i3 Will the business model support this level of infrastructure?

24. Multiple Providers We just saw that BGP is totally kludged together to take into account multiple providers’ policy… I3 takes all that away

25. Cooperative non-profit Might Work As long as nobody uses it Someone, somewhere is going to have to pay for it

26. Overall An interesting research paper But still far from practical