Sunteți pe pagina 1din 63
September/October 2008, Vol. 22, No. 5 ® THE MAGAZINE OF GLOBAL INTERNETWORKING www.comsoc.org Implications and

September/October 2008, Vol. 22, No. 5

®

September/October 2008, Vol. 22, No. 5 ® THE MAGAZINE OF GLOBAL INTERNETWORKING www.comsoc.org Implications and Control
September/October 2008, Vol. 22, No. 5 ® THE MAGAZINE OF GLOBAL INTERNETWORKING www.comsoc.org Implications and Control

THE MAGAZINE OF GLOBAL INTERNETWORKING

www.comsoc.org

Implications and Control of Middleboxes in the Internet

® ®
®
®
and Control of Middleboxes in the Internet ® ® A Publication of the IEEE Communications Society
and Control of Middleboxes in the Internet ® ® A Publication of the IEEE Communications Society

A

Publication of the IEEE Communications Society

in

cooperation with the

IEEE Computer Society and the Internet Society

® THE MAGAZINE OF GLOBAL INTERNETWORKING SEPTEMBER/OCTOBER 2008, VOL. 22, NO. 5 Special Issue Implications
® THE MAGAZINE OF GLOBAL INTERNETWORKING SEPTEMBER/OCTOBER 2008, VOL. 22, NO. 5 Special Issue Implications

®

® THE MAGAZINE OF GLOBAL INTERNETWORKING SEPTEMBER/OCTOBER 2008, VOL. 22, NO. 5 Special Issue Implications and

THE MAGAZINE OF GLOBAL INTERNETWORKING

SEPTEMBER/OCTOBER 2008, VOL. 22, NO. 5

Special Issue

Implications and Control of Middleboxes in the Internet

Guest Editors: Xiaoming Fu, Martin Stiemerling, and Henning Schulzrinne

8

14

20

26

A Retrospective View of Network Address Translation

Today, network address translators, or NATs, are every- where. Their ubiquitous adoption was not promoted by design or planning but by the continued growth of the Internet. Lixia Zhang

Behavior and Classification of NAT Devices and Implications for NAT Traversal

For a long time, traditional client-server communication was the predominant communication paradigm of the Internet. Network address translation devices emerged to help with the limited availability of IP addresses and were designed with the hypothesis of asymmetric con- nection establishment in mind. But with the growing success of peer-to-peer applications, this assumption is no longer true. Andreas Müller, Georg Carle, and Andreas Klenk

Modeling Middleboxes

The authors present a simple middlebox model that suc- cinctly describes how different middleboxes process packets and illustrate it by representing four common middleboxes. Dilip Joseph and Ion Stoica

Network Address Translation for the Stream Control Transmission Protocol

The authors discuss the deficiencies of using existing NAT methods for SCTP and describes a new SCTP-specif- ic NAT concept. This concept is analyzed in detail for several important network scenarios, including peer-to- peer, transport layer mobility, and multihoming. Michael Tüxen, Irene Rüngeler, Randall Stewart, and Erwin P. Rathgeb

33

41

48

56

Distributed Connectivity Service for a SIP Infrastructure

The authors present a distributed connectivity service solution that integrates relay functionality directly in user nodes. Luigi Ciminiera, Guido Marchetto, Fulvio Risso, and Livio Torrero

Dial “M” for Middlebox Managed Mobility

Users can be served by multiple network-enabled terminal devices, each of which in turn can have multiple network interfaces. This multihoming at both the user and device level presents new opportunities for mobility handling. Stephen Herborn and Aruna Seneviratne

NAT Issues in the Remote Management of Home Network Devices

The authors focus on NAT issues in the management of home network devices. Specifically, they discuss efforts relating to standardization. Choongul Park, Kitae Jeong, Sungil Kim, and Youngseok Lee

Improving the Performance of Route Control Middleboxes in a Competitive Environment

The authors show that by blending randomization with adaptive filtering techniques, it is possible to drastically reduce the interference between competing route con- trollers, and this can be achieved without penalizing the end-to-end traffic performance. Marcelo Yannuzzi, Xavi Masip-Bruin, Eva Marin-Tordera, Jordi Domingo-Pascual, Alexandre Fonte, and Edmundo Monteiro

Editor’s Note

New Books & Multimedia

Guest Editorial

2

6

4

IEEE NETWORK ISSN 0890-8044 is published bimonthly by the Institute of Electrical and Electronics Engineers, Inc. Headquarters address: IEEE, 3 Park Avenue, 17th Floor, New York, NY 10016- 5997, USA; tel: +1-212-705-8900; e-mail: ieee.network@ieee.org. Responsibility for the contents rests upon authors of signed articles and not the IEEE or its members. Unless otherwise specified, the IEEE neither endorses nor sanctions any positions or actions espoused in IEEE Network.

ANNUAL SUBSCRIPTION: $40 in addition to IEEE Communications Society or any other IEEE Society member dues. Non-member prices: $250. Single copy price $50. EDITORIAL CORRESPONDENCE: Address to: Chatschik Bisdikian, Editor-in-Chief, IEEE Network, IEEE Communications Society, 3 Park Avenue, 17th Floor, New York, NY 10016-5997, USA; e- mail:bisdik@us.ibm.com

COPYRIGHT AND REPRINT PERMISSIONS: Abstracting is permitted with credit to the source. Libraries are permitted to photocopy beyond the limits of U.S. Copyright law for private use of patrons:

those articles that carry a code on the bottom of the first page provided the per copy fee indicated in the code is paid through the Copyright Clearance Center, 222 Rosewood Drive, Danvers, MA 01923, USA. For other copying, reprint, or republication permission, write to Director, Publishing Services, at IEEE Headquarters. All rights reserved. Copyright ©2008 by the Institute of Electrical and Electronics Engineers, Inc.

POSTMASTER: Send address changes to IEEE Network, IEEE, 445 Hoes Lane, Piscataway, NJ 08855-1331, USA. Printed in USA. Periodical-class postage paid at New York, NY and at additional mailing offices. Bulk rate postage paid at Easton, PA permit #7. Canadian GST Reg# 40030962. Return undeliverable Canadian addresses to: Frontier, P.O. Box 1051, 1031 Helena Street, Fort Eire, ON L2A 6C7.

SUBSCRIPTIONS, orders, address changes should be sent to IEEE Service Center, 445 Hoes Lane, Piscataway, NJ 08855-1331, USA. Tel. +1-732-981-0060.

ADVERTISING: Advertising is accepted at the discretion of the publisher. Address correspondence to IEEE Network, 3 Park Avenue, 17th Floor, New York, NY 10016-5997, USA.

®
®

THE MAGAZINE OF GLOBAL INTERNETWORKING

Director of Magazines

Thomas F. La Porta, Penn. State Univ., USA

Editor-in-Chief

Ioanis Nikolaidis, U. of Alberta, Canada

Associate Editor-in-Chief

Chatschik Bisdikian, IBM Research, USA

Senior Technical Editors

Thomas M. Chen, Swansea U., UK Yi-Bing (Jason) Lin, National Chiao Tung Univ., Taiwan Peter O’Reilly, Northeastern Univ., USA

Technical Editors

Kevin Almeroth, UCSB, USA

N. Asokan, Nokia Res. Ctr., Finland

Olivier Bonaventure, U. Catholique de Louvain, Belgium Adrian Conway, Verizon, USA Jon Crowcroft, U. of Cambridge, UK Christos Douligeris, U. of Piraeus, Greece Paolo Giacomazzi, Politecnico di Milano, Italy David Greaves, U. of Cambridge, UK Nikhil Jain, Qualcomm, USA Admela Jukan, T. U. Braunschweig, Germany Tim King, BTexact Tech., UK Frank Magee, Consultant, USA Ioanis Nikolaidis, U. of Alberta, Canada Georgios I. Papadimitriou, Aristotle Univ., Greece Mohammad Peyravian, IBM Corporation, USA Kazem Sohraby, U. of Arkansas, USA James Sterbenz, Univ. of Kansas, USA Joe Touch, USC/ISI, USA Vittorio Trecordi, CEFRIEL, Italy Guoliang Xue, Arizona State Univ., USA Raj Yavatkar, Intel, USA Bulent Yener, Rensselaer Polytechnic Institute, USA

Feature Editors

Olivier Bonaventure, "Software Tools for Networking"

U. Catholique de Louvain, Belgium

Olivier Bonaventure, "New Books & Multimedia"

U. Catholique de Louvain, Belgium

IEEE Production Staff

Joseph Milizzo, Assistant Publisher Eric Levine, Associate Publisher Susan Lange, Digital Production Manager Catherine Kemelmacher, Associate Editor Jennifer Porcello, Publications Coordinator Devika Mittra, Publications Assistant

2008 IEEE Communications Society Officers

Doug Zuckerman, President Andrzej Jajszczyk, VP–Technical Activities Mark Karol, VP–Conferences Byeong Gi Lee, VP–Member Relations Sergio Benedetto, VP–Publications Nim Cheung, Past President Stan Moyer, Treasurer John M. Howell, Secretary

Board of Governors

The officers above plus Members-at-Large:

Class of 2008 Thomas M. Chen, Andrea Goldsmith Khaled Ben-Letaief, Peter J. McLane Class of 2009 Thomas LaPorta, Theodore Rappaport Catherine Rosenberg, Gordon Stuber Class of 2010 Fred Bauer, Victor Frost Stefano Galli, Lajos Hanzo

2008 IEEE Officers

Lewis M. Terman, President John R. Vig, President-Elect Barry L. Shoop, Secretary David G. Green, Treasurer Leah H. Jamieson, Past President Jeffry W. Raynes, Executive Director Curtis A. Siller, Jr., Director, Division III

H. Jamieson, Past President Jeffry W . R aynes, Executive Director Curtis A. Siller, Jr., Director,

®

EDITOR’S NOTE

NATs and Frozen Veggies

Division III ® EDITOR’S NOTE NATs and Frozen Veggies Ioanis Nikolaidis D D ear readers, welcome

Ioanis Nikolaidis

DD ear readers, welcome to the September 2008 issue of IEEE Network. The sound of trucks, the heavy duty disposal bins on the curb,

and the thud and bang of construction are all elements of a “quiet” sum- mer, full of renovations, in my neighborhood. Resisting this Siren’s call is difficult even if I swore off any renovations for the rest of my life, given past experience. I naively thought that this time it wouldn’t be that bad. After all, this time it looks like a much smaller job than last time. Of

course, I neglected a key conservation law: if a job is small, the additional delays for various reasons will expand it to be roughly equal the total time

of a “big” job (more professionally managed one might argue, and hence with much less slack). What I was not prepared to experience is the shift in attitudes caused by the widespread adoption of many “information” appli- ances in today’s household. I should have spotted the shift when my contractor warned that he would need to turn off the power to our house, only to qualify it with “If that’s okay with your gear, right?” noticing that there were maybe a tad too many devices, computers, firewalls, servers, and bridges spread around the house. He was concerned that some might develop bad hiccups after the switch was turned off and on again. He had experienced himself some “unhealthy” side effects to his equipment under similar circumstances, so his concern was genuine. I thought for a moment of explaining the benefits of stateless- ness and how, I would hope, most of my gear could survive power being cut and restored later (no I don’t have a UPS — I believe in luck). I decided not to expand on the topic, just agreeing that it was okay to cut the power to the house. Things indeed went as planned, although it should have struck me as odd that he did not ask about other things that might be influenced by cutting the power. A few days later, while I was at work, the contractor stumbled on a dilemma. He had to run a industrial strength vacuum cleaner to pick up lots of debris. Having pulled down walls and removed several wall outlets left him with no choice but to run an extension cord to the nearest outlet he could find still standing. It happened that this was an outlet already fully populated by two cords, one connecting a refrigerator we keep in the basement, and one connecting a NAT/firewall box, a nearby server, and a cable modem. Without any hesitation, he removed the one least likely to create a hassle: the refrig- erator! In comparison to a NAT box, a refrigerator is low tech and almost stateless — if not its volatile contents. His choice was reasonable. He was not expect- ing to keep it for more than an hour this way. But human nature conspired. The contractor forgot to plug in the refrigerator when he was done. The

packets were running smoothly while our frozen veggies were thawing. To

EDITOR’S NOTE

make matters worse, and blame my own human nature here, I did not notice the “failure” until late in the evening (okay, so I do keep some beer there too). Had it been the firewall malfunctioning I would have spotted it in minutes. I spent a good part of the evening deciding what had to be thrown away and what to keep (luckily this was not a warm day) and laughing at our priorities:

mine and the contractor’s. The fact that everyday people think of consumer-grade networking and information appliances as possibly the most sensitive objects in a house reflects what they have learned from their own experience in the recent past. After all, a lost file can be a major blow, while a pound of rotten spinach is, well, compost. A handful of remark- able technologies made it into these everyday devices, and one that is still a topic of research, extension, and overall controversy is Network Address Translation (NAT). NAT is no longer just a way to establish a home user’s little kingdom of an Internet-connected private network (while guilt-free of hoarding IP addresses). NAT boxes are increasingly active participants as the ‘’middle- point’’ of communication paths and this has led to the use of a new term, “middlebox,” to describe the particu- lar class of technologies. This special issue, entitled “Implications and Control of Middleboxes in the Internet,” provides a timely

review of where we are in middlebox evolution and how they might further evolve. I would like to thank the guest editors, Xiaoming Fu, Martin Stiemerling, and Henning Schulzrinne, as well as the liaison editor of this issue, Jon Crowcroft, for their excellent work in putting this issue together. I would also to welcome a new member to our editorial board: Dr. Admela Jukan. Dr. Jukan received her Ph.D. degree from Vienna Uni- versity of Technology in Austria, and is currently a W3 Professor of Electrical and Computer Engineering at the Technical University Carolo-Wilhelmina of Brunswick (Braunschweig), Germany. Dr. Jukan served between 2002 and 2004 as Program Director in Com- puter and Networks System Research at the National Science Foundation (NSF), responsible for funding and coordinating US-wide university research and educa- tion activities in the area of network technologies and systems. As always, your feedback regarding the direction and substance of the magazine is invaluable and always appreciated. Please contact me, by e-mail, at yannis@cs.ualberta.ca, to let me know what you think about the editorial comments, what type of content might be more interesting to you, and in what ways the magazine’s distinct character could be improved or fur- ther publicized.

the magazine’s distinct character could be improved or fur- ther publicized. IEEE Network • September/October 2008

NEW BOOKS AND MULTIMEDIA/EDITED BY OLIVIER BONAVENTURE

The New Books and Multimedia column contains brief reviews of new books in the computer communications field. Each review includes a highly abstracted description of the contents, relying on the publisher’s descriptive materials, minus advertising superlatives, and checked for accuracy against a copy of the book. The reviews also comment on the structure and the target audience of each book. Publishers wishing to have their books listed in this manner should contact Olivier Bonaventure by email. Olivier Bonaventure Université Catholique de Louvain, Belgium bonaventure@ieee.org

LAN Switch Security : What Hackers Know About Your Switches

Eric Vyncke and Christopher Pagen, Cisco Press, 2008, ISBN-10: 1-58705- 256-3, Softbound, 360 pages

Ethernet is now the default fixed local area network technology. Ethernet LANs are found in all enterprise environments, and in more and more home networks. Ether- net was designed in the 1970s when securi- ty was not a concern. Since then, Ethernet has evolved with the introduction of hubs and switches. Many network administra- tors are aware that hubs are a security con- cern since they broadcast Ethernet frames, and some of them assume that switches are more secure. Unfortunately, hackers have learned the limitations of Ethernet switch- es and have developed several tools that can be used to exploit them. This book describes the current state of the art in securing Ethernet switches. The authors take a practical approach by using different types of Cisco switches and freely available tools to demonstrate the security problems and their solutions. Despite its focus on a single vendor, this book is an interesting reference for system adminis- trators who are willing to better under- stand how to secure their Ethernet networks. This is particularly important in environments such as schools were uncon- trolled laptops are often connected. The first part discusses the basic secu- rity problems that affect Ethernet switch- es: the learning bridge process and the implications of the limited size of the MAC table on Ethernet switches. It also discusses configurations to mitigate these problems. Then the book analyzes sever- al protocols and their security implica- tions: the spanning tree protocol, the 802.1q VLANs, DHCP, IPv4 ARP, and IPv6 Neighbor Discovery, but also sur- prising electrical security issues with

power over Ethernet. The second part focuses on techniques can that be used on switches to sustain denial-of-service attacks, from both forwarding and con- trol plane viewpoints. The last part ana- lyzes recent techniques that can be used to improve the security of Ethernet switches, such as 802.1x or 802.1AE and access control lists.

Principles of Protocol Design

Robin Sharp, Springer Verlag, 2008, ISBN: 978-3-540-77540-9, Hard- bound, 402 pages

This book takes an unusual path to describe computer network protocols. While most standard networking texts mainly focus on a textual description of the different protocols and mechanisms, Robin Sharp starts from formal descrip- tion techniques. More precisely, he choos- es the Communicating Sequential Processes (CSP) notation proposed by Hoare. CSP is a process algebra that allows to model the interactions among communicating processes. The book starts with a detailed description of CSP and then uses the CSP formalism to describe several mechanisms such as flow and error control, fault-tolerant broadcast, and two- phase commits. An advantage of using CSP is that the book contains proofs of several of the described mechanisms. However, as CSP does not contain com- plex data types, it is difficult to completely model complex protocols in detail. Sur- prisingly, the author did not consider more powerful formal description tech- niques that evolved from CSP such as LOTOS. The second part of the book is more heterogeneous. Several security protocols are discussed, and the BAN logic is intro- duced. Then the author briefly discusses real protocols. The discussion considers both open system interconnection (OSI) protocols and Internet protocols. This part

is less interesting than the first part, where the CSP models could be of interest to readers who are more interested in the application of formal description tech- niques to network protocols.

Patterns in Network Architec- ture : A Return to Fundamen- tals

John Day, Prentice Hall, 2008, ISBN- 10: 0132252422, Hardbound, 464 pages

The architecture of today’s Internet was mainly designed together with the TCP and IP protocols in the 1970s and early 1980s. During the last years, researchers and funding organizations in America, Europe, and Asia have started to work on different alternative architectures for the Internet. Some consider an evolutionary approach where the Internet architecture would be incrementally modified in a backward compatible manner, while oth- ers believe a completely new architecture should be developed to take into account the requirements of today’s and tomor- row’s Internet. John Day’s book is a must read for researchers interested in the evolution of the Internet architecture. The book is composed of two main parts. The first part is mainly a history of the evolution of computer network architectures in the 1970s and 1980s. John Day participated actively in this research on both the Inter- net side and the OSI side. He explains the reasons for some of the design choices and discusses alternatives that were considered but not selected. The discussion considers several of the key elements of a computer network architecture, including the proto- col elements, layering, naming, and addressing. The second part describes John Day’s vision of an alternative network architec- ture. For this, he starts by reconsidering network-based InterProcess Communica- tion (IPC) and shows that a distributed IPC should be at the core of a computer network architecture. This discussion is interesting, but the author does explain in detail how it could be realized in practice. The second part ends with two chapters on topological addressing influenced by Mike O’Dell’s GSE proposal, and a dis- cussion of the impact of multicast and multihoming on the architecture.

GUEST EDITORIAL

