Scott Weber
CSE 498

Review of "Internet Indirection Infrastructure"

The Internet's infrastructure is very good at delivering unicast packets from their single source to their single destination.  However, new routing and delivery ideas have pushed beyond the effective limits of the infrastructure currently in place in the Internet.  Delivery methods such as multicast, anycast and concast require new infrastructure support and careful deployment to be effective and widely available.  Several ways to deploy these new methods into the current Internet have been suggested, but none have been widely accepted.  The authors of this paper propose a new solution that could provide these new services with little impact on the existing infrastructure.

The authors have chosen to follow the old adage that any computer science problem can be solved simply by adding a level of indirection.  Their Internet Indirection Infrastructure (i3) provides a way to address packets without knowing their actual destination.  A server or network of servers become a central location for mappings from ids to IP addresses.  Very few constraints are placed on the id mappings, so problem such as multicast become trivial: just map multiple IP addresses to a single id; all packets sent to the id will be delivered to every mapped IP address.  A receiver is responsible for adding the id to IP address mapping for itself into the i3 network.  When a sender wishes to contact a recipient, it will send the packet to the i3 network along with the destination id.  The i3 network is then responsible for determining the IP address(es) of the final recipient(s) and delivering the packet to it (them).

The i3 network does not bother itself with determining the most effective mapping or mappings to deliver the packet or packets, this responsibility is left to the clients.  For example, if a group of clients want to join a multicast group, the group is responsible for setting up an appropriate multicasting tree.  The clients are also responsible for determining the id under which they will be registered.  This reliance on the client is a whole through which many security problems could arise.  In fact, several of the security issues are addressed in the paper.  Even beyond the security implications, it is difficult to believe that the clients have enough knowledge to be trusted with this responsibility.  For example, what if a client inadvertently chooses an id that has already been registered?  This would be a valid registration, i3 would consider it as an attempt to do multicasting.  However, multicast may not be the intended result ! of the client.

Another feature of i3 is the use of inexact matching.  This way, the id of an incoming packet need only match a certain amount of the entirety with a mapped id in order to be considered a match.  For example, a 256-bit id may only be required to match 128 bits for a valid match.  This causes a problem that could lead to inappropriately delivered packets.  A source may send a packet with some id that has just been removed from the mapping table deliberately or inadvertently.  When the packet arrives at i3, it may end up being matched to a different id that is close to the desired one, but who's mapping leads to a very different receiver.  Thus, the packet is delivered to a very wrong destination without the sender even knowing.  This is a major security risk.

The authors suggested implementation of anycast using i3 relies heavily on the inexact matching technique discussed above.  Another problem with this idea is that anycast could actually degrade to multicast.  This clearly violates the statement that "anycast ensures that a packet is delivered to exactly one receiver."  A sender may deliver a packet to some anycast id that, due to inexact matching, actually matches to two of the possible five destinations.  The packet would be delivered to more than one receiver.  Anycast has been defined with both at most one and at least one semantics in other research and standards, but the definition in this paper is violated easily due to inexact matching and the lack of checking done by i3 itself.

The paper does a poor job of describing how any return packets are delivered to the original source.  It does mention a new handshaking mechanism by which each end exchanges ids as communication begins, but does not state whether this is a general solution that would have to be implemented by all hosts using i3, or whether this is a special situation.  It is also unclear whether the packets arriving at the receiver appear to come from the original sender or from i3 itself.

When describing security, the authors claim that an attacker who "sniffs" packets by simply registering all ids, thereby transparently receiving all traffic through i3, is no more of a security risk since this could simply be done by snooping at the IP level or taking control of an i3 server.  This is not quite true.  By registering all ids, an attacker leverages the i3 network to deliver all traffic into his own network.  Without this, an attacker would have the much more difficult task of asserting himself into the i3 network at some point.  By simply registering a few mappings with i3, all the traffic delivered directly to the attacker, saving him a lot of difficult work.

The biggest problem, which is described as a feature, of i3 is the possibility for id collision.  While it is useful to allow multiple mappings from a single id for such services as multicast, it could cause many more problems.  Traffic can easily be accidentally, or deliberately, misdirected.  The end-to-end semantics of the Internet are destroyed by i3.  The sender has no idea where packets sent are actually delivered, and the receiver does not know from where they came.

This paper presents a very neat idea about how to solve many of the routing issues being faced by those developing new delivery techniques and ideas.  Many security issues remain unfixed and perhaps unfixable without some kind of authentication.  Even so, I find this idea intriguing and worth exploring.  I would absolutely recommend this paper for reading by others.

REFERENCE
Ion Stoica, Daniel Adkins, Shelley Zhuang, Scott Shenker and Sonesh Surana. "Internet Indirection Infrastructure." Proceedings of ACM SIGCOMM, pages 73-88, August 2002.