Curtis R. Taylor

On building inexpensive network capabilities

By: 
Craig A. Shue, Andrew J. Kalafut, Mark Allman, Curtis R. Taylor
Appears in: 
CCR April 2012

There are many deployed approaches for blocking unwanted traffic, either once it reaches the recipient's network, or closer to its point of origin. One of these schemes is based on the notion of traffic carrying capabilities that grant access to a network and/or end host. However, leveraging capabilities results in added complexity and additional steps in the communication process: Before communication starts a remote host must be vetted and given a capability to use in the subsequent communication.

Public Review By: 
Stefan Saroiu

Leveraging capabilities in network architectures is a hot area of research today. A number of researchers have argued that capabilities could help improve network security (especially DoS attacks) because an attacker would lack the ability to generate traffic unless it acquires the appropriate capability first. This paper puts forward a interesting insight -- we could try leveraging DNS as a capability system and configure servers to change their IP addresses frequently (perhaps by changing IP translations in the NAT box placed in front of the server). A host needs to perform a DNS lookup before initiating a connection to the server. The paper does a nice job of describing how DNS could be used as a capability system. All reviewers acknowledged that the paper’s observation (i.e., “Hey! Here’s how to turn DNS into a capability system”) is a really nice one. The paper is also well-written and thought-provoking, and thus a very nice new addition on a long line of previous papers on the theme of how to introduce new functionality by piggy-backing on existing networking systems. The reviewers' main concern was understanding the exact nature of the threats that such a system would prevent. The reviewers felt that many DoS attacks today rely on flooding the network (rather than on sending a small number of packets only) and this system falls short from preventing such attacks. For example, even without the server's current IP address, an attacker could still flood the NAT box if they were to know a previously valid server IP. While the reviewers' concerns are very specific – the paper’s threat model is not clearly articulated – they get to a much deeper issue of this research area. The nature of the argument put forward appears to be recursive. On one hand, capabilities can stop DoS attacks on the network. But, how do we stop DoS attacks on the capabilities system itself?

Syndicate content