Implications and Control of Middleboxes in the Internet

Implications and Control of Middleboxes in the Internet Xiaoming Fu Martin Stiemerling Henning Schulzrinne M M

Xiaoming Fu

Martin Stiemerling

Henning Schulzrinne

MM iddleboxes in the Internet have been explored, sometimes quite controversially, in operations, standardization, and the research community for more than 10 years. The main concern in the

past has been their contradicting nature to the Internet’s end- to-end principle. In the past, many have expressed concerns that middleboxes contradict the Internet's end-to-end principle that is often understood to posit that "intelligence" is placed in end system and network elements just forward packets. Mid- dleboxes introduce functions beyond forwarding in the data path between a source and destination, as described, for exam- ple, in RFC 3234. RFC 3234 describes a wide range of middle boxes, from TCP performance enhancing proxies to transcoders. On the other hand, middleboxes were introduced in the Internet for various reasons: NATs intend to decouple the internal IP addressing from the public address space while allowing multiple hosts to share a single public IP address, for the purpose of preserving the IP address space; firewalls are used for administrators to enforce policies on the data traffic at administrative borders with the intention of preventing their networks from being attacked or monitored; application level gateways (ALGs) are typically used to assist applications in their operations. The implications of the emergence and popularity of middleboxes are complicated. With middleboxes it is diffi- cult to even provide basic end-to-end connectivity for many applications. For example, Internet hosts behind NATs can only initiate a TCP connection with another host, but can- not accept a connection request. Unlike in the past, when the vast majority of applications followed the client-server design pattern, and most hosts behind NATs were clients anyway (e.g., your browser accessing a Web server), a vari- ety of new applications today, such as voice-over-IP, gam- ing, and peer-to-peer file sharing cause an enormous list of issues. Hosts behind NATs are not reachable from any other host anymore, which become particularly troublesome for VoIP and other peer-to-peer applications. Likewise, firewalls are usually statically configured to block certain TCP ports or do not understand non-TCP protocols, mak- ing it difficult to deploy new applications and protocols. This results in a number of issues to be considered in the design and development of new protocols and applications. To mitigate the negative impacts of these issues, quite a number of techniques have been developed, which can be cat-

egorized as explicit control and implicit control of firewalls and NATs. For explicit control, an entity, either the end host or a proxy in the network, has a relationship with the middle- box and controls its behavior (e.g., the set of policies or filter rules loaded). Examples of explicit control are universal plug and play (UPnP), Internet Engineering Task Force (IETF) Middlebox Communications (MIDCOM), and IETF Next Steps in Signaling (NSIS). On the other hand, implicit control is the traditional way of traversing middleboxes. Implicit con- trol does not have any control relationship with the middlebox, because end hosts, probably with the support of other end hosts, are using hole punching techniques to get a working middlebox traversal. Examples of implicit control are the IETF’s Session Traversal Utilities for NAT (STUN), Traversal Using Relays around NAT (TURN), and Interactive Connec- tivity Establishment (ICE). In addition, there have been some recent attempts to design or use certain types of middleboxes, such as various application proxies. In this special issue we are pleased to introduce a series of state-of-the-art articles on this specific area. These articles cover the subject from a variety of perspectives, offering the readers an understanding of the issues and implications of var- ious middleboxes in the Internet, including their control mech- anisms. A total of eigh articles, selected from 26 submissions based on a strict peer review process, cover a broad range in the field of implications and control of middleboxes in the Internet. While some articles present more general issues with middleboxes, understanding their behaviors and implications, others focus on new approaches to controlling and usiing mid- dleboxes. NATs, an unplanned reality, have posed complications to the Internet architecture and applications. The first article, “A Retrospective View of NAT” by Lixia Zhang, takes readers back to the early days of middleboxes. It gives a historic review of NATs and the lessons learned, including how they impeded standardization and deployment of IPv6, and an expected solu- tion for addressing the Internet address depletion problem. Without a timely standardization of NAT, today there have been a number of different NAT implementations, and it is vital to understand their behaviors due to their nearly ubiqui- tous presence. The second article, “Behavior and Classification of NAT Devices and Implications for NAT Traversal” by Andreas Müller, Andreas Klenk, and Georg Carle, provides a compre- hensive overview of NAT behaviors and currently available

GUEST EDITORIAL

NAT traversal techniques. The article presents a new catego- rization approach based on an analytical abstraction of NAT traversal, which classifies NAT traversal services into four dis- tinct types and deduces the corresponding NAT behaviors. This may help developers of new protocols and applications to determine applicable techniques for NAT traversal. While the first two articles describe the history, behavior, and classification of NAT, the next article by Dilip Joseph and Ion Stoica, “Modeling Middleboxes,” proposes a formal and generic model for deducing middlebox functionalities and behaviors. Using this model, the article illustrates how differ- ent middleboxes process packets, and how four common mid- dleboxes — firewall, NAT, layer 4, and layer 7 load balancers — may be depicted. As such, the article provides an initial step for relevant designers, users, and researchers to understand and refine the behaviors and implications of various middle- boxes. Existing middleboxes mostly consider TCP and UDP in their implementations, and typically do not support other pro- tocols, such as the Stream Control Transmission Protocol (SCTP). In the fourth article, Michael Tüxen et al. describe the extensions required to support NAT for SCTP. The analysis presented in this article may be useful as a general lesson in the near future, as several other protocols after SCTP, includ- ing DCCP, XCP, and HIP, use similar techniques such as mul- tihoming, rehoming, and handshake cookies. Applications using the Session Initialization Protocol (SIP) or peer-to-peer way of operation (P2PSIP or just normal P2P applications) are among those that suffer most from the mid- dlebox traversal issue. The fifth article, “Distributed Connec- tivity Service for a SIP Infrastructure” by Luigi Ciminiera et al., examines this issue and presents an alternative approach to the current STUN/TURN/ICE approach to middlebox traver- sal. The approach distributes the rendezvous and relay func- tions among SIP user agents, which discover their peers autonomously and maintain a P2P overlay to ensure connectiv- ity across NATs and firewalls in a SIP infrastructure without relying on a centralized server. The remaining three articles address new applications of mid- dleboxes. The sixth article, “Dial M for Middlebox Managed Mobility” by Stephen Herborn and Aruna Seneviratne, describes a new usage type of middleboxes for mobility support via the concept of virtual private “personal networks.” Such a network is created and maintained by way of HIP combined with IPsec and supported by middlebox state drop "(at least to some extent)" plus middlebox state, which may be interesting (at least to some extent) for the recent research efforts on network virtualization, as they use today’s technologies directly. An increasing number of home users today are using NATs to connect their home IP devices with the Internet. Choongul Park et al. discuss this issue in their article “Issues in the Remote Management of Home Network Devices.” By extend- ing SNMP and using additional management objects (MOs) to gather NAT binding information, the authors attempt to address the NAT traversal problem under a symmetric NAT, based on their observations in Korea. While the success rate of NAT traversal could be a potential issue outside Korea, the article provides an insight of what home networking standards may have to deal with.

Yet another type of middlebox function, intelligent route control (IRC) for multihomed sites and subscribers, has been recently identified as a key issue in efficient network opera- tions. The final article, “Improving the Performance of Route Control Middleboxes in a Competitive Environment” by Marcelo Yannuzzi et al., addresses this issue and introduces an IRC approach for competitive environments, by blending ran- domization with adaptive filtering techniques. We hope that these articles will help to clarify and explain the state-of-the-art advances on middlebox issues in the Inter- net, providing current visions of how the behaviors, implica- tions, and control of middlboxes may be analyzed, encompassed, and utilized. In preparing this special issue, we wish to thank all the peer reviewers for their efforts in careful- ly reviewing the manuscripts to meet the tight deadlines. We are grateful to our liaison editor Jon Crowcroft for his con- structive feedbacks, and Editor-in-Chief Ioanis Nikolaidis for his timely and critical suggestions.

Biographies

XIAOMING FU [M’02] (fu@cs.uni-goettingen.de) received his Ph.D. degree in computer science from Tsinghua University, Beijing, China, in 2000. After almost two years of postdoctoral work at Technical University Berlin, he joined the University of Göttingen as an assistant professor, leading a team working on networking research. Since April 2007 he has been a professor and head of the Computer Networks Group at the University of Göttingen. During 2003–2005 he also served as an expert on the ETSI Specialist Task Forces on Internet Proto- col Testing; he was also a visiting scientist at the University of Cambridge and Columbia University. In the research fields of architectures, protocols, and applications for QoS, firewalls, p2p overlay, and mobile networking as well as related security issues, he (co-)authored more than 50 referred papers as well as several RFCs/I-Ds. He has served as TPC member and session chair for several conferences, including IEEE INFOCOM, ICNP, ICDCS, GLOBECOM, and ICC. He was also founding chair of the ACM Workshop on Mobility in the Evolving Internet Architecture (MobiArch) and is TPC Co-Chair of IEEE GLOBECOM 2009 Next Generation Networking and Internet Symposium. He is currently a member of the editorial board of Computer Communications Journal (Elsevier).

STIEMERLING [M’00] (stiemerling@cs.uni-goettingen.de) received his

M.Sc. degree (Diploma) in electrical eengineering with a focus on IP networking technologies from the Polytechnic University of Applied Sciences in Cologne in 2000. After that he joined the NEC Laboratories Europe, Heidelberg, Germany, where he is currently a senior researcher. His areas of research interest are Internet architecture, Internet signaling protocols, network management, and overlay/ peer-to-peer systems. He has published several papers in these areas, and served as a TPC member of IEEE IPOM 2007. In the IETF he is active as working document editor in the MIDCOM, MMUSIC, and NSIS working groups, as well as in other IETF working groups and IRTF research groups. He is co-chair of the IETF Next Steps in Signaling (NSIS) working group, and secretary of the IP over DVB (IPDVB) working group, and a co-author of RFC 3816, RFC 3989, and RFC 4540, as well as RTSPng.

MARTIN

SCHULZRINNE [F’06] (hgs@cs.columbia.edu) received his Ph.D. from the

University of Massachusetts in Amherst, Massachusetts. He was a member of technical staff at AT&T Bell Laboratories, Murray Hill, New Jersey, and an asso- ciate department head at GMD-Fokus (Berlin) before joining the Computer Sci- ence and Electrical Engineering Departments at Columbia University, New York. He is currently a professor and chair of the Department of Computer Science. He has been a member of the Board of Governors of the IEEE Communications Society and is vice chair of ACM SIGCOMM, former chair of the IEEE Commu- nications Society Technical Committees on Computer Communications and the Inter- net, has been technical program chair of Global Internet, INFOCOM, NOSSDAV, and IPTCOMM, and was General Chair of ACM Multimedia 2004. He has also been a member of the Internet Architecture Board. Protocols co- developed by him, such as RTP, RTSP, and SIP, are now Internet standards, used by almost all Internet telephony and multimedia applications. His research inter- ests include Internet multimedia systems, ubiquitous computing, mobile systems, qual- ity of service, and performance evaluation.

HENNING

A Retrospective View of Network Address Translation Lixia Zhang, University of California, Los Angeles Abstract
A Retrospective View of Network Address Translation Lixia Zhang, University of California, Los Angeles Abstract
A Retrospective View of Network Address Translation Lixia Zhang, University of California, Los Angeles Abstract

A Retrospective View of Network Address Translation

Lixia Zhang, University of California, Los Angeles

Abstract

Today, network address translators, or NATs, are everywhere. Their ubiquitous adoption was not promoted by design or planning but by the continued growth of the Internet, which places an ever-increasing demand not only on IP address space but also on other functional requirements that network address translation is per- ceived to facilitate. This article presents a personal perspective on the history of NATs, their pros and cons in a retrospective light, and the lessons we can learn from the NAT experience.

AA network address translator (NAT) commonly refers to a box that interconnects a local network to the public Internet, where the local network runs on a block of private IPv4 addresses as spec-

ified in RFC 1918 [1]. In the original design of the Internet architecture, each IP address was defined to be globally unique and globally reachable. In contrast, a private IPv4 address is meaningful only within the scope of the local net- work behind a NAT and, as such, the same private address block can be reused in multiple local networks, as long as those networks do not directly talk to each other. Instead, they communicate with each other and with the rest of Inter- net through NAT boxes. Like most unexpected successes, the ubiquitous adoption of NATs was not foreseen when the idea first emerged more than 15 years ago [2, 3]. Had anyone foreseen where NAT would be today, it is possible that NAT deployment might have followed a different path, one that was better planned and standardized. The set of Internet protocols that were developed over the past 15 years also might have evolved dif- ferently by taking into account the existence of NATs, and we might have seen less overall complexity in the Internet com- pared to what we have today. Although the clock cannot be turned back, I believe it is a worthwhile exercise to revisit the history of network address translation to learn some useful lessons. It also can be worth- while to assess, or reassess, the pros and cons of NATs, as well as to take a look at where we are today in our under- standing of NATs and how best to proceed in the future. It is worth pointing out that in recent years many efforts were devoted to the development and deployment of NAT traversal solutions, such as simple traversal of UDP through NAT (STUN) [4], traversal using relay NAT (TURN) [5], and Teredo [6], to name a few. These solutions remove obstacles introduced by NATs to enable an increasing number of new application deployments. However, as the title suggested, this article focuses on examining the lessons that we can learn from the NAT deployment experience; a comprehensive sur- vey of NAT traversal solutions must be reserved for a sepa- rate article.

I also emphasize that this writing represents a personal view, and my recall of history is likely to be incomplete and to contain errors. My personal view on this subject has also changed over time, and it may continue to evolve, as we are all in a continuing process of understanding the fascinating and dynamically changing Internet.

How a NAT Works

As mentioned previously, IP addresses originally were designed to be globally unique and globally reachable. This property of the IP address is a fundamental building block in supporting the end-to-end architecture of the Internet. Until recently, almost all of the Internet protocol designs, especially those below the application layer, were based on the aforementioned IP address model. However, the explo- sive growth of the Internet during the 1990s not only sig- naled the danger of IP address space exhaustion, but also created an instant demand on IP addresses: suddenly, con- necting large numbers of user networks and home comput- ers demanded IP addresses instantly and in large quantities. Such demand could not possibly be met by going through the regular IP address allocation process. Network address translation came into play to meet this instant high demand, and NAT products were quickly developed to meet the mar- ket demand. However, because NATs were not standardized before their wide deployment, a number of different NAT products exist today, each with somewhat different functionality and different technical details. Because this article is about the history of NAT deployment — and not an examination of how to traverse various different NAT boxes — I briefly describe a popular NAT implementation as an illustrative example. Interested readers can visit Wikipedia to find out more about existing types of NAT products. A NAT box N has a public IP address for its interface connecting to the global Internet and a private address fac- ing the internal network. N serves as the default router for all of the destinations that are outside the local NAT address block. When an internal host H sends an IP packet P to a

public IP destination address D located in the global Inter- net, the packet is routed to N . N translates the private source IP address in P’s header to N ’s public IP address and adds an entry to its internal table that keeps track of the mapping between the internal host and the outgoing packet. This entry represents a piece of state, which enables subse- quent packet exchanges between H and D. For example, when D sends a packet P ’ in response to P, P’ arrives at N , and N can find the corresponding entry from its mapping table and replace the destination IP address — which is its own public IP address — with the real destination address H , so that P’ will be delivered to H . The mapping entry times

out after a certain period of idleness that is typically set to a vendor-specific value. In the process of changing the IP address carried in the IP header of each passing packet, a NAT box also must recalculate the IP header checksum, as well as the checksum of the transport protocol if it is calcu- lated based on the IP address, as is the case for Transmis- sion Control Protocol (TCP) and User Datagram Protocol (UDP) checksums. From this brief description, it is easy to see the major bene- fit of a NAT: one can connect a large number of hosts to the global Internet by using a single public IP address. A number of other benefits of NATs also became clear over time, which

I will discuss in more detail later. At the same time, a number of drawbacks to NATs also can be identified immediately. First and foremost, the NAT changed the end-to-end communication model of the Inter- net architecture in a fundamental way: instead of allowing any host to talk directly to any other host on the Internet, the hosts behind a NAT must go through the NAT to reach oth- ers, and all communications through a NAT box must be ini- tiated by an internal host to set up the mapping entries on the NAT. In addition, because ongoing data exchange depends on the mapping entry kept at the NAT box, the box represents a single point of failure: if the NAT box crashes, it could lose all the existing state, and the data exchange between all of the internal and external hosts must be restart- ed. This is in contrast to the original goal of IP of delivering packets to their destinations, as long as any physical connec- tivity exists between the source and destination hosts. Fur- thermore, because a NAT alters the IP addresses carried in a packet, all protocols that are dependent on IP addresses are affected. In certain cases, such as TCP checksum, which includes IP addresses in the calculation, the NAT box can hide the address change by recalculating the TCP checksum when forwarding a packet. For some of the other protocols that make direct use of IP addresses, such as IPSec [7], the protocols can no longer operate on the end-to-end basis as originally designed; for some application protocols, for exam- ple, File Transfer Protocol (FTP) [8], that embed IP address- es in the application data, application-level gateways are required to handle the IP address rewrite. As discussed later, NAT also introduced other drawbacks that surfaced only recently.

A Recall of the History of NATs

I started my Ph.D. studies in the networking area at the Mas-

sachusetts Institute of Technology at the same time as RFC 791 [9], the Internet Protocol Specification, was published in September 1981. Thus I was fortunate to witness the fascinat- ing unfolding of this new system called the Internet. During the next ten years, the Internet grew rapidly. RFC 1287 [2], Towards the Future Internet Architecture, was published in 1991 and was probably the first RFC that raised a concern about IP address space exhaustion in the foreseeable future.

RFC 1287 also discussed three possible directions to extend IP address space. The first one pointed to a direction similar to current NATs:

Replace the 32-bit field with a field of the same size but with a different meaning. Instead of being globally unique, it would be unique only within some smaller region. Gateways on the bound- ary would rewrite the address as the packet crossed the boundary.

RFC 1335 [3], published shortly after RFC 1287, provided

a more elaborate description of the use of internal IP address-

es (i.e., private IP addresses) as a solution to IP address exhaustion. The first article describing the NAT idea, “Extend- ing the IP Internet through Address Reuse” [10], appeared in the January 1993 issue of ACM Computer Communication Review and was published a year later as RFC 1631 [11]. Although these RFCs can be considered forerunners in the development of NAT, as explained later, for various reasons the IETF did not take action to standardize NAT. The invention of the Web further accelerated Internet growth in the early 1990s. The explosive growth underlined the urgency to take action toward solving both the routing scalability and the address shortage problems. The IETF took several follow-up steps, which eventually led to the launch of the IPng development effort. I believe that the expectation at the time was to develop a new IP within a few years, followed by a quick deployment. However, the actual deployment dur- ing the next ten years took a rather unexpected path.

The Planned Solution

As pointed out in RFC 1287, the continued growth of the Internet exposed strains on the original design of the Internet architecture, the two most urgent of which were routing sys- tem scalability and the exhaustion of IP address space. Because long-term solutions require a long lead time to devel- op and deploy, efforts began to develop both a short term and

