Grenville Armitage

Investigating the IPv6 teredo tunnelling capability and performance of internet clients

By: 
Sebastian Zander, Lachlan L.H. Andrew, Grenville Armitage, Geoff Huston, George Michaelson
Appears in: 
CCR October 2012

The Teredo auto-tunnelling protocol allows IPv6 hosts behind IPv4 NATs to communicate with other IPv6 hosts. It is enabled by default on Windows Vista and Windows 7. But Windows clients are self-constrained: if their only IPv6 access is Teredo, they are unable to resolve host names to IPv6 addresses. We use web-based measurements to investigate the (latent) Teredo capability of Internet clients, and the delay introduced by Teredo. We compare this with native IPv6 and 6to4 tunnelling capability and delay.

Public Review By: 
Jia Wang

The IPv6 capability on today’s Internet has been a well established topic over the past years. There have been extensive attentions, discussions, and activities at IETF and NANOG as well as proposals published in research literatures. This paper provided a nice addition to the existing work by studying the IPv6 Teredo tunneling capability and performance of Internet clients. Teredo is a Windows based tunneling of IPv6 over IPv4-only networks and is enabled by default in Windows Vista and Windows 7. The paper focused on examining two aspects of Teredo tunnel performance: success rate (i.e., client capability) and latency. In order to measure the Teredo performance, authors instrumented several Web sites by embedding a small test script which performs the measurement when downloaded by a client Web browser. Authors also used Google’s AdSense platform to distribute their script as an advertisement. There were several interesting observations based on their experiments that covered a time period of several months. First, while only 6–7% of connections were from fully IPv6-capable clients, more than twice as many connections (15–16%) were from Windows clients that could have used IPv6 if Windows Teredo was fully enabled by default. Second, over 80% of Windows Vista and 66% of Windows 7 connections Teredo failed to establish a tunnel. Third, Teredo significantly increases the median delay to fetch objects by 1–1.5 seconds compared to IPv4 or native IPv6. These observations indicated that both client capability and delay are major issues of Teredo. Though some of these observations are not completely surprising (e.g., applications experience more latencies), the paper provided quantitative measurement of the client capability and performance impact of Teredo tunneling which can be useful to researchers who looks for such numbers. I think it could be even more useful and perhaps would make the paper stronger if authors could generalize their study to a wider range of Web sites and even other applications. In addition, it would be interesting to see a more thorough comparison of Teredo with other IPv6 tunneling techniques. I would also like to see efforts that could further improve Teredo in terms of capability and latency. Having said this, I feel that this paper is an interesting piece of measurement work on IPv6 Teredo tunneling.

Issues with Network Address Translation for SCTP

By: 
David A. Hayes, Jason But, and Grenville Armitage
Appears in: 
CCR January 2009

A Stream Control Transmission Protocol (SCTP) capable Network Address Translation (NAT) device is necessary to support the wider deployment of the SCTP protocol. The key issues for an SCTP NAT are SCTP’s control chunk multiplexing and multi-homing features. Control chunk multiplexing can expose an SCTP NAT to possible Denial of Service attacks. These can be mitigated through the use of chunk and parameter processing limits.

Public Review By: 
Chadi Barakat

The number of NAT boxes in the Internet is fast increasing especially with the deployment of home networks by ADSL subscribers. Unfortunately, these boxes are known to cause several problems to end-toend protocols given the fact that they alter the information in the IP address and port number fields of Internet packets. Among the problems caused by NAT boxes and recently identified are the ones relative to the SCTP protocol. Indeed, the SCTP protocol (Stream Control Transmission Protocol) is intended to transmit multiple streams inside the same association and to enable hosts to simultaneously use multiple IP addresses for network path tolerance. All the information on the association is transmitted in an SCTP initialization packet and is then transparent to the NAT box. Later on when packets of new streams are sent within the same association using new port numbers, the NAT box is unable to handle them which causes their drop. The solution proposed to this problem by a recent Internet draft by Stewart and Tuxen consists in parsing the SCTP header by NAT boxes to create all necessary rules upon the initialization and to keep parsing packets to translate the port numbers of the different streams. This solution is shown in the present paper to introduce security threats on NAT boxes and to induce high processing overhead. Indeed, the ease by which streams are created from outside the local network can push attackers to considerably increase the number of these streams to overwhelm the NAT boxes. This problem is carefully analyzed in the present paper both analytically and experimentally and a set of recommendations and guidelines are issued to improve the security of NAT boxes.
Even though the evaluation part in the paper can be made more solid and the presentation can be improved by putting the contribution in a more general context than SCTP and the proposed Internet draft, the paper has the merit of identification a new real problem and analyzing it. The publication of the idea while the standardization of SCTP-enabled NATs is going on can help improving any potential standard around this problem. This also has certainly an impact on the research on NAT boxes in general and on making them more robust against any other attack of the same type.

IMRG Workshop on Application Classification and Identification Report

By: 
Tim Strayer, Mark Allman, Grenville Armitage, Steve Bellovin, Shudong Jin, and Andrew W. Moore
Appears in: 
CCR July 2008

The Internet Research Task Force’s (IRTF) Internet Measurement Research Group (IMRG) continued its practice of sponsoring workshops on current topics in computer network measurement with the Workshop on Application Classification and Identification (WACI) held October 3, 2007, at BBN Technologies in Cambridge, Massachusetts. There has been much general interest within the community recently in finding techniques to identify traffic without examination of the service ports used in the TCP or UDP header, as these increasingly do not accurately indicate the application generating the traffic.

An independent H-TCP implementation under FreeBSD 7.0: description and observed behaviour

By: 
Grenville Armitage, Lawrence Stewart, Michael Welzl, and James Healy
Appears in: 
CCR July 2008

A key requirement for IETF recognition of new TCP algorithms is having an independent, interoperable implementation. This paper describes our BSD-licensed implementation of H-TCP within FreeBSD 7.0, publicly available as a dynamically loadable kernel module. Based on our implementation experience we provide a summary description of the H-TCP algorithm to assist other groups build further interoperable implementations.

Public Review By: 
Jithendra Padye

In this paper the authors detail their experiences implementing H-TCP in FreeBSD 7.0.
Needless to say, the subject matter is not novel. Yet, the reviewers felt that the research community should encourage this type of work. Independent implementations and evaluations of proposed standards, while not glamorous, are vitally needed to ensure that new standards are specified correctly and work as promised under realistic conditions.
To recognize a new TCP variant, IETF requires an independent, interoperable implementation of the proposed variant. The authors go through the exercise of implementing H-TCP by looking only at the published standard.
The authors were generally successful in their endeavor, which is a testimony to the completeness of the H-TCP standard. But they had to contact the authors of the standard to obtain some clarifications, and some open issues remained (see sections 5.1 and 5.6), which is a testimony to the difficulty of translating a standard into an implementation.
Interoperability with other implementations and legacy code is a major concern for many IETF proposals. However, this is not a major concern for HTCP implementations since there is no change to any packet formats, or the basic TCP state machine.
Instead, the important question is what impact HTCP flows have on performance of other high-speed TCP flows and standard NewReno TCP flows. While this paper does offer some results to that effect, addressing this issue is not the main thrust of this paper.
In terms of results, the reviewers felt that a head-to-head comparison with another H-TCP implementation (perhaps one from the Hamilton institute) would have been very useful. Unfortunately, the paper does not include such a comparison. Instead, the authors focus on comparing H-TCP performance with NewReno, which has already been studied by others.

Syndicate content