Internet Indirection Infrastructure

This paper describes an overlay-based Internet routing service built over the primitives of a DHT. Addresses in the overlay address consistent of two pieces, one which must match exactly and the other which is matched to the closest (longest prefix match) available address when routing messages. Receivers arrange to have an address routed to them by inserting a mapping (called a trigger) from an overlay address to some list of (overlay or IP) addresses. When a message is sent to an overlay address, these triggers are found, and for each trigger, the message is forwarded to the first functional address, passing along any left-over addresses in the trigger as metadata. These triggers are expired unless refreshed periodically and can be removed only if the destination-part is known. Conflicts in address assignment are avoided by using a sufficiently large address space.

The paper envisions that this addressing mechanism can be used to implement many commonly requested routing services:

• mobility — the mobile host simply maintains a trigger with a permanent address, arranging for it to point to its current real address;
  
• multiast — each subscribing host inserts a trigger for the multicast address (or, for large multicast groups, the hosts can arrange for a tree of triggers);
  
• anycast — endpoint encode their preferences in the inexactly matched portion of the address and ensure that exactly one trigger is the closest match;
  
• service composition — the end-host wishing to insert the service inserts a trigger listing the service, then itself; the service agrees to forward the message to the address it receives as metadata;
  

The implementation of this primitive over a Chord DHT assigns responsibility for routing to an overlay address to the Chord node responsible for the corresponding key in Chord's keyspace. (To allow closest-match routing, exactly all addresses with the same exact-match portion correspond to the same Chord key.) The responsible Chord node forwards all data destined for the overlay address in question. This routing scheme poses some performance concerns. The chosen intermediate server may be a poor choice, routing traffic between relatively close hosts through a far-away or slow router. To avoid this the authors propose using separate addresses for connection setup (done with a public address) than for the connection itself (which uses a temporary private address); the private address can be chosen to fall into the range a nearby server is responsible for (presumed to be discovered by querying the addresses of nearby servers in the DHT). Another concern is overloading a DHT node responsible for a popular public address; the authors believe they can address this by caching the associated triggers along the lookup path.

Other concerns about this system are ones of security. The most obvious issue is that the flexibility to implement multicast comes with the ability to send massive amounts of duplicitous traffic to a victim host. The authors propose sending challenges to the trigger's mapped address to assure that the address to which triggers map actually permits the mapping. For cases where the victim is the infrastructure itself, the authors propose assigning resources based on the end-host inserting the trigger and detecting loops using either test packets or a bloom filter to mark visited hosts.

The authors also address concerns of eavesdropping or hijacking communications using the triggers. The authors argued that random private triggers would prevent eavesdropping attacks because a malicious third-party would need to guess the private trigger. Similarly, the authors would prevent hijacking by having the public trigger merely forward to a (hopefully unguessable) private trigger required to remove the public.

I felt that these security concerns would be better solved by using a traditional cryptographic end-to-end solution for hijacking and eavesdropping concerns (perhaps by encoding public keys in the public triggers) and authentication for trigger-removal requests. The authors wish i3 to be a relatively configuration-free system distributed between multiple administrative domains, to achieve these goals, almost any party should be able to run an i3 node. Given this, it seems a more viable attack would be to collect triggers by running (perhaps many) i3 nodes; since the trigger's values will be distributed at random among the i3 nodes and forwarded to other i3 nodes for caching, an attacker should be able to get the values of many private triggers.