a long-term solution to those problems. Classless inter-domain routing, or CIDR, was proposed as a short term solution. CIDR removed the class boundaries embedded in the IP address structure, thus enabling more efficient address allocation, which helped extend the lifetime of IP address space. CIDR also facilitated routing aggrega- tion, which slowed down the growth of the routing table size. However, as stated in RFC 1481 [12], IAB Recommendation for an Intermediate Strategy to Address the Issue of Scaling:

“This strategy (CIDR) presumes that a suitable long-term solution is being addressed within the Internet technical com- munity.” Indeed, a number of new IETF working groups start- ed in late 1992 and aimed at developing a new IP as a long-term solution; the Internet Engineering Steering Group (IESG) set up a new IPng area in 1993 to coordinate the efforts, and the IPng Working Group (later renamed to IPv6) was established in the fall of 1994 to develop a new version of IP [13]. CIDR was rolled out quickly, which effectively slowed the growth of the global Internet routing table. Because it is a quick fix, CIDR did not address emerging issues in routing scalability, in particular the issue of site multihoming. A multi- homed site should be reachable through any of its multiple provider networks. In the existing routing architecture, this requirement translates to having the prefix, or prefixes, of the site listed in the global routing table, thereby rendering provider-based prefix aggregation ineffective. Interested read- ers are referred to [14] for a more detailed description on multihoming and its impact on routing scalability. The new IP development effort, on the other hand, took much longer than anyone expected when the effort first

began. The IPv6 working group finally completed all of the protocol development effort in 2007, 13 years after its estab- lishment. The IPv6 deployment also is slow in coming. Until recently, there were relatively few IPv6 trial deployments; there is no known commercial user site that uses IPv6 as the primary protocol for its Internet connectivity. If one day someone writes an Internet protocol develop- ment history, it would be very interesting to look back and understand the major reasons for the slow development and adoption of IPv6. But even without doing any research, one could say with confidence that NATs played a major role in meeting the IP address requirement that arose out of the Internet growth and at least deferred the demand for a new IP to provide the much needed address space to enable the continued growth of the Internet.

The Unplanned Reality

Although largely unexpected, NATs have played a major role in facilitating the explosive growth of Internet access. Nowadays, it is common to see multiple computers, or even multiple LANs, in a single home. It would be unthinkable for every home to obtain an IP address block, however small it may be, from its network service provider. Instead, a com- mon implementation for home networking is to install a NAT box that connects one home network or multiple home networks to a local provider. Similarly, most enterprise net- works deploy NATs as well. It also is well known that coun- tries with large populations, such as India and China, have most of their hosts behind NAT boxes; the same is true for countries that connected to the Internet only recently. With- out NATs, the IPv4 address space would have been exhaust- ed a long time ago. For reasons discussed later, the IETF did not standardize NAT implementation or operations. However, despite the lack of standards, NATs were implemented by multiple ven- dors, and the deployment spread like wildfire. This is because NATs have several attractions, as we describe next.

Why NATs Succeeded

NATs started as a short term solution while waiting for a new IP to be developed as the long-term solution. The first recog- nized NAT advantages were stated in RFC 1918 [1]:

With the described scheme many large enterprises will need only a relatively small block of addresses from the globally unique IP address space. The Internet at large benefits through conservation of globally unique address space, which will effec- tively lengthen the lifetime of the IP address space. The enterpris- es benefit from the increased flexibility provided by a relatively large private address space.

The last point deserves special emphasis. Indeed, anyone can use a large block of private IP addresses — up to 16 mil- lion without asking for permission — and then connect to the rest of the Internet by using only a single public IP address. A big block of private IP addresses provides the much needed room for future growth. On the other hand, for most if not all user sites, it is often difficult to obtain an IP address block that is beyond their immediate requirements. Today, NAT is believed to offer advantages well beyond the above. Essentially, the mapping table of a NAT provides one level of indirection between hosts behind the NAT and the global Internet. As the popular saying goes, “Any problem in computer science can be solved with another layer of indi- rection.” This one level of indirection means that one never need worry about renumbering the internal network when

changing providers, other than renumbering the public IP address of the NAT box. Similarly, a NAT box also makes multihoming easy. One NAT box can be connected to multiple providers and use one IP address from each provider. Not only does the NAT box shelter the connectivity to multiple ISPs from all the internal hosts, but it also does not require any of its providers to “punch a hole” in the routing announcement (i.e., make an ISP de-aggregate its address block). Such a hole punch would be required if the multihomed site takes an IP address block from one of its providers and asks the other providers to announce the prefix. Furthermore, this one level of indirection also is perceived as one level of protection because external hosts cannot directly initiate communication with hosts behind a NAT, nor can they easily figure out the internal topology. Besides all of the above, two additional factors also con- tributed greatly to the quick adoption of NATs. First, NATs can be unilaterally deployed by any end site without any coor- dination by anybody else. Second, the major gains from deploying a NAT were realized on day one, whereas its poten- tial drawbacks were revealed only slowly and recently.

The Other Side of the NAT

A NAT disallows the hosts behind it from being reachable by

an external host and hence disables it from being a server. However, in the early days of NAT deployment, many people

believed that they would have no need to run servers behind a NAT. Thus, this architectural constraint was viewed as a secu- rity feature and believed to have little impact on users or net- work usage. As an example, the following four justifications for the use of private addresses are quoted directly from RFC 1335 [3].

• In most networks, the majority of the traffic is confined to its local area networks. This is due to the nature of net- working applications and the bandwidth constraints on inter-network links.

• The number of machines that act as Internet servers, that is, run programs waiting to be called by machines in other net- works, is often limited and certainly much smaller than the total number of machines.

• There are an increasingly large number of personal machines entering the Internet. The use of these machines is primarily limited to their local environment. They also can be used as clients such as ftp and telnet to access other machines.

• For security reasons, many large organizations, such as banks, government departments, military institutions, and some companies, allow only a very limited number of their machines to have access to the global Internet. The majori- ty of their machines are purely for internal use. As time goes on, however, the above reasoning has largely been proven wrong. First, network bandwidth is no longer a fundamental con- straint today. On the other hand, voice over IP (VoIP) has become a popular application over the past few years. VoIP changed the communication paradigm from client-server to a peer-to-peer model, meaning that any host may call any other host. Given the large number of Internet hosts that are behind NAT, several NAT traversal solutions have been developed to support VoIP. A number of other recent peer- to-peer applications, such as BitTorrent, also have become popular recently, and each must develop its own NAT traver- sal solutions. In addition to the change of application patterns, a few other problems also arise due to the use of non-unique, pri-

vate IP addresses with NATs. For instance, a number of busi- ness acquisitions and mergers have run into situations where two networks behind NATs were required to be interconnect- ed, but unfortunately, they were running on the same private address block, resulting in address conflicts. Yet another problem emerged more recently. The largest allocated private address block is 10.0.0.0/8, commonly referred to as net-10. The business growth of some provider and enterprise net- works is leading to, or already has resulted in, the net-10 address exhaustion. An open question facing these networks is what to do next. One provider network migrated to IPv6; a number of others simply decided on their own to use another unallocated IP address block [15]. It is also a common misperception that a NAT box makes an effective firewall. This may be due partly to the fact that in places where NAT is deployed, the firewall function often is implemented in the NAT box. A NAT box alone, however, does not make an effective firewall, as evidenced by the fact that numerous home computers behind NAT boxes have been compromised and have been used as launch pads for spam or distributed denial of service (DDoS) attacks. Firewalls estab- lish control policies on both incoming and outgoing packets to minimize the chances of internal computers being compro- mised or abused. Making a firewall serve as a NAT box does not make it more effective in fencing off malicious attacks; good control polices do.

Why the Opportunity of Standardizing NAT Was Missed

During the decade following the deployment of NATs, a big debate arose in the IETF community regarding whether NAT should, or should not, be deployed. Due to its use of private addresses, NAT moved away from the basic IP model of pro- viding end-to-end reachability between hosts, thus represent- ing a fundamental departure from the original Internet architecture. This debate went on for years. As late as 2000, messages posted to the IETF mailing list by individual mem- bers still argued that NAT was architecturally unsound and that the IETF should in no way endorse its use or develop- ment. Such a position was shared by many people during that time. These days most people would accept the position that the IETF should have standardized NAT early on. How did we miss the opportunity? A simple answer could be that the crys- tal ball was cloudy. I believe that a little digging would reveal a better understanding of the factors that clouded our eyes at the time. As I see it from my personal viewpoint, the follow- ing factors played a major role. First, the feasibility of designing and deploying a brand new IP was misjudged, as were the time and effort required for such an undertaking. Those who were opposed to standardiz- ing NAT had hoped to develop a new IP in time to meet the needs of a growing Internet. Unfortunately, the calculation was way off. While the development of a new IP was taking its time, Internet growth did not wait. Network address transla- tion is simply an inevitable consequence that was not clearly recognized at the time. Second, the community faced a difficult question regarding how strictly one should stick to architectural principles, and what can be acceptable engineering trade-offs. Architectural principles are guidelines for problem solving; they help guide us toward developing better overall solutions. However, when the direct end-to-end reachability model was interpreted as an absolute rule, it ruled out network address translation as a feasible means to meet the instant high demand for IP

addresses at the time. Furthermore, sticking to the architec- tural model in an absolute way also contributed to the one- sided view of the drawbacks of NATs, hence the lack of a full appreciation of the advantages of NATs as we discussed earli- er, let alone any effort to develop a NAT-traversal solution that can minimize the impact of NATs on end-to-end reacha- bility. Yet another factor was that given that network address translation could be deployed unilaterally by a single party alone, there was not an apparent need for standardization. This seemingly valid reasoning missed an important fact: a NAT box does not stand alone; rather it interacts both direct- ly with surrounding IP devices, as well as indirectly with remote devices through IP packet handling. The need for standardizing network address translation behavior has since been well recognized, and a great effort has been devoted to developing NAT standards in recent years [16]. Unfortunately the early misjudgment on NAT already has cost us dearly. While the big debate went on through the late 1990s and early part of the first decade of this century, NAT deployment was widely rolled out, and the absence of a stan- dard led to a number of different behaviors among various NAT products. A number of new Internet protocols also were developed or finalized during the same time period, such as IPSec, Session Announcement Protocol (SAP), and Session Initiation Protocol (SIP), to name a few. Their designs were based on the original model of IP architecture, wherein IP addresses are assumed to be globally unique and globally reachable. When those protocols became ready for deploy- ment, they faced a world that was mismatched with their design. Not only were they required to solve the NAT traver- sal problem, but the solutions also were required to deal with a wide variety of NAT box behaviors. Although NAT is accepted as a reality today, the lessons to learn from the past are yet to be clarified. One example is the recent debate over Class-E address block usage [17]. Class-E refers to the IP address block 240.0.0.0/4 that has been on reserve until now. As such, many existing router and host implementations block the use of Class-E addresses. Putting aside the issue of required router and host changes to enable Class-E usage, the fundamental debate has been about whether this Class-E address block should go into the public address allocation pool or into the collection of private address allocations. The latter would give those networks that face net-10 exhaustion a much bigger private address block to use. However, this gain is also one of the main arguments against it, as the size limitation of private addresses is consid- ered a pressure to push those networks facing the limitation to migrate to IPv6, instead of staying with NAT. Such a desire sounds familiar; similar arguments were used against NAT standardization in the past. However if the past is any indica- tion of the future, we know that pressures do not dictate new protocol deployment; rather, economical feasibility does. This statement does not imply that migrating to IPv6 brings no economical feasibility. On the contrary, it does, especially in the long run. New efforts are being organized both in protocol and tools development to smooth and ease the transition from IPv4 to IPv6 and in case studies and documentation to show clearly the short- and long-term gains from deploying IPv6.

Looking Back and Looking Forward

The IPv4 address space exhaustion predicted long ago is final- ly upon us today, yet the IPv6 deployment is barely visible on the horizon. What can and should be done now to enable the Internet to grow along the best path forward? I hope this review of NAT history helps shed some light on the answer.

First, we should recognize not only the fact that IPv4 net- work address translation is widely deployed today, but also recognize its perceived benefits to end users as we discussed in a previous section. We should have a full appraisal of the pros and cons of NAT boxes; the discussion in this article merely serves as a starting point. Second, it is likely that some forms of network address translation boxes will be with us forever. Hopefully, a full appraisal of the pros and cons of network address translation would help correct the view that all network address transla- tion approaches are a “bad thing” and must be avoided at all costs. Several years ago, an IPv4 to IPv6 transition scheme called Network Address Translation-Protocol Translation (NAT-PT; see [18]) was developed but later classified to his- torical status, 1 mainly due to the concerns that:

• NAT-PT works in much the same way as an IPv4 NAT box.

• NAT-PT does not handle all the transition cases.

However, in view of IPv4 NAT history, it seems worthwhile to revisit that decision. IPv4, together with IPv4 NAT, will be with us for years to come. NAT-PT seems to offer a unique value in bridging IPv4-only hosts and applications with IPv6- enabled hosts and networks. There also have been discussions of the desire to perform address translations between IPv6 networks as a means to achieve several goals, including insu- lating one’s internal network from the outside. This question of “Whither IPv6 NAT?” deserves further attention. Instead of repeating the mistakes with IPv4 NAT, the Internet would be better off with well-engineered standards and operational guidelines for traversing IPv4 and IPv6 NATs that aim at maximizing interoperability. Furthermore, accepting the existence of network address translation in today’s architecture does not mean we simply take the existing NAT traversal solutions as given. Instead, we should fully explore the NAT traversal design space to steer the solution development toward restoring the end-to-end reachability model in the original Internet architecture. A new effort in this direction is the NAT traversal through tunneling (NATTT) project [19]. Contrary to most existing NAT traver- sal solutions that are server-based or protocol-specific, NATTT aims to restore end-to-end reachability among Inter- net hosts in the presence of NATs, by providing generic, incrementally deployable NAT-traversal support for all appli- cations and protocols. Last, but not least, I believe it is important to understand that successful network architectures can and should change over time. All new systems start small. Once successful, they grow larger, often by multiple orders of magnitude as is the case of the Internet. Such growth brings the system to an entirely new environment that the original designers may not have envisioned, together with a new set of requirements that must be met, hence the necessity for architectural adjust- ments. To properly adjust a successful architecture, we must have a full understanding of the key building blocks of the architec- ture, as well as the potential impact of any changes to them. I believe the IP address is this kind of key building block that touches, directly or indirectly, all other major components in the Internet architecture. The impact of IPv4 NAT, which changed IP address semantics, provides ample evidence. Dur- ing IPv6 development, much of the effort also involved a change in IP address semantics, such as the introduction of new concepts like that of the site-local address. The site-local address was later abolished and partially replaced by unique

1 Historical status means that a protocol is considered obsolete and is thus removed from the Internet standard protocol set.

local IPv6 unicast addresses (ULA) [20], another new type of IP address. The debate over the exact meaning of ULA is still going on. The original IP design clearly defined an IP address as being globally unique and globally reachable and as identify- ing an attachment point to the Internet. As the Internet con- tinues to grow and evolve, recent years have witnessed an almost universal deployment of middleboxes of various types. NATs and firewalls are dominant among deployed middleboxes, though we also are seeing increasing numbers of SIP proxies and other proxies to enable peer-to-peer- based applications. At the same time, proposals to change the original IP address definition, or even redefine it entire- ly, continue to arise. What should be the definition, or defi- nitions, of an IP address today, especially in the face of various middleboxes? I believe an overall examination of the role of the IP address in today’s changing architecture deserves special attention at this critical time in the growth of the Internet.

Acknowledgments

I sincerely thank Mirjam Kuhne and Wendy Rickard for their help with an earlier version of this article that was posted in the online IETF Journal of October 2007. I also thank the co- editors and reviewers of this special issue for their invaluable comments.

References

[1] Y. Rekhter et al., “Address Allocation for Private Internets,” RFC 1918, 1996. [2] D. Clark et al., “Towards the Future Internet Architecture,” RFC 1287, 1991. [3] Z. Wang and J. Crowcroft, “A Two-Tier Address Structure for the Internet: A Solution to the Problem of Address Space Exhaustion,” RFC 1335, 1992. [4] J. Rosenberg et al., “STUN: Simple Traversal of User Datagram Protocol (UDP) through Network Address Translators (NATs),” RFC 3489, 2003. [5] J. Rosenberg, R. Mahy, and P. Matthews, “Traversal Using Relays around NAT (TURN),” draft-ietf-behave-turn-08, 2008. [6] C. Huitema, “Teredo: Tunneling IPv6 over UDP through Network Address Translations (NATs),” RFC 4380, 2006. [7] S. Kent and R. Atkinson, “Security Architecture for the Internet Protocol, RFC 2401, 1998. [8] J. Postel and J. Reynolds, File Transfer Protocol (FTP), RFC 959, 1985. [9] J. Postel, Internet Protocol Specification, RFC 791, 1981. [10] P. Tsuchiya and T. Eng, “Extending the IP Internet through Address Reuse,” ACM SIGCOMM Computer Commun. Review, Sept. 1993. [11] K. Egevang and P. Francis, “The IP Network Address Translator (NAT),” RFC 1631, 1994. [12] C. Huitema, “IAB Recommendation for an Intermediate Strategy to Address the Issue of Scaling,” RFC 1481, 1993. [13] R. M. Hinden, “IP Next Generation Overview,” http://playground.sun.com/ ipv6/INET-IPng-Paper.html, 1995. [14] L. Zhang, “An Overview of Multihoming and Open Issues in GSE,” IETF J., Sept. 2006. [15] L. Vegoda, “Used but Unallocated: Potentially Awkward /8 Assignments,” Internet Protocol J., Sept. 2007. [16] http://www.ietf.org/html.charters/behave-charter.html; IETF BEHAVE Work- ing Group develops requirements documents and best current practices to enable NATs to function in a deterministic way, as well as advises on how to develop applications that discover and reliably function in environments with the presence of NATs. [17] http://www.ietf.org/mail-archive/web/int-area/current/msg01299.html; see the message dated 12/5/07 with subject line “240/4” and all the fol- low-up. [18] G. Tsirtsis and P. Srisuresh, “Network Address Translation-Protocol Transla- tion (NAT-PT),” RFC 2766, 2000. [19] E. Osterweil et al., “NAT Traversal through Tunneling (NATTT),” http:// www.cs.arizona.edu/˜bzhang/nat/ [20] R. M. Hinden and B. Haberman, “Unique Local IPv6 Unicast Addresses,” RFC 4193, 2005.

Biography

LIXIA ZHANG (lixia@cs.ucla.edu) received her Ph.D. in computer science from the Massachusetts Institute of Technology. She was a member of research staff at the Xerox Palo Alto Research Center before joining the faculty of the UCLA Comput- er Science Department in 1995. In the past she served as vice chair of ACM SIGCOMM and co-chair of the IEEE ComSoC Internet Technical Committee. She is currently serving on the Internet Architecture Board.

Behavior and Classification of NAT Devices and Implications for NAT Traversal Andreas Müller and Georg
Behavior and Classification of NAT Devices and Implications for NAT Traversal Andreas Müller and Georg
Behavior and Classification of NAT Devices and Implications for NAT Traversal Andreas Müller and Georg

Behavior and Classification of NAT Devices and Implications for NAT Traversal

Andreas Müller and Georg Carle, Technische Universität München Andreas Klenk, Universität Tübingen

Abstract

