Post on 04-Jan-2016
description
transcript
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