Abstract — The Host Identity Protocol (HIP) fundamentally changes the way two hosts in the Internet communicate. One key advantage over other schemes is that HIP does not require any modifications to the traditional network-layer functionality of the Inte
Workshop on HIP and Related Architectures, Washington, DC, USA, November 6, 2004. 1 Middlebox Traversal of HIP Communication
Martin Stiemerling, Jürgen Quittek and Lars Eggert
Abstract — The Ho st Identity Pro to co l (HIP) fundamentally changes the way two hosts in the Internet communicate. One key advantage o ver o ther schemes is that HIP do es no t require any modifications to the traditional network-layer functionality of the Internet, i.e., its ro uters. HIP deplo yment sho uld therefo re be transparent. In the current Internet, ho wever, many devices other than routers may affect the network-layer behavio r of the Internet. These “middlebo xes” are intermediary devices that perfo rm functio ns o ther than the no rmal, standard functio ns o f an IP ro uter o n the datagram path between so urce ho st and destinatio n ho sts. Examples o f middlebo xes include netwo rk address translato rs, packet classifiers, perfo rmance-enhancing pro xies, lo ad balancers amo ngst many. Whereas so me types o f middleboxes may not interfere with HIP at all, others can affect so me aspects o f HIP co mmunicatio n and o thers can render HIP communication impossible. This document examines the specifics of how middleboxes can interfere with HIP and discusses options to enable HIP traffic to traverse so me types o f middlebo xes.It does not promote the use of any of the discussed types of middle-boxes.
I.I NTRODUCTION
HE current specification of the Host Identity Protocol (HIP) [1] assumes simple Internet paths, where routers forward globally routable IP packets based on their destination address alone. Over such paths, the HIP protocol performs well.
In the current Internet, such pure paths are becoming in-creasingly rare. For a number of reasons, several types of devices modify or extend the pure forwarding functionality the Internet’s network layer used to deliver. RFC 3234 [3] coins the term middleboxes for such devices: “A middlebox is (…) any 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.” Middleboxes affect communication in a number of ways. For example, they may inspect the flows of some transport protocols, such as TCP, and selectively drop, insert or modify packets. If such devices encounter a higher-layer protocol they do not support, or even a variant of a supported protocol that they do not know how to handle, communication across the middlebox may become impossible for these kinds of traffic. There are many different variants of middleboxes. The most common ones may be network address translators and fire-walls. RFC 3234 identifies many other types of middleboxes. One broad way of classifying them is by behavior. The first group operates on packets, does not modify application-layer Manuscript received October 1, 2004. Parts of this work are a product of the Ambient Networks and Enthrone projects supported in part by the Euro-pean Commission under its Sixth Framework Programme. It is provided “as is” and without any express or implied warranties, including, without limita-tion, the implied warranties of fitness for a particular purpose. The views and conclusions contained herein are those of the authors and should not be interpreted as necessarily representing the official policies or endorsements, either expressed or implied, of the Ambient Networks or Enthrone projects or the European Commission.
Martin Stiemerling, Jürgen Quittek and Lars Eggert are with NEC Europe Ltd, N etwork Laboratories, Heidelberg, Germany (phone: +49-6221-905-1143; fax: +49-6221-905-1155; e-mail: {stiemerling, quittek, eggert} @netlab.nec.de.) payloads and does not insert additional packets. This group includes N AT, N AT-PT, SOCKS gateways, IP tunnel end-points, packet classifiers, markers, schedulers, transport relays, IP firewalls, application firewalls, involuntary packet redirec-tors and anonymizers. Other middleboxes exist, such as TCP performance-enhancing proxies, application-level gateways, gatekeepers and session control boxes, transcoders, proxies, caches, modified DN S servers, content and applications distribution boxes, load balancers that divert or modify URLs, application-level interceptors and application-level multicast systems.
An earlier document investigated the impact of network address translation on HIP deployment [2]. However, it does not discuss the interactions of HIP and other types of middle-boxes. Section II of this document describes a simple network scenario involving a middlebox and investigates how different types of middleboxes affect HIP communication in the given scenario. Section III discusses future work and summarizes the document.
II.HIP A CROSS M IDDLEBOXES
Figure 1 illustrates a simple network scenario that involves
搜索“diyifanwen.net”或“第一范文网”即可找到本站免费阅读全部范文。收藏本站方便下次阅读,第一范文网,提供最新外语学习Middlebox Traversal of HIP Communication全文阅读和word下载服务。
相关推荐: