1 / 26

Criticisms of I3

Criticisms of I3. Zhichun Li. General Issues. Functionality Security Performance Practicality If not significant better than existing schemes, why bother?. Limitations or design principle. Subscription based model of communication Must know the IDs to subscribe to

jam
Download Presentation

Criticisms of I3

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  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 i3can 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

More Related