For a long time, traditional client-server communication was the predominant com- munication paradigm of the Internet. Network address translation devices emerged to help with the limited availability of IP addresses and were designed with the hypothesis of asymmetric connection establishment in mind. But with the growing success of peer-to-peer applications, this assumption is no longer true. Consequent- ly network address translation traversal became a field of intensive research and standardization for enabling efficient operation of new services. This article pro- vides a comprehensive overview of NAT and introduces established NAT traversal techniques. A new categorization of applications into four NAT traversal service categories helps to determine applicable techniques for NAT traversal. The interac- tive connectivity establishment framework is categorized, and a new framework is introduced that addresses scenarios that are not supported by ICE. Current results from a field test on NAT behavior and the success ratio of NAT traversal tech- niques support the feasibility of this classification.

WW hen the Internet Protocol (IP) was designed, the growth of the Internet to its current size was not imaginable. Therefore, it was reason- able to use a fixed 32-bit field to identify a

host based on its IP address. This limited address range makes

it impossible to assign globally unique IPv4 addresses to the

growing number of networked devices. Furthermore, request- ing an IP address for every newly added device results in an unacceptable administration overhead. The authors in [1] pro- pose to assign a number of public IP addresses to a designat- ed border router instead of configuring certain hosts with

addresses that can be routed globally. The border router is then responsible for translating IP addresses between the pri- vate and the public domains, allowing as many simultaneous connections as public IP addresses were assigned. This allows

a host within the local network to access the Internet even

though it has a private IP address. This technique became known as network address translation (NAT). Because the translation of addresses breaks the end-to-end connectivity model of the IP, newly developed services following the peer- to-peer (P2P) paradigm such as file sharing, instant messag- ing, and voice over IP (VoIP) applications suffer from the existence of NAT. Thus, NAT traversal is an important prob- lem today. And even in the future, after a possible success of IPv6, companies and home users still might deploy NAT devices to hide their topologies from Internet service providers (ISPs). There are two possible approaches to the problem.

One direction within the Internet Engineering Task Force (IETF) Behave Working Group [2] is to cope with existing NAT implementations and to establish standards for the

detection of NAT behavior and for NAT traversal. On the other hand, the IETF also standardizes behavioral properties for NATs to work in conjunction with IETF protocols (e.g., Datagram Congestion Control Protocol [DCCP], Internet Control Message Protocol [ICMP], Stream Control Transmis- sion Protocol [SCTP]). Enterprise class NATs are among the first to incorporate new features introduced through standard- ization. However, the large scale deployment of residential gateways with NAT functionality prohibits the change of NAT and requires the use of protocols that work with existing NATs. This is also the focus of this article, where we treat NATs as black boxes rather than trying to change them.

NAT Behavior

Today, a NAT device usually is used to share a single public IP address among a number of private end systems. The NAT maintains a table, listing all connections between the public and the private domains. For every connection attempt (e.g., a Transmission Control Protocol synchronize [TCP SYN] pack- et) coming from an internal host, the NAT creates a new entry in the list. In NAT terminology this entry is called a binding [3]. Each entry contains the source IP address and the source port. The NAT replaces the source IP address with its public IP address. The source port is replaced using one of the strategies explained later in this section. Although the concept of NAT was published as early as 1994 [1], no common approach for NAT emerged. Current NAT implementations not only differ from vendor to vendor but also from model to model, which leads to compatibility

Classification

NAT property

Port binding

Port preservation No port preservation Port overloading Port multiplexing

NAT binding

Endpoint-independent Address- (port)-dependent Connection-dependent

Endpoint filtering

Independent Address restricted Address and port restricted

Table 1. NAT behavior categories and possible NAT properties.

issues. If an application works with one particular NAT, this does not imply that it always works in a NATed environment. Therefore, it is very important to understand and classify existing NAT implementations in order to design applications that can work in combination with current NATs. The classifi- cation in this article is mainly derived from simple traversal of User Datagram Protocol (UDP) through NAT (STUN) [4], whereas the address binding and mapping behavior follows the terminology used in RFC 4787 [5]. This section covers only topics that are required for the understanding of this article. A detailed discussion and further information (includ- ing test results) is given in [6] (for TCP) and [5] (for UDP). Binding covers “context based packet translation” [7], which describes the strategy the NAT uses to assign a public trans- port address (combination of IP address and port) to a new state in the NAT. Filtering, or packet discard, shows how the NAT handles (or discards) packets trying to use an existing mapping. Table 1 shows the different categories and their pos- sible properties. Port binding describes the strategy a NAT uses for the assignment. With port preservation, the NAT assigns an external port to a new connection; it attempts to preserve the local port number if possible. Port overloading is problematic and rarely occurs. A new connection takes over the binding, and the old connection is dropped. Port multi- plexing is a very common strategy where ports are demulti- plexed based on the destination transport address. Incoming packets can now carry the same destination port and are dis- tinguished by the source transport address. NAT binding deals with the reuse of existing bindings. That is, if an internal host closes a connection and establishes a new one from the same source port, NAT binding describes the assignment strategy for the new connection. As shown in Table 1, the NAT binding is organized into three categories. With Endpoint Independent, the external port is only depen- dent on the source transport address of the connection. As long as a host establishes a connection from the same source IP address and port, the mapping does not change. The assignment is dependent on the internal and the external transport address with the Address (Port) Dependent strategy. As long as consecutive connections from the same source to the same destination are established, the mapping does not change. As soon as we use a different destination, the NAT changes the external port. With a Connection Dependent bind- ing, the NAT assigns a new port to every connection. We dis- tinguish between NATs that increase the new port number by a specific (and well predictable) delta and NATs that assign random port numbers to the new mappings. Endpoint filtering describes how existing mappings can be used by external hosts and how a NAT handles incoming con- nection attempts that are not part of a response. Independent Filtering allows inbound connections independent of the

source transport address of the packet. As long as the destina- tion transport address of a packet matches an existing state, the packet is forwarded. With Address Restricted Filtering, the NAT forwards only packets coming from the same host (matching IP address) to which the initial packet was sent. Address and Port Restricted Filtering also compares the source port of the inbound packet in addition to address restricted filtering.

NAT Traversal Problem

To work properly, the NAT must have access to the protocol headers at layers 3 and 4 (in case of a network address port translation [NAPT]). Additionally, for every incoming packet, the NAT must already have a state listed in its table. Other- wise, it cannot find the related internal host to which the packet belongs. According to RFC 3027 [8], the NAT traver- sal problem can be separated into three categories, which are presented in this section. In addition to the three problems, we identified Unsupported Protocols as a new category. The first problem occurs if a protocol uses Realm-Specific IP Addresses in its payload. That is, if an application layer pro- tocol such as the Session Initiation Protocol (SIP) uses a transport address from the private realm within its payload signalizing where it expects a response. Because regular NATs do not operate above layer 4, application layer protocols typi- cally fail in such scenarios. A possible solution is the use of an application layer gateway (ALG) that extends the functionali- ty of a NAT for specific protocols. However, an ALG sup- ports only the application layer protocols that are specifically implemented and may fail when encryption is used. The second category is P2P Applications. The traditional Internet consists of servers located in the public realm and clients that actively establish connections to these servers. This structure is well suited for NATs because for every con- nection attempt (e.g., a TCP SYN) coming from an internal client, the NAT can add a mapping to its table. But unlike client-server applications, a P2P connection can be initiated by any of the peers regardless of their location. However, if a peer in the private realm tries to act as a traditional server (e.g., listening for a connection on a socket), the NAT is unaware of incoming connections and drops all packets. A solution could be that the peer located in the private domain always establishes the connection. But what if two peers, both behind a NAT, want to establish a connection to each other? Even if the security policy would allow the connection, it can- not be established. The third category is a combination of the first two. Bun- dled Session Applications, such as File Transfer Protocol (FTP) or SIP/Session Description Protocol (SDP), carry realm-specific IP addresses in their payload to establish an additional session. The first session is usually referred to as the control session, whereas the newly created session is called the data session. The problem here is not only the realm-specific IP addresses, but the fact that the data session often is established from the public Internet toward the pri- vate host, a direction the NAT does not permit (e.g., active FTP). Unsupported Protocols are typically newly developed trans- port protocols such as the SCTP or the DCCP that cause problems with NATs even if an internal host initiates the con- nection establishment. This is because current NATs do not have built-in support for these protocols. The unsupported protocols also cover protocols that cannot work with NATs because their layer 3 or layer 4 header is not available for translation. This happens when using encryption protocols such as IPSec.

(3) (3) (2) (1) (1) (1) (1) (2) (2) (1) Requester Service Service a) b)
(3)
(3)
(2)
(1)
(1)
(1)
(1)
(2)
(2)
(1)
Requester
Service
Service
a)
b)
c)
d)
(2)
(3)
(3)

Figure 1. NAT traversal service categories for applications: a) RNT; b) GSP; c) SPPS; d) SSP.

NAT Traversal Service Categories

Instead of classifying the NAT behavior (see classification in STUN [4]), we defined four NAT traversal service categories, each making different assumptions about the purpose of the connection establishment and the infrastructure that is avail- able. Our categorization emphasizes that the applicability of many NAT traversal techniques depends on the support of a combination of requester, the responder, globally reachable infrastructure nodes, and the role of the application. On the one hand, server applications set up a socket and wait for con- nections (which also applies to P2P applications). On the other hand, client applications such as VoIP clients actively initiate a connection and wait for an answer on a different port (bundled session applications). Other applications work only across NATs if both ends participate in the connection establishment (unsupported protocols). Thus, we differentiate between supporting a service and supporting a client. In this article, the client is called the requester because it actively ini- tiates a connection. The behavior of the NAT is important because it allows or prohibits certain NAT traversal techniques within one service category. If only one end implements NAT traversal support (e.g., by running a stand-alone framework or by built-in NAT traversal functionality), NAT traversal techniques that rely on a collaboration of both ends (e.g., ICE) are not applicable. Our first category, requester side NAT traversal (RNT), covers scenarios where only the requester side supports NAT traversal (e.g., the application or the NAT itself). RNT helps applications that actively participate in the con- nection establishment and still suffer from the existence of NATs. Typical examples are applications that have prob- lems with realm-specific IP addresses in their payload. This applies to protocols using in-band signaling on the applica- tion layer, which is related to bundled session applications with asymmetric connection establishment (e.g., VoIP using SIP/SDP). The second category, global service provisioning (GSP), assumes that the host providing the service implements NAT traversal support, helping to make a service globally accessi- ble. This is done by creating and maintaining a NAT mapping that then accepts multiple connections from previously unknown clients (Fig. 1). This is the main difference from RNT, which only creates a NAT mapping for one particular session (e.g., one call in the case of VoIP). The last two categories assume support at both ends, the service and the requester. On the one side, NAT traversal is required to make a service behind a NAT globally accessible, whereas on the other side, the support at the requester allows the use of sophisticated techniques through coordinated action. Thus, service provisioning using pre-signaling (SPPS) extends the GSP category by the assumption that both hosts have interoperable frameworks (e.g., ICE [9]; NAT, URIs, Tunnels, SIP, and STUNT [NUTSS] [10]; NATBlaster [11]; or NatTrav [12]) running. This allows a selection from all avail- able NAT traversal solutions, which leads to a high success rate of NAT traversal. In Fig. 1, the two hosts use a ren- dezvous point to agree on a NAT traversal technique. After

creating the mapping in step 2, the service is accessible by any host, depending on the selected NAT traversal technique and the filtering strategy of the NAT. SPPS supports all types of services where a one-to-one connection is sufficient and pre- signaling is available. The last category, secure service provisioning (SSP), is an extension of SPPS and addresses scenarios that require autho- rization of the remote party before initiating the NAT traver- sal process. The hereby established channel must be accessible only by the authorized remote party. This requires additional functionality that enforces this policy and only allows autho- rized users to access the service. The policy enforcement can be done at the NAT itself, at a data relay, or at a firewall. Table II depicts all four service categories with popular NAT traversal techniques and shows the implications for automated NAT traversal and required signaling. First we distinguish between the service and the requester. “Support at the ser- vice” means, for example, that a framework must be deployed at the same host providing the service. The same applies to the requester. “RP” means that a rendezvous point is required for relaying data back and forth. “Signaling messages” means that some sort of signaling protocol is used for NAT traversal. Again, we differentiate between signaling at the service and signaling at the requester. A rendezvous point for signaling messages is required in case of pre-signaling. Finally, “stream independent” describes the requirement for consecutive con- nections. For example, a port forwarding entry must be creat- ed only once, whereas hole punching [13] requires sending a new hole punching packet for every new stream (with restrict- ed filtering). Table 2 shows the main differences of our service cate- gories. RNT deals with bundled session applications that wait on a port after initiating a session (e.g., via a SIP INVITE). GSP requires only support of the service and aims to make a service globally reachable for multiple clients. SPPS and SSP combine these categories and require support at both ends. The requester initiates pre-signaling to exchange information about a global end point. The service then creates a mapping in the NAT that can be used by the client.

Applicability of NAT Traversal Techniques for NAT Traversal Service Categories

There are many different techniques for solving the NAT traversal problem in specific scenarios, but none of them pro- vides a solution that works well with all NATs, applications, and network topologies. Another article explains many of the available protocols for NAT traversal [14] in general. This sec- tion describes the applicability of existing techniques from the applications point of view. RNT is required for protocols using in-band signaling (bun- dled session applications). Therefore, one common approach is to integrate RNT into these applications (e.g., the VoIP client), to establish port bindings on the fly. One possibility is the integration of a universal plug and play (UPnP) client. Another option is to use ALGs that are integrated in the NAT, interpreting in-band signaling and establishing map-

Service

   

Requires support at

   

Signaling messages

 

Stream-

category

NAT traversal techniques

Service

Requester

RP

NAT

Service

Requester

RP

STUN

independent

 

NAT with ALG

     

X

         

RNT

UPnP (for bundled session applications)

 

X

 

X

 

X

   

X

 

UPnP (port forwarding)

X

   

X

X

     

X

GSP

Hole punching — independent filtering

X

     

X

   

X

X

Open data relay (e.g., RSIP)

X

 

X

 

X

 

X

 

X

 

Hole punching — independent binding

X

X

   

X

X

X

X

 

SPPS

UPnP

X

X

 

X

 

X

X

X

 

Closed/open data relay (e.g., TURN, Skype)

X

X

X

 

X

X

X

   

Tunneling (e.g., over UDP)

X

X

   

X

X

   

X

 

Hole punching — restricted filtering

X

X

   

X

X

X

X

 

NSIS NATFW NSLP

X

X

 

X

X

X

     

SSP

Closed data relay (e.g., TURN)

X

X

X

 

X

X

X

   

Tunneling (e.g., over secure channel)

X

X

   

X

X

   

X

Table 2. Service categories and their implications for automated NAT traversal; RP denotes rendezvous point.

pings accordingly. ALGs are not a general solution because the NAT must implement the required logic for each proto- col, and end-to-end security prohibits the interpretation of the signaling by the NAT. GSP depends on NAT traversal techniques that allow unre- stricted access to a public end point. A control protocol can be used to directly establish a port forwarding entry in the mapping tables of the NAT, for instance, with UPnP [15]. Port forwarding entries created by UPnP are easy to maintain and work independently from NAT behavior. However, UPnP only works if the NAT is in the local network on the path to the other end point. Thus, nested NATs are not allowed, and path changes break the connectivity. Hole punching is an alternative if UPnP is not applicable and works for NATs with an independent filtering strategy. The mapping must be refreshed periodically, for instance, by sending keep-alive packets. For NATs other than full-cone, hole-punching for GSP cannot be used because the source port of the request is unknown in advance. SSPS makes no assumption about the accessibility of a cre- ated mapping, thus all possible techniques are applicable. Dif- ferent from GSP, hole-punching for SPPS works as long as port prediction is possible. For NATs implementing restricted filtering, pre-signaling helps to create the appropriate map- ping because the five-tuple of the connection is exchanged. Pre-signaling also enables the establishment of an UDP tun- nel, allowing the encapsulation of unsupported protocols. SPPS also can use UPnP to establish port forwarding entries for one session.

SSP is an extension to SPPS that allows only authorized hosts to allocate and to use a mapping. Protocols that autho- rize requests and assume control over the middlebox, such as middlebox communication (MIDCOM) [16] or the NAT/Fire- wall Next Step in Signaling (NSIS) Layer Protocol [17] qualify for SSP. The advantage of NSIS is that it can discover and configure multiple middleboxes along the data path, thus sup- porting complex scenarios with nested NATs and multipath routing. However, if one NAT on the path does not support the protocol, NSIS fails. Using NSIS and MIDCOM for SSP requires restrictive rules that allow only authorized clients to use the mapping, for instance, by opening pinholes for IP five- tuples. UPnP is not useful for SSP because it forwards inbound packets without considering the source transport address. Hole punching can be used only with SSP if the NAT implements a restricted filtering strategy. All cases discussed previously rely on additional measures to prohibit IP spoofing. The use of secure tunnels impedes IP spoofing and allows secure NAT traversal, even for unsupported protocols (e.g., IPSec, SCTP, DCCP). SSP also can be achieved by using traversal using relay NAT (TURN) with authentication, authorization, and secure communication (e.g., via transport layer security [TLS]). ICE [9] is under standardization by the IETF and strives to combine several techniques into a framework flexible enough to work with all network topologies. Because ICE requires both peers to have an ICE implementation running, it can be seen as a technique for SPPS or SSP, depending on the acces- sibility and the security policies of the public endpoint.

NAT traversal request

Requester initiated Access to service Support at service Support at both ends
Requester initiated
Access to service
Support at service
Support at both ends

Support at both ends

Secure Insecure endpoint endpoint SSP SPPS
Secure
Insecure
endpoint
endpoint
SSP
SPPS
Support at client RNT GSP
Support
at client
RNT
GSP
Insecure endpoint endpoint SSP SPPS Support at client RNT GSP Sec ure Inse cure endpoint endpoint
Sec ure Inse cure endpoint endpoint SSP SPPS
Sec ure
Inse cure
endpoint
endpoint
SSP
SPPS

Figure 2. Decision tree for ANTS.

The same is true for solutions such as TURN [18]. TURN is a promising candidate for SPPS, because it provides a relay with a public transport address allowing the exchange of data packets between a TURN client and a public host.

Why Unilateral Solutions Exist

Despite the great flexibility of SPPS and SSP, both categories involve a number of assumptions that are not always satisfied. The most important one is the requirement for both ends (and sometimes also the infrastructure), to support compati- ble versions of the NAT traversal framework. It remains to be seen if the future will bring a sufficiently big deployment of one framework on which to rely for arbitrary applications. The chances are better within homogeneous problem domains, like telecommunication, where such frameworks can be inte- grated with the applications and be distributed in large num- bers. For instance, the adoption of ICE is occurring mainly within the VoIP/SIP community and focusing on VoIP specific use cases. These drawbacks are the reason why RNT and GSP as unilateral solutions for the NAT traversal problems exist. It is easier to enhance an infrastructure under one responsibility than to rely on a solution that requires a global deployment. However, unilateral solutions are limited to the middle- boxes in the given domain. They fail to provide solutions to scenarios with nested NATs and depend on the net- work topology.

Coalescing Unilateral and Cooperative Approaches for NAT Traversal

