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 Must know of at least one I3 server Unreliable service

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.

Functionality

Anycast Typical usage: same access point availabl

e 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?

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 clien

t itself. Service composition is trivial to do anyway. Suc

h as the server do it self, or use a proxy. Actually, Users can decide what to do. E.g. Goog

le’s dynamic web page translation.

Usability “Thus, it is important that it not require ex

tensive 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 kno

wing about the overlay

Security “…our goal is to design simple and efficien

t 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

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.

Security

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

HT based systems

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

Security

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…

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?

UDP and TCP Supposedly I3 should work with unmodifie

d applications UDP is the only transport mechanism that c

an 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 av

erage, up to 30s

UDP and TCP

Higher RTT, lower throughput

Triangular routing For multicast, anycast, or high mobility IP t

he sample based approach cannot work How well the sampling works depend on th

e distribution of latency. Latency is not the single metrics the client n

eeds. Loss rate, link available bandwidth, etc.

May conflict with load balancing Basically, end hosts are responsible for rout

ing

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?

Poor Evaluation

Multicast? “Since we didn’t enable multicast, in o

ur 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 wo

rked for the situations they were trying to address?

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

Poor Evaluation

Comparison(?) Absolutely none, but it is just a proof of c

oncept How well does it work compared to other

overlays? How well does it work compared to just r

egular IP?

Practicality “We don’t know what the economic mod

el 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.”

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?

Multiple Providers

We just saw that BGP is totally kludged together to take into account multiple providers’ policy…

I3 takes all that away

Cooperative non-profit

Might Work As long as nobody uses it Someone, somewhere is going to have to

pay for it

Overall

An interesting research paper But still far from practical