Scott Weber
CSE 498

Review of "A Waypoint Service Approach to Connect Heterogeneous Internet Address Spaces"

As the IPv4 available address space shrinks, many solutions have been proposed and some implemented, to allow more computers to connect to the Internet.  IPv6 is the standardized long-term solution, but it's deployment is difficult and will not happen quickly.  One of the stop-gap solutions to get more computers online with fewer addresses has been network address translation (NAT).  Unfortunately, computers behind a NAT gateway can only participate in one-way communications.  In general, computers in the globally addressable Internet cannot initiate communication with a host behind a gateway, it only works the other way around.  A similar problem exists for IPv6 only hosts since IPv6 addresses are not routeable in the IPv4 Internet.  This paper proposes a system called AVES that facilitates communication in both directions across a NAT gateway with minimal impact to the current infrastructure of the Internet.

The AVES system makes use of modified DNS servers and waypoint machines that forward requests to their destination.  Each host behind the NAT gateway is given a unique hostname under a domain.  When a host in the global address space wants to contact a host behind the gateway, it will issue a request for it's IP from the DNS server.  The DNS server will register this request with a waypoint server and then return the IP of the waypoint to the client.  The client will then talk to the waypoint as if it were the destination server.  The waypoint is responsible for tunneling the packets to the NAT gateway, which in turn delivers them to the final destination.  So, the three pieces of software that must be modified are the DNS server, the waypoint and the NAT gateway.  Since so little software must be modified and all of this software usually lands under the same administrative domain and the administrators of these systems will directly benefi! t, it is probable that a system like this would be easily adopted.

The authors continually tout the "unlimited" or very high limit on connections possible with the waypoint system.  They neglect to mention the system limitations on open file descriptors or the practical limitations due to processing time and overhead.

As described, the system relies on DNS responses not being cached.  The TTL is explicitly set to zero and all clients are assumed to respect that.  However, some DNS servers ignore low TTLs and client software generally ignore all TTLs.  Thus a client-to-waypoint mapping may stick around in a cache for quite some time.  Consider a client that has an IP for a waypoint W to talk to server A.  If the mapping expires on the waypoint, and then a new mapping is created from the same client to server B on the same W, problems could arise.  The client may then use its originally cached IP, thinking it is talking to server A when in fact it will be delivering packets to server B.  This may be a rare occurrence, but it is not just a nuisance, it could be a security problem if sensitive data is unknowingly delivered to the wrong host.

The waypoint mechanism explicitly generates asymmetric routes.  The route to the server passes through the waypoint, while the route from the server bypasses the waypoint.  While this is not an issue for most uses, there are some protocols, like network time, that are sensitive to routing differences and may suffer unacceptable performance.

The Setup/Accept exchange that takes place on every DNS query is bound to increase the user-experienced latency of a lookup.  In some cases, this could result in requests being resent even though it was not lost, simply delayed.  While on the surface, this seems to be a problem, it may actually turn out to be a valuable process.  For example, a request that is taking too long to complete is probably due to an overloaded waypoint that does not have time to respond to the server.  Therefor, when the request is reissued and the DNS server chooses a new waypoint, the client is directed toward a less loaded server.  While there is no intelligence built in, it may show itself accidentally.

The general application of this technology requires that a waypoint assume that the first connection after a DNS Setup request comes from the same client that initialized the process.  The authors admit that this is a security weakness, as a carefully timed packet could hijack the session initialized by another client.  Their solution to this problem is to punish those hosts who seem to be misbehaving harshly to discourage them.  When a request comes in during a time that it is not expected, the requesting host is blacklisted for three hours.  This will probably keep automated scanning attacks from being viable.  However, it may also have negative consequences.  For example, a host that takes a little too long getting its packet to the waypoint after receiving the DNS response would be blacklisted, as would a host using a cached IP after the mapping expired from the waypoint.  This solution seems to punish the innocent too much for too smal! l a gain.

This paper presents a cool new idea on how to integrate the globally routed IPv4 with private IPv4 networks and IPv6 islands.  The biggest advantage of this system is the small impact it has on the existing infrastructure, requiring just a few changes in a few, centrally controlled places.  I would recommend this paper to anyone interested in integrating NATted networks with the global IPv4 network and/or IPv4 networks with IPv6 networks.

REFERENCE
T. S. Eugene Ng, Ion Stoica, and Hui Zhang. "A Waypoint Service Approach to Connect Heterogeneous Internet Address Spaces." In Proceedings of USENIX Technical Conference, pages 319-332, June 2001.