When investigating existing NAT traversal techniques, we determined that none of them can be used in all scenar- ios. For example, UPnP only supports globally accessible end points, whereas ICE requires both hosts to run the framework. In [19], we proposed a new framework that aims toward providing an advanced NAT traversal service (ANTS) supporting all four service categories. The con- cept of ANTS is based on the idea of reusing previously obtained knowledge about the topology of the network and the capability of the NAT. A small component of ANTS, the NAT tester, is responsible for gathering this information and will be presented (together with some test results) in the next section. If a user decides that a particular application should be reachable from the public Internet, he registers it at a ses- sion manager that keeps track of all applications request-

ing NAT traversal support. With the session manager, ANTS

can provide GSP and RNT directly. Whenever an application

is added and associated with GSP or RNT, the session manag-

er calls the NAT traversal logic and asks to allocate an appro- priate mapping in the NAT. This also requires ANTS to have sufficient knowledge about the applicability of the integrated techniques regarding the service categories. For example, UPnP cannot be used for SSP because it violates the idea of an endpoint that is accessible only by authenticated hosts. Figure 2 shows a decision tree that ANTS uses to establish

a mapping in the NAT. First, we distinguish between requester

initiated NAT traversal on the one hand and the access to a service on the other hand. Then, we must know which ends actually implement ANTS. If both hosts have the framework running, pre-signaling is possible, which leads to a wide choice of techniques depending on the security considerations of the mapping. If only one end supports ANTS, only techniques belonging to GSP or RNT are applicable. Despite some unsolved issues such as the question of how to connect legacy applications to ANTS (e.g., by using a library or a traversal of UDP through NAT [TUN]-based approach), the idea of a knowledge-based framework seems

S. cat.

Prot.

Condition

Suc. rate

 

UDP

(UPnP or HP-UDP) (UPnP or HP-TCP)

90.27%

RNT

TCP

77.84%

 

UDP

(Full Cone and HP-UDP) (Full Cone and HP-TCP) (UPnP or (Full Cone and HP-UDP)) (UPnP or (Full Cone and HP-TCP))

27.03%

TCP

17.30%

GSP

UDP

50.27%

TCP

44.32%

 

UDP

(HP-UDP) (HP-TCP) (HP-TCP or HP-UDP) (UPnP or HP-UDP) (UPnP or HP-TCP) (UPnP or HP-TCP or HP-UDP)

88.65%

TCP

71.35%

TCP

94.59%

SPPS

UDP

90.27%

TCP

77.84%

TCP

95.14%

 

UDP

(Restricted NAT and HP-UDP) (Restricted NAT and HP-TCP)

48.65%

SSP

TCP

38.38%

Table 3. Results of the field test: success rates of NAT traversal tech- niques depending on service categories.

to be the right answer. Thus once implemented, ANTS can help many existing services by integrating several techniques and making its choice based on knowledge about the NAT and the requirements of the application.

Field Test on NAT Traversal

To prove that existing techniques can be adapted to our ser- vice categories, we implemented a NAT tester that acts as a cornerstone for our new framework. This section presents the results of a field test investigating 185 NATs in the wild. For a detailed description including all results, see our Web site:

http://nettest.net.in.tum.de. The first test queries a public STUN server to determine the type of the NAT. Afterward, the NAT tester performs the following connection tests and tries to establish a connection to the host behind the NAT: UPnP, hole punching, and con- necting to a data relay (each for both protocols, UDP and TCP) (Table 3). We then adapted the test results to our work and evaluated the success rates of the individual techniques regarding our defined service categories. Table III shows the categories and the conditions that must be met according to the considera- tions made previously. For example, GSP requires the use of UPnP or hole punching support in combination with a full- cone NAT to make a service globally accessible. Therefore, 50.27 percent of our tested NATs supported a direct connec- tion for UDP and category GSP (44.32 percent for TCP). In all other cases (the remaining percentages), an external relay must be used to provide GSP. For SPPS, which makes no security assumptions, we divided our results into two categories. First we determined the suc- cess rates without considering UPnP. With 88.65 percent of all NATs, we were able to establish a direct connection to the host behind the NAT (71.35 percent for TCP). This rate increased slightly (for TCP to 77.84 percent) when UPnP was an option. The highest success rate for TCP NAT traversal (95.14 percent) was discovered when we also allowed the tun- neling of TCP packets through UDP. SSP allows only authorized hosts to create and to use a mapping. Therefore, a suitable technique for SSP is hole punching in combination with a NAT implementing a restrict- ed filtering strategy. This was supported by 48.65 percent for UDP and 38.38 percent for TCP. The success rate for RNT depends on the effort that is made for the specific protocol. For example, if we assume that we can inspect each signaling packet on the application layer thoroughly, we could adopt the results from SPPS to RNT. If we would only modify the packets in a way that the internal port is reachable by any client, the success rate of GSP would apply to RNT. Finally, we did not measure the effect of NATs with integrated ALGs in this field test.

Conclusion

With the increasing popularity of P2P communication, the NAT traversal problem has become more urgent than ever. Existing solutions have the drawback of supporting only cer- tain types of NATs and cannot be viewed as a general solu- tion to the problem. When analyzing the NAT traversal problem more thoroughly, we discovered that the question of who supports the NAT traversal framework determines which NAT traversal techniques are applicable. Therefore, we iden- tified four NAT traversal service categories that differentiate

between support by service, client, and infrastructure and list- ed applicable NAT traversal techniques for each category. Our findings from a field test showed that there are a number of prospective NAT traversal techniques that enable connec- tivity for each NAT traversal service category. We emphasized how to build upon this categorization to develop a knowledge- based NAT traversal framework. Future frameworks that aspire to support the typical connectivity scenarios of current applications should support all four service categories.

References

[1] K. Egevang and P. Francis, “The IP Network Address Translator (NAT),” IETF RFC 1631, May 1994. [2] IETF, “Behavior Engineering for Hindrance Avoidance (behave);” http://www.ietf.org [3] P. Srisuresh and M. Holdrege, “IP Network Address Translator (NAT) Termi- nology and Considerations,” IETF RFC 2663, Aug. 1999. [4] J. Rosenberg et al., “STUN: Simple Traversal of User Datagram Protocol (UDP) through Network Address Translators (NATs),” IETF RFC 3489, Mar. 2003. [5] E. F. Audet and C. Jennings, “NAT Behavioral Requirements for Unicast UDP,” IETF RFC 4787, Jan. 2007. [6] S. Guha and P. Francis, “Characterization and Measurement of TCP Traver- sal through NATs and Firewalls,” Proc. ACM Internet Measurement Conf., Berkeley, CA, Oct. 2005. [7] G. Huston, “Anatomy: A Look Inside Network Address Translators,” The Internet Protocol J., vol. 7, 2004, pp. 2–32. [8] M. Holdrege and P. Srisuresh, “Protocol Complications with the IP Network Address Translator,” IETF RFC 3027, Jan. 2001. [9] J. Rosenberg, “Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) Traversal for Offer/Answer Protocols,” IETF Internet draft, work in progress, Oct. 2007. [10] P. Francis, S. Guha, and Y. Takeda, “NUTSS: A SIP-based Approach to UDP and TCP Network Connectivity,” Cornell Univ., Panasonic Commun., tech. rep., 2004. [11] A. Biggadike et al., “NATBLASTER: Establishing TCP Connections between Hosts behind NATs,” ACM SIGCOMM Asia Wksp., Beijing, China, 2005. [12] J. Eppinger, “TCP Connections for P2P Applications — A Software Approach to Solving the NAT Problem,” Carnegie Mellon Univ., Pittsburgh, PA, tech. rep., 2005. [13] B. Ford, P. Srisuresh, and D. Kegel, “Peer-to-Peer Communication across Network Address Translation,” MIT, tech. rep., 2005. [14] H. Khlifi, J. Gregoire, and J. Phillips, “VoIP and NAT/Firewalls: Issues, Traversal Techniques, and a Real-World Solution,” IEEE Commun. Mag., July 2006. [15] U. Forum, “Internet Gateway Device (IGD) Standardized Device Control Protocol,” Nov. 2001. [16] P. Srisuresh et al., “Middlebox Communication Architecture and Frame- work,” IETF RFC 3303, Aug. 2002. [17] M. Stiemerling et al., “NAT/Firewall NSIS Signaling Layer Protocol (NSLP),” IETF Internet draft, Feb. 2008. [18] J. Rosenberg, R. Mahy, and P. Matthews, “Traversal Using Relays around NAT (TURN),” IETF Internet draft, work in progress, June 2008. [19] A. Müller, A. Klenk, and G. Carle, “On the Applicability of Knowledge- Based NAT-Traversal for Future Home Networks,” Proc. IFIP Networking 2008, Springer, Singapore, May 2008.

Biographies

ANDREAS MÜLLER (mueller@net.in.tum.de) received his diploma degree in comput- er science from the University of Tübingen, Germany in 2007. Currently, he is a research assistant and Ph.D. candidate at the Network Architecture and Services Department at the Technical University of Munich. His research interests include middleboxes, P2P systems, and autonomic networking.

KLENK (klenk@informatik.uni-tuebingen.de) earned his diploma degree

in computer science from Ulm University, Germany, in 2003. He is a Ph.D. can- didate and research assistant at the University of Tübingen and works with Pro- fessor Carle. He contributes to European research projects in the telecommunication field. His research interests include negotiation and security in autonomic systems.

ANDREAS

CARLE (carle@net.in.tum.de) received a M.Sc. degree from Brunel Univer-

sity London in 1989, a diploma degree in electrical engineering from the Univer- sity of Stuttgart in 1992, and a doctoral degree from the faculty of computer science, University of Karlsruhe in 1996. He is a full professor in computer sci- ence at the Technical University of Munich, where he is chair of the Department of Network Architecture and Services. Among the focal interests of his research are Internet technology and mobile communication in combination with security.

GEORG

Modeling Middleboxes Dilip Joseph and Ion Stoica, University of California at Berkeley Abstract The lack
Modeling Middleboxes Dilip Joseph and Ion Stoica, University of California at Berkeley Abstract The lack
Modeling Middleboxes Dilip Joseph and Ion Stoica, University of California at Berkeley Abstract The lack

Modeling Middleboxes

Dilip Joseph and Ion Stoica, University of California at Berkeley

Abstract

The lack of a concise and standard language to describe diverse middlebox func-

tionality and deployment configurations adversely affects current middlebox deploy- ment, as well as middlebox-related research. To alleviate this problem, we present

a simple middlebox model that succinctly describes how different middleboxes pro-

cess packets and illustrate it by representing four common middleboxes. We set up

a pilot online repository of middlebox models and prototyped model inference and validation tools.

MM iddleboxes, like firewalls, NATs, load bal- ancers, and intrusion-prevention boxes have become an integral part of networks today. There is great diversity in how these middle-

boxes process and transform packets, and in how they are configured and deployed. For example, a firewall is commonly connected inline on the physical network path and transpar- ently forwards packets unmodified or drops them. A load bal- ancer, on the other hand, rewrites packet headers and contents and often requires packets to be explicitly IP addressed and forwarded to it. There is currently no standard way to succinctly describe the complexity and diversity of middlebox packet processing and deployment mechanisms. Middlebox taxonomies like RFC 3234 [1] provide only a high-level classification of mid- dleboxes. Details about middlebox operations and deployment configurations often are buried in different middlebox and vendor specific configuration manuals or simply are not docu- mented clearly. Efforts like the Unified Firewall Model [2] and BEHAVE [3] provide models to describe the operations of specific middleboxes like firewalls and NATs. The lack of a concise and standard language to describe dif- ferent middleboxes adversely affects current middlebox deploy- ment, as well as hinders middlebox-related research. Correctly deploying and configuring a middlebox is a challenging task by itself. Without a clear understanding of how different middle- boxes process packets and interact with the network and with other middleboxes, network planning, verification of opera- tional correctness, and troubleshooting become even more complicated. In our own research experience of designing and implementing the policy-aware switching layer [4] — a new mechanism to overhaul the ad hoc manner in which middle- boxes are deployed in data centers today — the non-availabili- ty of clear information about how some middleboxes process packets led to initial design decisions that were wrong and that later manifested as hard-to-debug errors while testing. In this article, we present a general model to clearly and succinctly describe the functionality of a middlebox and deployment configurations. Through sets of pre-conditions and processing rules, the model describes the types of packets expected by a middlebox and how it transforms them. Later, we provide more details of our model and illustrate it by rep- resenting four common middleboxes. The middlebox model provides a standard language to con- cisely describe different middleboxes. We are building an

online repository of middlebox models at http://www.middle- box.org, which we envision as filled with models of various commonly used middleboxes. To ease model construction, we prototyped a tool that infers hints about the operations of a particular middlebox through black box testing. We also pro- totyped a tool that validates the operations of a middlebox against its model and thus helps detect unexpected behavior. We discuss these and other applications of our model later.

The Model

RFC 3234 [1] defines a middlebox as “an intermediary device performing functions other than the normal, standard functions of an IP router on the datagram path between a source host and destination host.” We refine this high-level definition of a mid- dlebox to construct a simple model that describes various aspects of middlebox functionality and operations. A middlebox in our model consists of zones, input pre-conditions, state databases, pro- cessing rules, auxiliary traffic, and the interest and state fields deduced from the processing rules. In this section, we describe and illustrate our model using four common middleboxes — firewall, NAT, layer-4 load balancer, and SSL-offload capable layer-7 load balancer. Table 1 describes the notations used.

Interfaces and Zones

Packets enter and exit a middlebox through one or more of its physical network interfaces. Each physical interface belongs to one or more logical network zones. A zone represents a packet entry and exit point from the perspective of middlebox func- tionality. A middlebox processes packets differently based on their ingress and egress zones. For example, the firewall shown in Fig. 1a has two physical interfaces, one belonging to the red zone that represents the insecure external network, and the other belonging to the green zone representing the secure internal network. Packets entering through the red zone are more stringently checked than those entering through the green zone. Similarly, the NAT in Fig. 1b has two different physical network interfaces, one belonging to the internal network (zone int) and the other belonging to the external network (zone ext). The source IP and port number are rewritten for packets received at zone int, whereas the destination IP and port number are rewritten for packets received at zone ext. Figure 1c shows a load balancer with a single physical network interface that belongs to two different zones — zone inet representing the

Logical AND operation

!

Logical NOT operation

sm

Source MAC (layer 2) address

dm

Destination MAC (layer 2) address

si

Source IP (layer 3) address

di

Destination IP (layer 3) address

sp

Source TCP/UDP (layer 4) port

dp

Destination TCP/UDP (layer 4) port

p

Packet

[

hd]

Packet with header h and payload d

5tpl

Packet 5-tuple: si, di, sp, dp, proto

X

rev

Swaps any source-destination IP, MAC, or port number pairs in X

 

Z( A, p )

true if packet p arrived at or departed zone A

I

( P, p )

Input precondition; true if packet p matches pattern P

C( p )

Condition specific to middlebox functionality

newflow?(p )

true if packet p indicates a new flow, e.g., TCP SYN

set( A, key val)

Stores the specified key-value pair in zone A ’s state database

S

: get?( A, key)

Returns true and assigns val to S if key val is present in zone A ’s state database

Table 1. Notations used in this article.

Internet and zone srvr representing the Web server farm. The load balancer spreads out packets received at zone inet to Web server instances in zone srvr. We assume that the mapping between interfaces and zones is pre-determined by the middlebox vendor or configured dur- ing middlebox initialization. Frames reaching an interface belonging to multiple zones are distinguished by their virtual local area network (VLAN) tags, IP addresses, and/or trans- port port numbers.

Input Preconditions

Input preconditions specify the types of packets that are accepted by a middlebox for processing. For example, a trans- parent firewall processes all packets received by it, whereas a load balancer in a single-legged configuration processes a packet arriving at its inet zone only if the packet is explicitly addressed to it at layers 2, 3, and 4. Similarly, a NAT process- es all packets received at its int zone, but requires those received at its ext zone to be addressed to it at layers 2 and 3. Input pre-conditions are represented using a clause of the form I (P, p), which is true if the headers and contents of pack- et p match the pattern P. For example, the firewall has the input precondition I (< * >, p), and the load balancer has I (< dm = MAC LB , di = IP LB , dp = 80 >, p) for its inet zone, where MAC LB and IP LB are the layer-2 and layer-3 addresses of the load balancer. Although I (< * >, p) is a tautology, we still explicitly specify it in the firewall model to enhance model clari- ty.

State Database

Most middleboxes maintain state associated with the flows and sessions they process. Our model represents state using key-value pairs stored in zone-independent or zone-specific state databases. Processing rules (described next) record the state using the set primitive and query state using the get? primitive. Accurately tracking state removal is hard, unless explicitly specified by the del primitive in a processing rule. Although state expiration timeouts can be specified as part of the set primitive, inaccuracies in timeout values or in their fine-

grained measurement can cause discrepancies between the model predicted behavior of a middlebox and its actual opera- tions. A middlebox behavior is predicted by the model. So the model predicted behavior of a middlebox may be better than its actual operations. As we illustrate in the next section, we use special processing rules to flag such possible discrepancies.

Processing Rules

Processing rules model the core functionality of a middlebox. A processing rule specifies the action taken by a middlebox when a particular condition becomes true. For example, the processing of an incoming packet is represented by a rule of the general form:

Z(A, p) I (P, p) C (p) Z (B, T (p)) state ops

The above rule indicates that a packet p reaching zone A of the middlebox is transformed to T(p) and emitted out through zone B, if it satisfies the input precondition I(P, p) and a mid- dlebox-specific condition C(p). In addition, the middlebox may update state associated with the TCP flow or application ses- sion to which the packet belongs. We now present concrete examples of processing rules for common middleboxes.

Firewall — First, consider a simple stateless layer-4 firewall that either drops a packet received on its red zone or relays it unmodified to the green zone. This behavior can be repre- sented using the following two rules:

Z(red, p) I(< * >, p) C

Z(red, p) I(< * >, p) C drop (p) DROP(p)

accept

(p) Z(green, p)

Since I(< * >, p) is a tautology, whether a packet is dropped or accepted by the firewall is solely determined by the C accept and C drop clauses that represent the filtering func- tionality of the firewall. Common filtering rules can be repre- sented easily using the appropriate Boolean expressions (e.g., C accept (p) : p.di = 80 || p.si = 128.34.45.6). For more com- plex filtering rules, we leverage external middlebox-specific

Web serve rs

Web serve rs (b) Red Green zone zone Insecure external network External zone External NAT network
Web serve rs (b) Red Green zone zone Insecure external network External zone External NAT network

(b)

Red

Green

zone

zone Insecure external network External zone External NAT network Internet zone
zone
Insecure
external
network
External
zone
External
NAT
network
Internet
zone

Internet

Sec ure intern al network
Sec ure
intern al
network

Internal

Int ernal network
Int ernal
network

zone

(a)

(c)

Server zone Switch
Server
zone
Switch

Figure 1. Zones of different middleboxes: a) firewall; b) NAT; and c) load balancer in single-legged configuration.

models like the Unified Firewall Model [2] to construct the appropriate C clauses. Rules for packets in the green red direction are similar.

