An obvious concern with AVES is whether it is secure. Can attackers flood the system? Will AVES reusable-IP hosts be exposed to attackers at the level of regular IP hosts? Can attackers cause the system to mis-behave? In the following, we discuss these issues in detail. We assume a general deployment scenario where delayed binding is used since a secure environment is assumed in intranet deployment. To summarize, the connectivity to AVES reusable-IP hosts is more easily disrupted by flooding attacks than that to regular IP hosts, however, AVES reusable-IP hosts are somewhat less vulnerable to other security exploits. Attackers also cannot cause waypoints to incorrectly relay traffic.
First and foremost, we acknowledge that AVES waypoints are no better at handling packet flooding type of denial of service attacks than any other network systems. The only method to prevent this is to traceback to the origin of the flooding and filter those packets out of the network. There has been some recent advances in this area [23]. Ingress filtering [5] also helps reduce the problem by disallowing address spoofed packets from entering the network. When the waypoints are flooded, reusable-IP networks will only have out-bound connectivity through NAT as in without AVES. In our implementation, we simply put some hard limits on resource consumptions to prevent overloading of each AVES component during a flooding attack. At a different level, to cope with aggressive users, the AVES-aware DNS server can potentially be extended to allocate the available session creation capacity more fairly by scheduling requests based on the initiators' and responders' identities. This way, an initiator or a responder (e.g. a popular web server) cannot occupy all resources and prevent other normal users from opening sessions. Currently, our implementation simply limits the peak rate at which sessions can be opened to each responder.
To address the second question, although AVES provides in-bound connectivity, it does not fully expose reusable-IP hosts and attacking them is somewhat more difficult. We have disabled the zone transfer [15] function of the AVES-aware DNS server to prevent malicious users from obtaining host names. In addition, to prevent scanning of host names, our implementation ignores and penalizes a requester that queries for host names that do not exist in our database. Without knowing any host name, the only opportunity for an attacker to connect to a reusable-IP host is to transmit packets to a waypoint during the time it is in a wait state. To lower the chance of this succeeding, our waypoint daemon monitors for in-coming packets with source addresses that it has no state for while it is not in a wait state and reject all packets from these sources for 3 hours.
Finally, an attacker may hope to cause waypoints to mis-behave by sending malicious packets to a waypoint while it is in a wait state. However, we have designed the wait state algorithm such that these malicious packets cannot cause a waypoint to mis-behave, they cannot prevent a legitimate initiator from connecting to the correct responder. The reason is that the wait state period is fixed and does not end simply because a malicious new initiator has arrived. The rejection algorithm is also conservatively designed to make sure all admission control violations are caught even in the presence of malicious packets.