NAT — Next, consider another very common middlebox — a NAT. Unlike the firewall in the previous example, a NAT rewrites packet headers and maintains per-flow state. We first describe the processing rules (rule box 1) for a full cone NAT and then, with minor modifications, change it to represent a symmetric NAT. Rule (i) describes how a full cone NAT processes a packet [hd] with a previously unseen [si, sp] pair received at its int zone. It allocates a new port number using a standard mecha- nism like random or sequential selection, or using a custom mechanism beyond the scope of our general model. It stores [si, sp] newport and newport [si, sp] in the state databases of zone int and zone ext, respectively. It rewrites the packet header h by applying the source NAT (SNAT fwd ) transformation function — the source medium access control (MAC) and IP addresses are replaced with the publicly visible addresses of the NAT, the source port with the newly allocated port number, and the destination MAC with the next hop IP gateway of the NAT. The packet with the rewritten header and unmodified payload is then emitted out through the ext zone. Rule (ii) specifies that the NAT emits a packet with a previously seen [si, sp] pair through zone ext, after applying SNAT fwd with the port number recorded in rule (i). Rule (iii) describes how the NAT processes a packet reaching the ext zone. It retrieves the newport [si, sp] state recorded in rule (i) using the destination port number of the packet, applies the reverse source NAT transformation function(SNAT rev ), and then emits the modified packet through zone int. Rule (iv) and Rule (v) flag discrepancies resulting from the inaccuracy of the model in tracking state expiration. The NAT may drop a packet arriving at its int or ext zone because the state associated with the packet expired without the knowledge of the model. Unlike a full cone NAT, a symmetric NAT allocates a sepa- rate port for each [si, sp, di, dp] tuple seen at its int zone, rather than for each [si, sp] pair. Thus, for a symmetric NAT, the zone int state set in rule (i) and retrieved in rules (ii) and

(iv), is keyed by [h.si, h.sp, h.di, h.dp] rather than by just [h.si, h.sp]. A symmetric NAT is also more restrictive than a full cone NAT. It relays a packet with header [IP s , IP NAT , PORT s , PORT d ] from the ext zone only if it had earlier received a packet destined to IP s : PORT s at the int zone and had rewritten its source port to PORT d . This restrictive behavior is captured by keying the zone ext state set in rule (i) and retrieved in rules (iii) and (v) with [h.di, h.dp, newport] rather than with just new- port. Other NAT types, like restricted cone and port restricted

cone, can be easily represented with similar minor modifications.

Layer-4 Load Balancer — Next, we present a layer-4 load bal- ancer, which unlike the NAT in the previous example, rewrites the destination IP address of a packet to that of an available Web server (rule box 2). Rule (i) describes how the load balancer processes the first packet of a new flow received at its inet zone. The load bal- ancer dynamically selects a Web server instance W i for the flow and records it in the state database of the inet zone. It rewrites the destination IP and MAC addresses of the packet to W i using the destination NAT (DNAT fwd ) transformation func- tion and then emits it out through the srvr zone. It also records this flow in the state database of the srvr zone, keyed by the five-tuple of the packet expected there in the reverse flow direction. Rule (ii) specifies that subsequent packets of the flow simply will be emitted out after rewriting the destination IP and MAC addresses to those of the recorded Web server instance. Rule (iii) describes how the load balancer processes a packet received from a Web server. It verifies the existence of flow state for the packet and then emits it out through the inet zone after applying the reverse DNAT transformation — that is, rewriting the source IP and MAC addresses to those of the load balancer and the destination MAC to the next hop IP gateway. Although the Web server instance selection mechanism is beyond the scope of our general model, the load balancer model easily can be augmented with primitives to represent common selection mechanisms like least loaded and round robin. In the previous example, we assumed that the load balancer was set as the default IP gateway at each Web server. Other load balancer deployment configurations (e.g., direct server return or source NAT) can be represented with minor modifications.

Layer-7 Load Balancer — We now present our most complex example, a layer-7 SSL offload-capable load balancer. This example illustrates how our model describes a middlebox whose processing spans both packet headers and contents and is not restricted to one-to-one packet transformations. The layer-7 load balancer is the end point of the TCP connection from a client (the CL connection). Because accurately model- ing TCP is very hard, we abstract it using a black box TCP

state machine tcp CL and buffer the data received from the client in a byte queue D CL . The I clauses are similar to those in the layer-4 load balancer and hence not repeated in rule box 3. Rule (i) specifies that the load balancer creates tcp CL and D CL and records them along with the packet header on receiv- ing the first packet of a new flow from a client at the inet zone. Rule (ii) specifies how the TCP state and data queue of the CL connection are updated as the packets of an existing flow arrive from the client. Rule (iii), triggered when tcp CL has data or acknowledgments to send, specifies that packets from the load balancer to the client will have header h

(with appropriate sequence numbers filled in by tcp CL ) and payload read from the D LS queue, if it was already created by the firing of rule (iv). Rule (iv), triggered when the data col- lected in D CL is sufficient to parse the HTTP request URL and/or cookies, specifies that the load balancer selects a Web server instance W i and opens a TCP connection to it, that is,

rev

CL

Z(int, [hd]) Z( e x t, [SNAT (h,n ewpor t)d]) fw d ∧ I (
Z(int, [hd])
Z( e x t, [SNAT
(h,n ewpor t)d])
fw d
∧ I ( <*>, [hd])
∧ se t(int, [h.s i, h .sp ] – n ewpo r t)
(i)
∧ I S :
∧ se t( e x t,n ewpo r t – [h .s i, h .sp ])
ge t? (int, [h .si, h .sp ])
SNAT
([sm , d m ,
= [ MA C NAT , MA C gw , I P NAT ,di,PORT,d p ]
fw d
s i, di, sp , d p ], PORT )
Z(int, [hd])
∧ S : ge t ? (int, [h.s i, h .sp])
Z( e x t, [hd])
I ( < di =
,
IP NAT
(iii) dm =MA C
> , [hd])
Z(int, [ SNAT r e v (h, S.si, S.sp)d])
NAT
∧ S : ge t? ( e x t, h . dp )
SNAT
([ sm , dm , s i, di, = [ M A C NAT , MA C I P , s i,I P, sp,PORT ]
r
e v
sp , d p ], I P, PORT )
Z(int, [hd])
DROP([hd])
(i v ) ∧ I ( <*>, [hd])
∧ WARN (in c o n s i s t e nt st a t e )
∧ S : ge t ? (int, [h.s i, h .sp ])
Z( e x t, [hd])
∧ WARN (in c o n s i s t e nt st a t e )
∧ S : ge t ? (e x t, h. d p)

(ii)

I ( <*>, [hd])

Z(e x t, [SNAT fw d (h, S )d])

I ( < di =I

( v ) dm =MA C

I ( < di = I ( v ) d m =M A C ∧ P

P NAT

NAT

,

> , [hd])

I ( < di = I ( v ) d m =M A C ∧ P

D ROP([hd])

Rule box 1.

creates tcp LS and D LS . It also installs a pointer to the state indexed by the DNATed header h LS in the state database of the srvr zone. Rule (v) shows how this state is retrieved, and its tcp LS and D LS are updated, on receipt of a packet from a Web server. Rule (vi) specifies the header and payload of packets sent by the load balancer to a Web server instance — h LS and data read from D CL . The rules listed above represent a plain layer-7 load bal- ancer. By replacing the + and read data queue operations with + ssl and read ssl operations that perform SSL encryption and decryption on the data, we can represent an SSL offload- capable load balancer without disturbing other rules. Similar to the TCP black box, we abstract out the details of the SSL protocol.

Auxiliary Traffic

In addition to its core functionality of transforming and for- warding packets, a middlebox can generate additional traffic, either independently or when triggered by a received packet. For example, a load balancer periodically checks the liveness of its target servers by making TCP connections to each serv- er. It also can send an Address Resolution Protocol (ARP) request for the layer-2 address of the Web server assigned to a received packet. Such packets generated by middleboxes and their responses, which support middlebox functionality, are referred to as auxiliary traffic in our model. Auxiliary traffic is represented using processing rules, as well. For example, the auxiliary traffic associated with the load balancer can be represented in rule box 4. The PROBE function returns a set of packets to check the liveness of server W i . In the simple case, these are just the TCP hand-shake packets with the appropriate sm, dm, si, di, sp, and dp.

Interest and State Fields

The interest fields of a middlebox identify the packet fields of interest, that is, the fields it reads or modifies. The state fields identify the subset of the interest fields used by the middlebox in storing and retrieving state. Although these fields can be deduced from the processing rules, they are explicitly present- ed in the model because they can highlight succinctly unex- pected aspects of middlebox processing.

Utility of a Middlebox Model

A middlebox model is useful only if it can easily represent many

real-world middleboxes and has practical applications. In this sec- tion, we first describe how we constructed the models described in the previous section and then discuss the applications of our model

in planning and troubleshooting existing middlebox deployments

and in guiding the development of new network architectures.

Model Instances

The models for the firewall, NAT, and layer-4 and layer-7 load balancers illustrated in the previous section were con- structed by analyzing generic middlebox descriptions and tax- onomies (like RFC 3234 [1]), consulting middlebox-specific manuals, and observing the working of the following real-

world middleboxes:

• Linux Netfilter/iptables software firewall

• Netgear home NAT

• BalanceNg layer-4 software load balancer

• HAProxy layer-7 load balancer Vmware appliance We prototyped a black box testing-based model-inference tool to aid middlebox model construction. The tool infers hints about the operations of a middlebox by carefully sending different kinds of packets on one zone and observing the packets emerging from other zones, as illustrated in Fig. 2. The following are some of the inferences generated by it:

• The firewall does not modify packets; all packets sent by the tool emerge unmodified or are dropped.

• The load balancers only process packets addressed to them at layers 2, 3, and 4.

• The layer-4 load balancer rewrites the destination IP and MAC addresses of packets in the inet srvr direction and the source addresses in the reverse direction. This infer- ence was made by pairing and analyzing packets with identical payloads seen at the two zones of the load balancer. By using a relaxed payload similarity metric, the header rewriting rules for even the layer-7 load balancer were partially inferred.

The layer-4 load balancer caches source MAC addresses of packets processed by it in the inet srvr direction and uses them in packets in the reverse direction. This inference was made by correlating rewritten packet header fields with values seen in earlier packets. Our inference tool is quite basic and serves only as an aid for model construction. It is not fully automated; for example,

it

requires the IP address and TCP port of the load balancer

as

input to avoid an exhaustive IP address search for packets

Z(inet, [hd]) ∧ Z( s rvr, [ DN AT fw d (h, W i )d])
Z(inet, [hd]) ∧
Z( s rvr, [ DN AT fw d (h, W i )d])
I ( < d m=MAC LB , di = IP LB ,
∧ s et(inet, h .5t p l – Wi)
(i)
dp=80> ,[hd])
∧ s et( s rvr,
∧ ne wflow? ([hd])
DN AT d (h, W i ) re v .5t p l
fw
– t r ue)
DN AT
([ s m , d m, s i, di,
fw d
s p , d p ], W )
= [ S M ,MAC W , s i,IP W , s p,d p ]
Z(inet, [hd]) ∧
I
( < d m=MAC , di =IP LB ,
LB
∧ ! newflow? ([hd])
∧ S : g et ? (inet, h .5t p l )
Z( s rvr, [hd]) ^
∧ S : g et ? ( s rvr, h .5 t p l )
DN AT r ev ([ s m ,dm ,s i,di,s p ,dp ])
= [ MAC LB , MAC g w , IP LB ,di, s p ,d p ]

(ii)

d p=80 >,[hd])

Z( s rvr,[DN AT fwd (h, S )d])

(iii)

( < s m=MAC i , s i =IP W i ,

I

s p=80 > ,[hd])

W

Z(in et, [ DN AT re v (h)d])

Rule box 2.

Z(inet, [hd]) set(inet, h . 5 t pl – ∧ ne wflow?([hd]) = Da t
Z(inet, [hd])
set(inet, h . 5 t pl –
∧ ne wflow?([hd])
= Da t a . ne w, h CL = h])
D CL
Z(inet, [hd])
∧ I (
)
∧ S . D CL + d
∧ S : g et ?(inet, h . 5 t p l )
Z(inet,
(iii)
S . t cp CL . r e ad y ?
S . t cp CL . s end( S. h r ev CL , S.D LS . r e a d))
S. h LS = D NAT fw d ( S. h CL , W i )
(iv ) S . D CL . ur l?
∧ s et(srvr, S . h r e v LS . 5 tp l – S)
∧ S . D LS = Da t a . ne w
Z( srvr, [hd])
∧ S . t cp LS = T CP. ne w
∧ S : g et ?( srvr, h . 5 tp l )
∧ S . D LS + d
(v i) S . t cp LS . re a d y ?
Z( srvr,
S . t cp LS . s end( S. h LS , S.D CL . re a d))

(i)

I (

)

[tcp CL = T C P. ne w,

(ii)

! ne wflow?([hd])

S. t cp CL . r e v (h)

( v ) I (

)

S . t cp LS . r ecv (h)

Rule box 3.

accepted by it. The inferred packet header transformation rules and state fields may not be 100 percent accurate and thus only serve to guide further analysis. For middleboxes like SSL offload boxes that completely transform packet payloads, the tool cannot infer the processing rules. We believe that completely inferring middlebox models through black box testing alone is impossible. If the source code for a middlebox implementation were available, we hypothesize that automatic white box software test-generation tools like directed automated random testing (DART) [5] can be adapted to infer middlebox model parameters. Automati- cally parsing middlebox configuration manuals to extract mod- els is another open research direction. We envision an online repository containing models of common middleboxes. We set up a pilot version of such a repository at http://www.middlebox.org with the models described in this article. We hope that middlebox manufactur- ers and network administrators who use middleboxes will con- tribute additional models to the repository. We also prototyped a model validation tool that analyzes traffic traces collected from the different zones of a middle- box and verifies whether its operations are consistent with its model downloaded from the repository. Apart from flagging errors and incompleteness in the models themselves, the vali- dation tool can be used to detect unexpected middlebox behavior, as we describe next.

Network Planning and Troubleshooting

The middlebox model clearly describes how various middle- boxes under different configurations interact with the network and with each other in a standard and concise format. This information aids in planning new middlebox deployments and in monitoring and troubleshooting existing ones. The input preconditions of a middlebox specify the types of packets expected by it and thus help a network architect plan the network topology and middlebox placement required to deliver the correct packets to it. The input preconditions and processing rules together help in analyzing the feasibility of placing different middleboxes in sequence. For example, because the right-hand sides of the firewall processing rules do not interfere with the conditions on the left-hand sides of the load balancer processing rules, the firewall can be placed in front of the load balancer with little scrutiny. However, placing the load balancer before the fire- wall requires more careful analysis as the destination address rewriting indicated by the processing rules of the load balancer may interfere with the C accept and C drop clauses of the firewall. The middlebox processing rules specify the packets flowing in

PERIODIC

Z( srvr, PROB E(IP W i ))

Z(inet,[hd]) S : g et? (inet, h.5 t pl ) ! S: g et? ( - ,IP S )

Z( srvr, A RPRE Q (IP S ))

Z( srvr, A RPRP LY (IP, MA C))

s et(- ,IP – MAC)

( - ,IP S ) Z( srvr , A RPRE Q (IP S )) Z( srvr

Rule box 4.

different parts of a network. This information can be used to stat-

ically analyze and detect problems with a middlebox deployment before actual network rollout. It also aids in troubleshooting exist-

ing middlebox deployments and enhances automated traffic moni-

toring and anomaly detection. For example, the model validation tool helped us detect unexpected NAT behavior in the home net-

work of one of the authors. The author’s home NAT was not rewriting the source port numbers of the packets sent by internal hosts. The tool automatically flagged this behavior as a violation of rules (i) and (ii) of our NAT model. We expected the multi- interface home NAT to use source port translation to support simultaneous TCP connections to the same destination from the same source port on multiple internal hosts. The failure of such simultaneous TCP connections on further investigation confirmed the anomaly. Although a small example, this experience indicates that our middlebox model holds practical utility in detecting unex- pected middlebox behavior.

Guide Networking Research

Our middlebox model provides networking researchers with clear and concise descriptions of how various middleboxes operate. Such information is very useful for researchers, as well as companies involved in developing new network archi- tectures, especially those that deal with middleboxes [6]. Not only does it provide hints to make a new architecture compat- ible with existing middleboxes, but it also helps identify mid- dleboxes that cannot be supported. In retrospect, the availability of a middlebox model would have benefited our research greatly on designing the policy- aware switching layer (PLayer) [4], alluded to earlier. The

PLayer consists of enhanced layer-2 switches (pswitches) that explicitly forward packets to the middleboxes specified by a net- work administrator. In our original (erroneous) design, pswitch- es rewrote the source MAC addresses of packets processed by

a transparent firewall to a unique dummy MAC address to

mark packets that had already been processed by the firewall. Contrary to our expectation of the load balancer to use ARP, it cached the dummy source MAC addresses of packets in the

forward flow direction and used them to address packets in the reverse direction. Such packets never reached their intended destinations. The presence of source MAC address in the inter- est and state fields of the load balancer would have helped us more quickly debug this problem. Moreover, it would have warned us against rewriting the source MAC address in our original design, thus avoiding a time-consuming redesign.

Limitations

The model presented in this article is only a first step toward modeling middleboxes. Its three main limitations are:

• The inability to describe highly-specific middlebox opera- tions in detail

• The lack of formal coverage proofs

• The complexity of model specification The goal of building a general middlebox model that can describe a wide variety of middleboxes precludes our model from representing functionality that is very specific to a partic- ular middlebox. We can extend our model easily using middle-

Internet Server zone zone Control Observe packet sending Model inference tool
Internet
Server
zone
zone
Control
Observe
packet
sending
Model inference tool

Figure 2. Middlebox model inference tool analyzing a load balancer.

box-specific models like the Unified Firewall Model as described earlier, although at the expense of reducing model simplicity and conciseness. The desire for simplicity and con- ciseness also limits our model from capturing accurate timing and causality between triggering of different processing rules. On the other hand, our model may not be general enough to describe all possible current and future middleboxes. Although we represented many common middleboxes in our model and are not aware of any existing middleboxes that cannot be represented, we are unable to formally prove that our model covers all possible middleboxes. The model for a particular middlebox consists of a small number (typically < 10) of processing rules. However, con- structing the model itself is a non-trivial task even with support from our model inference and validation tools. We expect models to be constructed by experts and shared through an online model repository, thus making them easily available to all, without requiring widespread model construction skills.

Related Work

The middlebox model described in this article is placed at an inter- mediate level in between related work on very general network communications models and very specific middlebox models. An axiomatic basis for communication [7] presents a general network communications model that axiomatically formulates packet forwarding, naming, and addressing. This article presents

a model tailored to represent middlebox functionality and oper-

ations. The processing rules and state database in our model are similar to the forwarding primitives and local switching table in [7]. As part of future work, we plan to investigate the integra- tion of the two models and thus combine the practical benefits

of our middlebox model (e.g., middlebox model inference and validation tools, model repository) and the theoretical benefits of the general communications model (e.g., formal validation of packet forwarding correctness through chains of middleboxes). Predicate routing [8] attempts to unify security and routing by declaratively specifying network state as a set of Boolean expressions dictating the packets that can appear on various links connecting together end nodes and routers. This approach can be extended to represent a subset of our mid- dlebox model. For example, Boolean expressions on the ports and links (as defined by predicate routing) of a middlebox can specify the input preconditions of our model and indirectly hint at the processing rules and transformation functions. From a different perspective, middlebox models from our repository can aid the definition of the Boolean expressions in

a network implementing predicate routing. Reference [9] uses statistical rule mining to automatically group together commonly occurring flows and learn the under- lying communication rules in a network. Our work has a nar-

rower and more detailed focus on how middle- boxes operate. Reference [10] uses detailed mea- surement techniques to evaluate the performance and reliability of production middlebox deploy- ments. We plan to investigate how the techniques described in these papers can enhance our model inference and validation tools. RFC 3234 [1] presents a taxonomy of middle- boxes. Our model goes well beyond a taxonomy and describes middlebox packet processing in more detail using a concise and standard lan- guage. In addition, our model can naturally induce a more fine-grained taxonomy on middleboxes (e.g., “middleboxes that rewrite the destination IP and port number” versus “middleboxes operating at the transport layer”). Our model does not cur- rently consider the middlebox failover modes and functional ver- sus optimizing roles identified by RFC 3234. The Unified Firewall Model [2] and IETF BEHAVE [3] working group characterize the functionality and behavior of specific middleboxes — firewalls and NATs in this case. Guid- ed by these efforts, we construct a general model that applies to a wide range of middleboxes and enables us to compare different middleboxes and study their interactions. Further- more, these specific models can be plugged into our general model and alleviate the limitations of model generality.

Conclusion

In this article, we presented a simple middlebox model and illustrated how various commonly used middleboxes can be described by it. The model guides middlebox-related research and aids middlebox deployments. Our work is only an initial step in this direction and calls for the support of the middle- box research and user communities to further refine the model and to contribute model instances for the many differ- ent kinds of middleboxes that exist today.

References

[1] “Middleboxes: Taxonomy and Issues,” RFC 3234. [2] G. J. Nalepa, “A Unified Firewall Model for Web Security,” Advances in Intelligent Web Mastering. [3] “Behavior Engineering for Hindrance Avoidance”; http://www.ietf.org/ html.charters/behave-charter.html [4] D. Joseph, A. Tavakoli, and I. Stoica, “A Policy-Aware Switching Layer for Data Centers,” Proc. SIGCOMM, 2008. [5] P. Godefroid, N. Klarlund, and K. Sen, “DART: Directed Automated Random Testing,” Proc. PLDI, 2005. [6] M. Walfish et al., “Middleboxes No Longer Considered Harmful,” Proc. OSDI, 2004. [7] M. Karsten et al., “An Axiomatic Basis for Communication,” Proc. SIG- COMM ’07. [8] T. Roscoe et al., “Predicate Routing: Enabling Controlled Networking,” SIG- COMM Comp. Commun. Rev., vol. 33, no. 1, 2003. [9] S. Kandula, R. Chandra, and D. Katabi, “What’s Going On? Learning Com- munication Rules in Edge Networks,” Proc. SIGCOMM, 2008. [10] M. Allman, “On the Performance of Middleboxes,” Proc. IMC, 2003.

Biographies

DILIP JOSEPH (dilip@cs.berkeley.edu) received his B.Tech. degree in computer science from the Indian Institute of Technology, Madras, in 2004 and his M.S. degree in computer science from the University of California at Berkeley in 2006. He is current- ly a Ph.D. candidate at the University of California at Berkeley. His research interests include data center networking, middleboxes, and new Internet architectures.

STOICA (istoica@cs.berkeley.edu) received his Ph.D. from Carnegie Mellon

University in 2000. He is an associate professor in the EECS Department at the University of California at Berkeley, where he does research on peer-to-peer net- work technologies in the Internet, resource management, and network architec- tures. He is the recipient of the 2007 Rising Star Award, a Sloan Foundation Fellowship (2003), a Presidential Early Career Award for Scientists and Engi- neers (PECASE) (2002), and the ACM doctoral dissertation award (2001). In 2006 he co-founded Conviva, a startup company to commercialize peer-to-peer technology for video distribution.

ION

Network Address Translation for the Stream Control Transmission Protocol Michael Tüxen and Irene Rüngeler, Münster
Network Address Translation for the Stream Control Transmission Protocol Michael Tüxen and Irene Rüngeler, Münster
Network Address Translation for the Stream Control Transmission Protocol Michael Tüxen and Irene Rüngeler, Münster

Network Address Translation for the Stream Control Transmission Protocol

Michael Tüxen and Irene Rüngeler, Münster University of Applied Sciences Randall Stewart, The Resource Group Erwin P. Rathgeb, University of Duisburg-Essen

Abstract

Network address translation is widely deployed in the Internet and supports the Transmission Control Protocol and the User Datagram Protocol as transport layer protocols. Although part of the kernels of all recent Linux distributions, namely, the FreeBSD 7 and the Solaris 10 operating systems, the new Internet Engineering Task Force transport protocol — Stream Control Transmission Protocol — is not supported on most NAT middleboxes yet. This article discusses the deficiencies of using existing NAT methods for SCTP and describes a new SCTP-specific NAT con- cept. This concept is analyzed in detail for several important network scenarios, including peer-to-peer, transport layer mobility, and multihoming.

NN etwork address translation (NAT) is a common method for separating private networks from global networks by translating private Internet Protocol (IP) addresses to global IP addresses.

Often there is only one global IP address available for multi- ple hosts inside the private network. In this case, the transport

layer port number also is modified, and the method is called network address and port number translation (NAPT). NAT and NAPT have been in use for the Transmission Control Protocol (TCP) and the User Datagram Protocol (UDP) for a long time, but the Stream Control Transmission Protocol (SCTP), as a fairly new transport protocol is not supported yet. Applying this method also to SCTP does not work for multihomed associations. Currently, NAT implementations that support SCTP in a way similar to TCP or UDP are being developed first. Although this works well for single-homed SCTP associations, it does not work for multihomed SCTP associations. This makes these solutions non-applicable for typical SCTP appli- cations that require multihoming. However, in these cases, some vendors and operators also want to use NAT middle- boxes for various reasons. Therefore, it is important to have NAT middleboxes that not only support SCTP in a limited way, but with all features, especially multihoming. In [1] and [2], the authors of this article describe an approach to integrate SCTP in network address translators for single-homed client-server communication. This article extends this method in a way that also works in the case of multihomed and peer-to-peer scenarios. Additionally, it covers the case of transport layer mobility or routing changes in the network. These additions also will be provided to the Internet Engineering Task Force (IETF) for standardization. The structure of this article is as follows: first, we provide an introduction to SCTP, emphasizing the features that are relevant for this article. We discuss generic NAT and NAPT methods for traffic based on TCP or UDP and for traffic that

is not based on these protocols. Their applicability for SCTP is analyzed. An SCTP-specific method for NAT middleboxes that overcomes the deficiencies of the generic methods is described. Several examples are given explaining in detail how the SCTP-specific NAT method works for different scenarios including single-homed and multihomed client-server scenar- ios, peer-to-peer scenarios, and transport-layer mobility sce- narios. Then, conclusions are presented.

Introduction to the Stream Control Transmission Protocol

SCTP is currently specified in [5]. It was standardized by the IETF as the generic transport protocol for signaling transport in IP-based telephone signaling networks. SCTP is a connection-oriented protocol providing reliable transport of user messages. It supports IPv4 and IPv6 as a net- work layer. A connection between two SCTP end points is called an SCTP association or just an association. One of the major design goals was network fault tolerance, and therefore, each SCTP end point can use multiple IP- addresses within each association but only one port number. Each IP address of the peer can be used as the destination address of a packet. Currently, this multihoming support is used only for redundancy, but ongoing research is analyzing the possibility of also using it for load sharing. SCTP is already part of all recent Linux distributions — the Solaris 10 operating system and the FreeBSD 7.0 release. It is deployed to signal networks of telephony network operators and is used in IP-based signaling for universal mobile telecom- munication system (UMTS) networks. Other applications using SCTP include the IP Flow Information Export (IPFIX) protocol, Diameter, and the Reliable Server Pooling (RSer- Pool) protocol suite. It should be noted that SCTP was the first transport protocol specified by the IETF in 2000 and

COOKIE-ECHO

COOKIE-ECHO

COOKIE-ACK

COOKIE-ACK

INIT

Host A Host B INIT INIT-ACK
Host A
Host B
INIT
INIT-ACK
COOKIE-ACK COOKIE-ACK INIT Host A Host B INIT INIT-ACK INIT Host A Host B INIT-ACK Host
COOKIE-ACK COOKIE-ACK INIT Host A Host B INIT INIT-ACK INIT Host A Host B INIT-ACK Host
INIT Host A Host B INIT-ACK
INIT
Host A
Host B
INIT-ACK
A Host B INIT INIT-ACK INIT Host A Host B INIT-ACK Host A Host B INIT
A Host B INIT INIT-ACK INIT Host A Host B INIT-ACK Host A Host B INIT
A Host B INIT INIT-ACK INIT Host A Host B INIT-ACK Host A Host B INIT

Host A

Host B

INIT INIT-ACK
INIT
INIT-ACK
COOKIE-ECHO INIT-ACK INIT COOKIE-ACK
COOKIE-ECHO
INIT-ACK
INIT
COOKIE-ACK

Figure 1. Examples of the SCTP association setup.

deployed in commercial networks after the introduction of UDP and TCP in the 1980s. Four years later, a modification of UDP with limited checksum coverage — UDP-Lite — was standardized and is used in Third Generation Partnership Project (3GPP) networks. In 2006, the IETF standardized the Datagram Congestion Control Protocol (DCCP). Currently, neither UDP-Lite nor DCCP are available on major operating systems. An SCTP packet consists of a common header followed by

a number of chunks. The common header contains source and

destination port numbers similar to TCP or UDP headers, a 32-bit verification tag and a CRC32C checksum. The check- sum covers only the SCTP packet and does not take any kind of pseudo header into account. Each chunk consists of a type field, eight flags, a length field, and type-specific data. Fur- thermore, it is padded at the end to be 32-bit aligned. The basic association setup procedure is based on a four- way handshake and follows the client-server principle. It is shown on the left-hand side of Fig. 1. The first SCTP mes- sage is sent from the client to the server. It contains exactly one chunk, the initiation (INIT) chunk. The INIT chunk con- tains a 32-bit random number, the initiate tag, and the list of

IP-addresses used by the client. The server responds with an SCTP message, which also contains just one chunk, the initia- tion acknowledge (INIT-ACK) chunk. It also contains a 32- bit random initiate tag and the list of addresses of the server. If the client or server is single-homed, the list of addresses in the INIT or INIT-ACK chunk should be empty. After the server has sent the INIT-ACK chunk, it does not hold any state regarding the association. Instead, it puts all informa- tion in a state cookie, which itself is put into the INIT-ACK chunk. On reception of the INIT-ACK chunk, the client sends the state cookie in a COOKIE-ECHO chunk to the server. On reception of the COOKIE-ECHO chunk, the serv- er responds with a COOKIE-ACK chunk, and the association is established. Other chunks might be bundled with the COOKIE-ECHO or COOKIE-ACK chunk in the third and fourth message. The verification tag in the common header is always the initiate tag sent by the peer in the INIT or INIT-ACK mes- sage during the association setup. This is used to protect asso- ciations against blind attacks. Only the common header of the packet containing the INIT chunk has the verification tag 0. It

is important to note that most SCTP implementations use the

verification tag for looking up the association when a packet is received. Some implementations even ensure that the verifica-

tion tags are unique across all associations currently known. SCTP supports not only the client-server model for associa- tion setup, but also the more general peer-to-peer model.

Both end points can start the four-way hand- shake at about the same time, and the SCTP setup procedure ensures that exactly one association is established. This is called a collision case. An example message flow is shown on the right-hand side in Fig. 1. It is also possible that one side starts the association procedure while the peer is still in the established state. This might happen, for example, if one side reboots without tear- ing down the association and then starts the association setup procedure. The four-way handshake succeeds, and for the server side, the association restarts. One example is

shown in the middle of Fig. 1; detailed descriptions of the handling of all the possi- ble cases is given in [9]. If an SCTP end point must terminate an association immediately, it can send a packet containing an ABORT chunk. This chunk also is sent in response to almost all packets for which no association can be looked up. On reception of an ABORT chunk, the association is terminated. Error conditions can be signaled by sending an ERROR chunk. ABORT and ERROR chunks can include the causes of the error in order to provide more detailed information. In addition to the base protocol, several exten- sions also were standardized and implemented. The SCTP extension that is crucial for this article is the ability to add or delete IP addresses dynamically during the lifetime of an SCTP association. This is specified in [6]. If an SCTP end point wants to add or delete an IP-address, it sends an address configuration change (ASCONF) chunk that con- tains the address to be added or deleted and an address that can be used to look up the association, the so-called lookup address. When the peer has processed an ASCONF chunk, it sends back an address configuration acknowledgment (ASCONF-ACK) chunk. There is a special rule that if the address to be added is the wildcard address (0.0.0.0 for IPv4 or ::0 for IPv6), the source address of the packet containing the ASCONF chunk is added. If the address to be deleted is the wildcard address, all addresses except for the source address of the packet containing the ASCONF chunk are deleted.

Applicability of Generic Methods for NAT or NAT Traversal

UDP or TCP-like Network Address and Port Number Translation

NAT in its original meaning is realized by changing the (pri- vate) IP address of the client to a global address of the NAT middlebox and keeping this correlation in a table (Fig. 2). Thus, the server addresses its packets to this global address, reaches the NAT, which substitutes the destination address with the address of the client. This is a feasible method, as long as the source ports of the clients connecting to the same server are different. The source port numbers are chosen dynamically from operating system dependent ranges. Some operating systems use the port numbers between 49152 and 65535. Because many clients can be located behind the same NAT middlebox, and these clients might access a very popular server at about the same time, the chance that two clients get the same port is non-negligible. Therefore, TCP or UDP sessions usually are translated by changing the private IP address and additionally, the private

10.1.0.1:52001 120.10.2.1 10.1.0.2:52002 10.1.0.3:52003
10.1.0.1:52001
120.10.2.1
10.1.0.2:52002
10.1.0.3:52003

100.4.5.1:8080

Internet
Internet

120.10.2.1:52001 => 100.4.5.1:8080 120.10.2.1:52002 => 100.4.5.1:8080 120.10.2.1:52003 => 100.4.5.1:8080

Figure 2. Using basic NAT.

port number to a global IP address and port number in the TCP or UDP header, respectively. This method is called NAPT. Thereby, the NAT middlebox chooses the port num- bers from a pool and makes sure that no two connections to the same server obtain the same port numbers. As the transport layer checksum of the TCP and UDP packets covers the transport header that includes the port numbers, it must be modified according to the port number change. However, the checksum used for TCP or UDP has the property that the change of the checksum can be comput- ed only from the change of the port numbers. So this can be done very efficiently by a simple set of additions and subtrac- tions. It should be noted that the behavior of NAT middleboxes varies dramatically because there were no standards describ- ing how to build them. The Behavior Engineering for Hin- drance Avoidance (BEHAVE) working group of the IETF develops best current practice (BCP) documents giving requirements for NAT middlebox behavior and protocols to help applications to run over networks with NAT middlebox- es.

Considering only single-homed SCTP clients and servers, it is also possible to use this NAPT concept for SCTP because it has the same port number concept as TCP and UDP. Howev- er, the transport layer checksum used by SCTP is different from the one used by UDP and TCP. This checksum does not allow the computing of the checksum change based only on the port number change. Therefore, the NAT middlebox must compute the new SCTP checksum again, based on the com- plete SCTP packet. This requires a substantial amount of computing power that might be reduced when the computa- tion is performed directly by hardware. For multihomed SCTP clients and servers, reusing the techniques from TCP and UDP becomes much harder. As we mentioned earlier, hosts can be multihomed, which means that they can simultaneously use multiple network addresses and thus can be attached to multiple networks. Therefore, the traffic of one SCTP association, in general, passes through different NAT middleboxes on different paths. Because each SCTP end point can use only one SCTP port number on all paths, the NAT middleboxes cannot change the port number independently. To apply the existing NAT concept, the NAT middleboxes involved would have to synchronize the port numbers to assign a common number for the association. This is very hard to achieve. Based on this discussion, it seems desirable to use a NAT mechanism for SCTP that does not require a change to the SCTP header at all and hence to the port numbers, which avoids synchronization among NAT middleboxes and the recomputation of the SCTP checksum.

UDP-Based Tunneling

Currently, most NAT middleboxes support only protocols running on top of TCP or UDP. A stan- dard technique for all other protocols is to encap- sulate these packets into UDP instead of IP. Because both UDP and IP provide an unreliable packet delivery service, this is feasible. This also works for SCTP, as described in [3], and is cur- rently implemented in the SCTP kernel extension for Mac OS X. It should be noted that NAT middleboxes on different paths are not synchronized, and there- fore, the UDP port number might be different on

different paths. One drawback of using UDP encapsulation is that Internet Control Message Protocol (ICMP) messages might not contain enough information to be pro- cessed by the SCTP layer. Another drawback is that the sim- ple peer-to-peer solution described in the sections about peer-to-peer communication and multihoming with a ren- dezvous server does not work because the UDP port numbers might be changed by NAT-middleboxes. Tunneling SCTP over UDP must handle the same prob- lems as any other UDP-based communication for NAT traver- sal. However, this is the only possibility for SCTP-based communication through a NAT middlebox without modifying it to add SCTP support.

An SCTP-Specific Variant of NAT

In the NAPT method described previously, the NAT middle- box controls the 16-bit source port number of outgoing TCP connections to distinguish multiple TCP connections of all clients behind the NAT middlebox to the same server. The basic idea for the SCTP-specific method is instead to use the combination of the source port number and the verification tag. For single-homed hosts, this method is described in [2]. If NAT middleboxes use the verification tags together with the addresses and the port numbers to identify an association, the probability that two hosts end up with the same combina- tion decreases to a tolerable level.

A Simple Association Setup

The main task of a NAT middlebox is to substitute the source address of each packet with the public address used by the NAT middlebox and to keep the corresponding IP addresses in a table. First, we consider an association setup between a single-homed client and a single-homed server. Neither the INIT nor the INIT-ACK chunk contain any IP addresses. This leads to a scheme as described in Fig. 3. In the first message of the handshake, the verification tag in the common header must be set to 0, but the initiate tag (initTag) in the INIT chunk holds a 32-bit random number that is supposed to be the verification tag (VTag) of the incoming packets. Hence, at the beginning of the handshake, only one verification tag is known. The NAT middlebox keeps track of this information and takes the local private address (Local-Address) and the officially registered destination IP address (Global-Address) from the IP header of the SCTP packet and saves them in the NAT table (Fig. 3). The local source port (Local-Port) and the destination port (Global- Port) are obtained the same way. The initiate tag of the INIT chunk, which the client has chosen for its communication, is also extracted from the INIT chunk header and saved as Local-VTag. The Global-VTag that eventually will be chosen by the communication partner is not known yet. Before forwarding the packet, the NAT mid-

NAT

120.10.2.1

Server

100.4.5.1:8080

10.1.0.1:52001

NAT 120.10.2.1 Server 100.4.5.1:8080 10.1.0.1:52001 INIT: 10.1.0.1:52001=>100.4.5.1:8080 Vtag=0, initTag=12345

INIT: 10.1.0.1:52001=>100.4.5.1:8080 Vtag=0, initTag=12345

10.1.0.1:52001=>100.4.5.1:8080 Vtag=0, initTag=12345 INIT-ACK: 100.4.5.1:8080=>10.1.0.1:52001 Vtag=12345,

INIT-ACK: 100.4.5.1:8080=>10.1.0.1:52001 Vtag=12345, initTag=45678

INIT: 120.10.2.1:52001=>100.4.5.1:8080 Vtag=0, initTag=12345

INIT: 120.10.2.1:52001=>100.4.5.1:8080 Vtag=0, initTag=12345
120.10.2.1:52001=>100.4.5.1:8080 Vtag=0, initTag=12345 INIT-ACK: 100.4.5.1:8080=>120.10.2.1:52001 Vtag=12345,
120.10.2.1:52001=>100.4.5.1:8080 Vtag=0, initTag=12345 INIT-ACK: 100.4.5.1:8080=>120.10.2.1:52001 Vtag=12345,

INIT-ACK: 100.4.5.1:8080=>120.10.2.1:52001 Vtag=12345, initTag=45678

Chunk type

Local-Address

Global-Address

Local-Port

Global-Port

Local-VTag

Global-VTag

INIT

10.1.0.1

100.4.5.1

52001

8080

12345

-

INIT-ACK

10.1.0.1

100.4.5.1

52001

8080

12345

45678

COOKIE-ECHO: 10.1.0.1:52001=>

COOKIE-ECHO: 120.10.2.1:52001=>

100.4.5.1:8080

100.4.5.1:8080

Vtag=45678

Vtag=45678

100.4.5.1:8080 Vtag=45678 Vtag=45678 COOKIE-ACK: 100.4.5.1:8080=> COOKIE-ACK:
100.4.5.1:8080 Vtag=45678 Vtag=45678 COOKIE-ACK: 100.4.5.1:8080=> COOKIE-ACK:

COOKIE-ACK: 100.4.5.1:8080=>

COOKIE-ACK: 100.4.5.1:8080=>

10.1.0.1:52001

120.10.2.1:52001

Vtag=12345

Vtag=12345

100.4.5.1:8080=> COOKIE-ACK: 100.4.5.1:8080=> 10.1.0.1:52001 120.10.2.1:52001 Vtag=12345 Vtag=12345

Figure 3. Four-way handshake for the SCTP association setup with NAT table.

dlebox exchanges the source address of the IP header with the NAT address (Nat-Global-Address) and sends the packet toward the other end point. The other SCTP end point receiving the packet containing the INIT chunk answers the request with a message contain- ing the INIT-ACK chunk. This message is addressed to the NAT-Global-Address and the Local-Port. Its verification tag in the common header must be identical to the initiate tag of the INIT chunk, whereas the initiate tag of the INIT-ACK chunk will be used as the verification tag for all packets that are sent by the initiating end point (client 10.1.0.1 in the fig- ure) of the association. For an incoming INIT-ACK chunk, the NAT middlebox searches the table entries for the corre- sponding combination of Local-Port, Global-Address, Global- Port, and the Local-VTag and adds the Global-VTag. Thus, after the reception of the INIT-ACK chunk, both verification tags are known. Now the NAT middlebox sets the destination address to the Local-Address found in the table entry and delivers the packet. To complete the handshake, a packet with a COOKIE-ECHO chunk is sent that is acknowledged with a message containing a COOKIE-ACK chunk.

NAT Table

The NAT table consists of several entries. Each entry is a tuple consisting of:

1) Local-Address 2) Global-Address 3) Local-Port 4) Global-Port 5) Local-VTag 6) Global-VTag In addition to the procedure to modify the table given in the next subsection, a timer must be used to remove entries that have not been used for a certain amount of time. This time should be long enough such that the SCTP path supervision procedure prevents the table entries from timing out.

Modifications to the NAT Table

The basic procedure for handling INIT and INIT-ACK chunks was described previously. If the INIT or INIT-ACK chunk contains a list of addresses, then for each address in the list, an entry is added to the table. If an ASCONF chunk is received to add the wildcard

address, an entry to the NAT table is made for that address. Because both verification tags must be added, a parameter must be included in the ASCONF chunk that contains the verification tag that is not present in the common header.

Behavior of the SCTP End Points

Because multiple clients behind the NAT middlebox might choose the same local port when connecting to the same serv- er, the restart procedure would result in a loss of an SCTP association. Therefore, the INIT chunk sent by the clients should contain a parameter indicating that the server should not follow the restart procedure. Instead it should use the ver- ification tag to distinguish between the associations. This is what most SCTP implementations already do. Furthermore, the SCTP end points must not include non- global addresses in the INIT or INIT-ACK chunk. If an SCTP end point is multihomed and has non-global addresses, it should set up the association single-homed and then add the other addresses after the association has been established by sending an SCTP packet containing an ASCONF chunk for each address. To add such an address, the ASCONF should contain only the wildcard address and the parameter providing the required verification tag. The source address of the packet containing the ASCONF chunk will be added to the association. To remove an address, an ASCONF chunk is sent with the wildcard address. Then, all addresses except the source address of the packet containing the ASCONF chunk are deleted from the association.

Communication between the NAT Middleboxes and the SCTP End Points

If a NAT middlebox receives an INIT chunk that would result in adding an entry to the NAT table that conflicts with an already existing entry, it should not insert this entry and may send an ABORT chunk back to the SCTP end point. In the ABORT chunk, an M-bit should be set that indicates that it has been generated by a middlebox. This happens if two dif- ferent clients choose the same local port number and initiate tag and try to connect to the same server. On reception of such an ABORT chunk, the end point can try to choose a dif- ferent initiate tag and try setting up the association again.

Server 100.4.5.1:8080 100.5.5.1:8080 Client Router 1 10.1.0.1:52001 NAT Internet Router 2 Chunk type
Server 100.4.5.1:8080 100.5.5.1:8080 Client Router 1 10.1.0.1:52001 NAT Internet Router 2 Chunk type
Server
100.4.5.1:8080
100.5.5.1:8080
Client
Router 1
10.1.0.1:52001
NAT
Internet
Router 2
Chunk type
Local-Address
Global-Address
Local-Port
Global-Port
Local-VTag
Global-VTag
INIT+INIT-ACK
10.1.0.1
100.4.5.1
52001
8080
12345
45678
INIT-ACK
10.1.0.1
100.5.5.1
52001
8080
12345
45678
■ Figure 4. Building the NAT table for the single-homed client with a multihomed server.

If the NAT middlebox receives an SCTP packet that cannot be processed because there is no entry in the NAT table, the NAT middlebox should discard the packet and can send back an ERROR chunk. An M-bit must be set to indicate that the chunk is generated by a middlebox, and an error cause should indicate that the NAT middlebox does not have the required information to process the packet. On reception of such an ERROR chunk, the end point should use an ASCONF chunk to provide the required information to the NAT middlebox.

New SCTP Protocol Elements

Clients require a new parameter to be included in the INIT chunk to indicate that they will use the procedures described in this article. This parameter also is included in the INIT- ACK chunk to indicate that the receiver also supports it. Another new parameter is required that can contain a verifi- cation tag and is included in an ASCONF chunk.

Both the ERROR chunk and the ABORT chunk must have an M-bit indicating that the packet containing the chunk is generated by a middlebox instead of the peer. Two additional error causes are introduced, one to be included in the ERROR chunk to indicate that the NAT mid- dlebox misses some state, and one to be included in the ABORT chunk to indicate a conflict in the NAT table.

Examples

This section provides a detailed discussion of several network scenarios involving NAT middleboxes. The proposed NAT mechanisms were verified in all these scenarios using an SCTP simulation in the INET framework for the OMNeT++ simulation kernel described in [10]. Furthermore, a group of the Center for Advanced Internet Architecture at Swinburne University is implementing this method for the FreeBSD operating system. This project,

this method for the FreeBSD operating system. This project, Server 100.4.5.1:8080 Client Router 10.1.0.1:52001 NAT
Server 100.4.5.1:8080 Client Router 10.1.0.1:52001 NAT Internet new NAT Packets arriving at the server 120.10.2.1
Server
100.4.5.1:8080
Client
Router
10.1.0.1:52001
NAT
Internet
new NAT
Packets arriving at the server
120.10.2.1
120.10.2.1:52001=>100.4.5.1:8080
140.1.1.1:52001=>100.4.5.1:8080
140.1.1.1
10.1.0.1=>100.4.5.1
DATA: 120.10.2.1:52001=>100.4.5.1:8080
100.4.5.1=>10.1.0.1
ERROR: 100.4.5.1:8080=>120.10.2.1:52001
Cause: NAT state missing
10.1.0.1=>100.4.5.1
ASCONF: 120.10.2.1:52001=>100.4.5.1:8080
Vtag: 12345
140.1.1.1=>100.4.5.1
ASCONF-ACK:
100.4.5.1=>10.1.0.1
100.4.5.1:8080=>120.10.2.1:52001
100.4.5.1=>140.1.1.1
■ Figure 5. After a route change a new NAT middlebox appears.
Rendezvous server 100.1.3.1 Peer 3 Peer 1 Router 100.1.3.254 10.1.3.1 10.1.1.1 NAT 2 100.1.1.254 100.1.1.253
Rendezvous server
100.1.3.1
Peer 3
Peer 1
Router
100.1.3.254
10.1.3.1
10.1.1.1
NAT 2
100.1.1.254 100.1.1.253
100.1.2.253
100.1.2.254
NAT 1
10.1.2.1
10.1.4.1
Peer 2
Peer 4

Figure 6. Peer-to-peer communication with rendezvous server.

SCTP over NAT Adaptation (SONATA), is being implement- ed in cooperation with two of the authors and is based on [2].

Single-Homed Client to Multihomed Server

In the case of a single-homed client and a multihomed server, the server announces all its global addresses in address parameters included in the INIT-ACK chunk (Fig. 4). The packet crosses the NAT middlebox, which updates its entries for the association. When the client receives the chunk, it adds those addresses to its list of destination addresses. As a result, there will be a separate entry for each server address although there is only one association.

Adding New NAT Middleboxes

After setting up an association, data can be exchanged between client and server. The packets are routed through the Internet. It must be emphasized that the routes are not stable and can change during the lifetime of an association, in partic- ular if the association has a long life span as expected for major SCTP application scenarios. Therefore, a new NAT middlebox could become involved that has no knowledge of the properties of the association as shown in Fig. 5. Passing through a new NAT middlebox also means that the server receives a packet with a new source address, which appears as if the client has an additional IP address. In Fig. 5 the upper route shows the path where the associa- tion was set up initially. After the route was changed, the packets travel on the lower route. An example for the address/port combination for both routes is shown below the server. If the new NAT middlebox receives the first packet from the client, it sends back a packet containing an ERROR chunk indicating that it lacks the required NAT table entry. Therefore, upon receipt of the ERROR chunk, the client sends an ASCONF chunk on the new path with the required information. The new NAT middlebox can add a complete entry to its table upon receipt of this message. This message can pass through the NAT middlebox and can be acknowledged by the server with an ASCONF-ACK mes- sage. Afterward the communication can proceed as usual.

Client Using Transport Layer Mobility

SCTP with its functionality of dynamic address configuration is well suited to be employed in an environment with host mobility. Whereas all other parameters remain the same, the moving client will receive a new address. This not only results in a new source address for the packet but also in a changing route, such that eventually another NAT middlebox must be traversed, which again, initially has no knowledge of the asso- ciation. As the situation is similar to the one described in the last subsection, we suggest that the same actions are taken.

For more information on transport layer mobili-

ty, see [7].

Peer-to-Peer Communication

A greater challenge is the communication

between two peers, that is, two hosts that both use private IP addresses (peer-to-peer communi- cation). A detailed description for UDP and TCP is given in [8]. The two peers require an agent to help them find their communication partner. This agent usually is called a rendezvous server.

In Fig. 6 the corresponding network setup is shown. The communication process in this case consists of two phases. First, associations are ini- tialized between the peers and the rendezvous server; after retrieving the required information from the ren- dezvous server, the peers can communicate with each other independently of the server. After both peers retrieve the required information, the actual communication between the peers can start. As there is no server, both hosts must be able to act as client and server. Thus, both start an association. If the message containing the INIT chunk of Peer 1 reaches the NAT middlebox, NAT 2, before the message of Peer 2 could arrive, it will be discarded. The retransmission of the INIT chunk will arrive if in the meantime, Peer 2 has punched a hole by triggering the NAT middlebox to set up a table entry. The best results can be achieved if the associations are started at the same time. From the perspective of SCTP, the simulta- neous sending of INIT chunks also is not a normal situation because the INIT chunk is not followed directly by an INIT- ACK chunk but by another INIT chunk. The SCTP collision handling procedure ensures that exactly one association between the peers is established.

Multihomed Client and Server

The client sends an INIT chunk without a list of addresses to the server, which responds with an INIT-ACK chunk includ- ing a list of all addresses of the server. As shown in Fig. 7, this initial handshake uses the path via NAT 1. After the association is established, the client adds its sec- ond address by sending an ASCONF chunk. If the packet containing this chunk is sent via the path containing NAT 2, both NAT middleboxes have the required state. If this packet is sent on the path via NAT 1, any packet sent from the client on the path via NAT 2 results in an ERROR chunk being sent back, and this triggers the sending of an ASCONF chunk.

1 INIT INIT-ACK 2 3 COOKIE-ECHO COOKIE-ACK 4 NAT 1 NAT 2 Client Server 5
1
INIT
INIT-ACK
2
3
COOKIE-ECHO
COOKIE-ACK
4
NAT 1
NAT 2
Client
Server
5
ASCONF, ADD-IP
ASCONF-ACK
6

Figure 7. Multihoming through NAT middleboxes.

This chunk provides the required information to the NAT middlebox, NAT 2.

Multihomed Transport Layer Mobility

Previously, we discussed the procedure for a case when a client moves and hence changes its source address and the corresponding NAT middlebox as well. During the transition from one cell to another in a host mobility scenario, there is likely to be a zone where both cells are active, and thus, two addresses can be in use. Adding the new address results in a temporarily multihomed client. We propose to handle this sit- uation in a way similar to the case explained in the last sec- tion. The new address is added by the sending of a message containing an ASCONF chunk. But as the old address is com- pletely replaced by the new one as soon as the previous cell is left, another parameter must be added that indicates that the primary path should be set to the new address. This causes the server to send the next packets to the new address.

Multihoming with Rendezvous Server

The final step in increasing the complexity of the NAT sce- nario is the communication between two multihomed peers that are behind different NAT middleboxes. Just like in the single-homed case, the rendezvous server must gather the peer information to fill its table. This time the table must be enlarged by the additional addresses. The peers first set up an association with the rendezvous server. Using this server the peers can obtain each other’s addresses and port numbers. At this point, the peers must set up an association via ini- tialization collision to provide a path by using hole punching. To also use the second path, on the way, the NAT middlebox- es must obtain the required information. By sending messages containing ASCONF chunks almost simultaneously, the NAT middleboxes are notified to allow packets arriving from the opposite direction to pass through. Unfortunately, the mecha- nism described earlier to request information by sending a message containing an ERROR chunk does not work when coming from the global side of the network because only the host behind the NAT middlebox can provide the data to fill the NAT table. So when the message containing an ASCONF chunk arrives at the opposite NAT middlebox before a hole is punched, the packet is discarded, but its retransmission might be successful. After both NAT tables receive the appropriate entries, the secondary paths also can be used.

Conclusion

In this article, we proposed a comprehensive solution for the support of SCTP in NAT middleboxes. We motivated the necessity for a specific NAT concept with NAPT functionality, where the verification tags provided by SCTP are used to dis- tinguish between associations. The NAT middleboxes can request information from the SCTP end points and give hints to improve the overall procedure. Furthermore, several scenarios were analyzed to explain the manipulation of the NAT table in single-homed, multihomed, and mobility environments. The peer-to-peer communication with a preregistration was taken into account as well. Generalizing the SCTP-specific variant of NAT, the follow- ing is important. For supporting a transport protocol with multipath support, a connection identifier makes connection tracking possible without a requirement to rely on the port

numbers. This avoids the requirement of changing the port numbers and possibly synchronizing them between different NAT middleboxes. A feature of dynamic address reconfigura- tion can be used to avoid having IP addresses in the transport layer, which is problematic for the processing in NAT middle- boxes. For peer-to-peer communications, it is helpful if the transport layer supports simultaneous connection setups. Finally, it might be preferable to use simple algorithms involv- ing random numbers with a small chance of collision instead of more complex deterministic algorithms without collision. The solution presented in this article will be included in a future version of our Internet drafts to be considered for stan- dardization in the BEHAVE working group of the IETF.

References

[1] Q. Xie et al., “SCTP NAT Traversal Considerations,” draft-xie-behave-sctp- nat-cons-03.txt (work in progress), Nov. 2007. [2] R. Stewart and M. Tüxen, “Stream Control Transmission Protocol (SCTP) Net- work Address Translation,” draft-stewart-behave-sctpnat-03.txt (work in progress), Nov. 2007. [3] M. Tüxen and R. Stewart, “UDP Encapsulation of SCTP Packets,” draft- tuex- en-sctp-udp-encaps-02.txt (work in progress), Nov. 2007. [4] P. Srisuresh and M. Holdrege, “IP Network Address Translator (NAT) Termi- nology and Considerations,” RFC 2663, Aug. 1999. [5] R. Stewart, “Stream Control Transmission Protocol,” RFC 4960, Sept. 2007. [6] R. Stewart et al., “Stream Control Transmission Protocol (SCTP) Dynamic Address Reconfiguration,” RFC 5061, Sept. 2007. [7] M. Riegel and M. Tüxen, “Mobile SCTP Transport Layer Mobility Manage- ment for the Internet,” Proc. SoftCOM 2002, Int’l. Conf. Software, Telecom- munications and Computer Networks, Split, Croatia, 2002, pp. 305–09. [8] B. Ford and P. Srisuresh, “Peer-to-Peer Communication across Network Address Translators,” USENIX Annual Technical Conf., Anaheim, CA, Apr. 2005. [9] R. Stewart and Q. Xie, Stream Control Transmission Protocol (SCTP): A Refer- ence Guide, Addison-Wesley, Oct. 2001. [10] I. Rüngeler, M. Tüxen, and E. Rathgeb, “Integration of SCTP in the OMNeT++ Simulation Environment,” Int’l. Developers Wksp. OMNeT++ (OMNeT++ 2008), Mar. 2008.

Biographies

ERWIN P. RATHGEB (erwin.rathgeb@iem.uni-due.de) received his Dipl.-Ing. and Ph.D. degrees in electrical engineering from the University of Stuttgart, Germany, in 1985 and 1991, respectively. He has been a full professor at the University Duisburg-Essen since 1999 and holds the Alfried Krupp von Bohlen und Halbach Chair for Computer Networking Technology at the Institute for Experimental Math- ematics. From 1991 to 1998 he held various positions at Bellcore, Bosch Telekom, and Siemens. His current research interests include concepts and protocols for next-generation Internets with a focus on network security. He is a member of IFIP, GI, and ITG, where he is chairman of the expert group on network security.

R