publication vii - universitylib.tkk.fi/diss/2011/isbn9789526044026/article7.pdf · allow hip to use...

Publication VII

G. Camarillo, A. Keränen, and S. Pierrel. Automatic Flow-specificMulti-path Management for the Host Identity Protocol (HIP). InProceedings of the IEEE Wireless Communications and NetworkingConference (WCNC), Pages 1-6, April 2010.

c© 2010 IEEE.Reprinted with permission.

175

This material is posted here with permission of the IEEE. Such permission of the IEEE does not in any way imply IEEE endorsement of any of Aalto University's products or services. Internal or personal use of this material is permitted. However, permission to reprint/republish this material for advertising or promotional purposes or for creating new collective works for resale or redistribution must be obtained from the IEEE by writing to [email protected]. By choosing to view this document, you agree to all provisions of the copyright laws protecting it.

Automatic Flow-specific Multi-path Managementfor the Host Identity Protocol (HIP)

Gonzalo CamarilloNomadicLab

Ericsson ResearchJorvas, Finland

Email: [email protected]

Ari KeranenNomadicLab

Ericsson ResearchJorvas, Finland

Email: [email protected]

Sebastien PierrelEricsson Research

Stockholm, SwedenEmail: [email protected]

Abstract— In this paper, we describe an architecture for theHost Identify Protocol (HIP) to automatically manage the pathto be used between two hosts for a given traffic flow. Differentsimultaneous flows between the two hosts can take different paths.The architecture is based on and extends the Simultaneous Mul-tiaccess (SIMA) HIP extension and the Interactive ConnectivityEstablishment (ICE) framework. A key property of the policy-based path management proposed in this paper is that it includesNAT (Network Address Translation) traversal functionality.

I. INTRODUCTION

The Host Identity Protocol (HIP) [1] provides hosts withan integrated security, mobility, and multihoming solution.As originally specified, all traffic between two given HIPhosts was sent over the same IPsec-protected network path.This represented a problem because traffic can consist ofdifferent flows with different requirements. Flows with dif-ferent requirements may be better transported using differentpaths. Additionally, HIP did not originally include any NATtraversal mechanism. The lack of such a mechanism madeHIP’s deployment challenging.

In our previous work, we designed extensions to resolveboth of the previous issues in HIP’s original design. However,both extensions were not designed to work together and, thus,it was not possible to take advantage of both simultaneously.Additionally, the fact that they required manual input andknowledge of the characteristics of the network from users orapplications made them inconvenient to use by regular users.

In this paper, we propose an architecture that extends andcombines both extensions so that users and applications cantake advantage of both simultaneously in an automatic fashion.This architecture allows HIP hosts to automatically choose themost appropriate path for any particular flow based on a givenpolicy at any given time.

The remainder of this paper is organized as follows. Sec-tion II and Section III provide background information on HIPand ICE, respectively. Section IV describes our previous workin this area. Section V discusses the issues our architectureaims to resolve. Section VI presents our proposed architecturefor automatic flow-specific multi-path management in HIP.Section VII describes our implementation experience. Sec-tion VIII contains the conclusions of the paper.

II. BACKGROUND ON HIP

The current TCP/IP model uses the IP address of a host bothas its locator and identifier: the address is needed to route andforward the packets to the right destination in the network,but the address also names the host’s networking interface.This dual role of IP addresses presents problems especiallyfor mobile and multi-homed hosts.

A mobile host may change its point of attachment in thenetwork while being used for network communications. Amulti-homed host has multiple network interfaces, which itcan use either simultaneously or one at a time. Differentnetwork interfaces have different IP addresses. Also, even astationary host with a single network interface may end upusing different IP addresses due to dynamic configuration. Inall of these cases, the IP address of the host will change eventhough the host that is connected to the network remains thesame. Traditionally, transport layer connections are bound toan IP address of the host and, if the address changes, theconnection does not survive. Therefore, dynamically changingIP addresses are a problem for the hosts.

Even if the transport layer connections survived from achange of IP address, there are security problems with mul-tihoming and mobility. Since there must be a way to changethe IP address where the traffic is delivered, a malicious hostcan try to pretend to be the rightful owner of the traffic anddivert the traffic to itself for inspection or for performing aman-in-the-middle attack. Similarly, an attacker can try divertthe traffic to a victim host which will receive unsolicited trafficresulting in Denial-of-Service (DoS) attack.

HIP aims to resolve these problems by inserting a newhost identity layer and namespace between the transport andinternetworking layers of the IP stack as depicted in Figure 1.Instead of using the IP address as the identifier for the host,with HIP, the identifier is the public key of an asymmetriccryptographic key pair. Also, instead of binding connectionsto the IP address, transport layer protocols can now bind to apresentation of the host identifier: Host Identity Tag (HIT). Thehost identifier can remain the same regardless of the IP addressthat is currently used for it. Because the binding between thehost identity and the IP address is not fixed, the IP addresscan change without breaking the transport layer connections.

This full text paper was peer reviewed at the direction of IEEE Communications Society subject matter experts for publication in the WCNC 2010 proceedings.

978-1-4244-6398-5/10/$26.00 ©2010 IEEE

Fig. 1. Identifiers in different layers of TCP/IP stack with HIP

With this solution, mobility and multi-homing can be han-dled in a more natural way since multiple IP address canbe bound to a host identifier and the underlying IP addresscan be changed dynamically. Also, because the host identifieris an asymmetric cryptographic key, the host can prove thatit is allowed to use the identifier with the private key. Thissolves the problem with malicious hosts trying to change thedestination of the traffic.

During the connection set up phase HIP hosts prove theiridentity using the asymmetric cryptographic keys but they alsoperform a Diffie Hellman key exchange that allows them toderive symmetric keys and use them to set up an IPsec securedconnection. IPsec Encapsulating Security Payload (ESP) [2]provides confidentiality and integrity protection for all thetraffic that is exchanged between the hosts.

III. BACKGROUND ON ICE

Interactive Connectivity Establishment (ICE) [3] is a proto-col for traversing NATs. ICE was originally designed as a NATtraversal solution for sessions established using the SessionInitiation Protocol (SIP). Nevertheless, ICE is also applicableto other session oriented protocols that need connectivity inNATed networks [4] [5].

The main idea of ICE is quite simple: when a host wants tocommunicate with another host, it gathers a set of addressesand ports where the host thinks it might be reachable on. Theseaddress-port pairs, called candidates, are communicated to theother host using a signaling protocol like SIP. When the otherhost is informed about the incoming connection attempt, it alsogathers a set of candidates, announces them to the first host,and then both hosts send connectivity checks to each others’candidates. When these connectivity checks succeed on someof the candidate pairs, those pairs are marked as working. Afterthe checks, the candidate pair that had successful checks andhas the highest priority is selected and further communicationcan use the path between those addresses.

The local addresses and ports that are gathered can be fromthe physical network interfaces such as Ethernet or WiFi or

from virtual interfaces such as Virtual Private Network (VPN)tunnels. These local candidates are called host candidates.If some of the host’s network interfaces are behind a NAT,hosts on the other side of the NAT see the NAT’s addresswhen communicating with the host. ICE uses the SessionTraversal Utilities for NAT (STUN) protocol [6] to determinethe addresses and ports hosts in the globally routable Internetsee. This is done by sending requests from all the interfacesto a STUN server that is known to be on the other sideof the NATs (if there are any), asking for the address theSTUN server sees the request coming from. This query, calledBinding Request, also creates address translation bindings inthe NATs that are on the path. The STUN server replies usingthe same path and the requesting node learns the addressesand ports the NATs allocated to it. Candidates that are learnedthis way from an external server are called server reflexivecandidates.

Some NATs do not allow a reply to come from a differentaddress and/or port than where the request was sent to. Thisis called address (and port)-dependent filtering [7]. If the hostthat is doing the address gathering is behind such a NAT, onlythe STUN server can use the return path that is discoveredusing the Binding Request and packets from all other sourceaddresses (and ports) are dropped. This means that the addressallocated by the NAT cannot be used to communicate withthe remote host. In cases like this, a relay is needed. TraversalUsing Relays around NAT (TURN) [8], which is an extensionto STUN, can be used to obtain relayed addresses from aTURN server. If the TURN server is reachable from both ofthe hosts, they can communicate using it even if the NATsprevent direct communication. These relayed candidates arealso announced to the other party for the connectivity checks.

Before announcing the candidates, they are locally priori-tized. The simple prioritization algorithm works in a way thatsimilar candidates get similar priorities and candidates contain-ing less hops (i.e., less NATs and/or relays) are preferred (i.e.,host candidates are preferred to reflexive candidates, which arepreferred to relayed candidates). Within those limits the hostscan substantially effect the priorities using local policies. Afterprioritization, the candidates are coded in a way that is suitablefor the signaling protocol and they are sent to the other host.When both hosts have exchanged their prioritized candidates,the priorities of the local candidates are combined with thepriorities of the remote candidates and a checklist is formedwith higher priority candidate pairs on top of the list.

Connectivity checks are done sequentially in the order thecandidate pairs are in the checklist. STUN messages are sentbetween the candidates and if a request-response exchangesucceeds, a working candidate pair has been found. It ispossible, and even fairly common, that multiple working pathsare discovered during the connectivity tests but only the onewith the highest priority is selected for use.

IV. PREVIOUS WORK

Our previous work focused on extending HIP in order to ad-dress two important issues. Section IV-A describes our work to


allow HIP to use different accesses simultaneously. Section IV-B describes our work to add NAT traversal capabilities to HIP.Section V describes the issues we faced after having extendedHIP in those ways. These issues were the motivation to startthe work that is described in Section VI.

A. Simultaneous Multiaccess for HIPAs originally specified, HIP supported basic multihoming

capabilities. A HIP host with two IP addresses on two differentinterfaces could use any of those IP addresses to communicatewith another host. However, the host had to use a single IPaddress at a given time. That is, all traffic between both hostsfollowed the same path. When the path changed (e.g., becausethe host starts using the IP address on the other networkinterface), all traffic was routed to the new path.

We proposed an extension to provide HIP with more ad-vanced multihoming capabilities. The Simultaneous Multiac-cess (SIMA) extension, which is described in [9], allows a HIPhost to use multiple accesses simultaneously. In that way, ahost on the move could use, for example, a hotspot-based WiFiaccess to download a file whenever the network was availableand a ubiquitous cellular access for a video conference.

B. NAT Traversal for HIPHIP’s original design did not include NAT traversal ca-

pabilities. However, most network deployments at presentimplement some type of NAT functionality. Therefore, it wasessential for HIP to be able to traverse NATs. We extendedHIP to include an ICE-based NAT traversal solution, which isspecified in [5].

Having a NAT traversal solution that is based on ICE has theadvantage that HIP hosts can use already deployed STUN andTURN servers on the Internet. Most of these servers have beendeployed to facilitate NAT traversal for multimedia SIP-basedapplications but can be now used by HIP hosts implementingthe NAT traversal extension.

This NAT traversal extension is especially important inpeer-to-peer environments where HIP nodes form overlays[10]. In these environments, it is not uncommon for twocommunicating hosts to be both behind a NAT. Such hostscan use STUN and TURN servers that are deployed as part ofthe network infrastructure (as discussed earlier) or have a setof the nodes forming the overlay acting as STUN or TURNservers.

V. PROBLEM STATEMENT

The extensions described in Sections IV-A and IV-B ad-dressed two important issues in HIP’s original design. How-ever, there remained more issues to be addressed in futureextensions.

The SIMA extension explicitly takes into account multipleaccesses but not multiple paths in general. When ICE is used,a host can find multiple working paths for a given access andthe SIMA extension would benefit from being able to handleall of them.

Users or applications making use of the SIMA extensionneed to manually configure the mapping between flows and

User orApplication

PolicyModule

SIMAModule

ICEModule

Fig. 2. Architecture

accesses. For example, a user needs to manually configureSIMA to route file transfer traffic through a WiFi access in-stead of though a cellular one because the user knows that theparticular WiFi access has more bandwidth than the particularcellular access. In an ideal situation, the user, or application,would only need to specify a high-bandwidth policy for thefile transfer traffic. The system would automatically take careof discovering the characteristics of each access and routingthe traffic to the most appropriate one. Additionally, if thesituation changes (e.g., the WiFi access gets saturated andits characteristics get worse), the system should automaticallychoose a new access. Of course, the system should not onlyconsider accesses but paths in general. That is, the systemshould choose the path whose characteristics are closest tothe ones required by the user or application.

As discussed previously, ICE provides additional paths be-cause it can find multiple paths using a given access. However,ICE implementations typically focus on connectivity and justcheck paths to see if they work. They typically pick the firstone that works an start using it for exchanging traffic. Afterthat, the host focuses on keeping that single connection up.In order to take advantage of SIMA, the host needs to beable to continuously be aware of the current characteristics ofthe multiple paths available and use those paths that are mostappropriate for the current traffic flows.

The architecture described in Section VI addresses the is-sues discussed in this section. Note that these issues are relatedbut are not the same as the ones addressed by the so calledmulti-path TCP work [11], which aims to simultaneously useall paths available between two hosts for a TCP connection.

VI. PROPOSED ARCHITECTURE

Figure 2 shows the architecture we propose to resolve theissues described in Section V. The architecture consists ofthree modules: the policy module, the ICE module, and theSIMA module.

A. Policy ModuleThe policy module takes care of getting input from the user

or application on the preferences for different traffic flows. Forexample, a flow consisting of real-time traffic may need to usethe lowest-delay path at any given time while a flow consistingof a file transfer may need to use the highest-throughput path.Users can also provide the policy module with informationabout network interfaces that cannot be obtained otherwisesuch as the cost of usage. For example, a user can inform the


policy module that charging in WiFi access is based on a flatrate while using the cellular access costs a given amount ofmoney per megabyte.

The policy module obtains further information about differ-ent available paths from the ICE module, which is described inSection VI-B. The ICE module measures path features suchas currently available bandwidth and delay and informs thepolicy module. Depending on the preferences given to thepolicy module, the policy module instructs the ICE module tomeasure certain features. For example, if the policy module hasnot gotten any bandwidth-related preferences, it will instructthe ICE module not to do any bandwidth measurements.

With all the information about the available paths and thepreferences from the user or application, the policy moduledecides which path should be used for which flow. Oncethis decision is made, the policy module instructs the SIMAmodule to route traffic flows accordingly.

Simple policies such as “this traffic flow needs to use thelowest-delay path” are often good-enough for users. However,more complex policies allow the policy module to makebetter decisions. In our system users or applications providingthe policy module with a more complex policy can givea maximum vmax or minimum vmin acceptable value andanother value vok that describes what is “enough” for eachof the measured path features that are relevant for the stream.Whether to use a maximum or minimum limit depends on thetype of the feature: for example, delay would have a maximumacceptable value whereas bandwidth would be limited by thesmallest acceptable value. If the path’s value vp is worse thanthe maximum or minimal acceptable value, the path is nottaken into account as an option. Otherwise, the path’s value’snormalized difference d is calculated according to equation 1(for the values which have an upper limit) or 2 (for the valueswhich have a lower limit).

d =

⎧⎨⎩0 if vp < vok;vp − vok

vmax − vokotherwise.

(1)

d =

⎧⎨⎩0 if vp > vok;vok − vpvok − vmin

otherwise.(2)

All the features are also paired with a significance coeffi-cient ki which can be used to adjust the importance of eachof the features. The value of ki should be in the range of[0, 1] where 1 denotes high importance, values close to zero alow importance, and a zero value means that the feature is notrelevant. Finally, the error E is calculated from the normalizeddifference values di using the equation 3.

E =qk1d21 + k2d22 + k3d23 + . . . (3)

The path that minimizes E is selected to be used foreach stream. This way the path that has the closest match tothe stream’s preferences, taking all the relevant features intoaccount, will be used.

B. ICE ModuleA typical ICE module used only for NAT traversal normally

selects the first path where it can run a successful connectivitycheck. In many situations, a path selected in that way is notthe best path for a given traffic flow. We have enhanced theICE module so that in addition to running connectivity checkson different paths, it also measures various features fromthose paths. The path features that are measured are the onesindicated by the policy module, as described in Section VI-A. The fact that the same messages used by ICE to performconnectivity checks and to keep NAT binding updates alivecan also be used to measure certain path features (e.g., theroundtrip delay) saves time and bandwidth.

Features of the different paths can be extracted in multipleways and one of our goals is to do this as automatically asfeasible. Interesting path features include bandwidth, delay,jitter, reliability, and cost. Initial estimates of the delay canalready be made based on the connectivity tests that ICEperforms. Because connectivity tests include a request-replytransaction, calculating Round-Trip Time (RTT) estimates isstraightforward. Similar transactions are performed on all thepaths that work in order to calculate the jitter and to have morereliable estimate for the RTT. These transactions also helpkeep NAT bindings alive. Probing end-to-end methodologiessuch as PathMon [12] can also be used to measure availablebandwidth and to get more accurate estimates of the round-triptime and jitter.

The reliability of the path can also be estimated based oninitial and subsequent connectivity checks. The amount ofconnectivity checks lost provides an estimate for the packetloss in the path. Similarly, if some path bandwidth probingmethodology is used, lost probe messages before congestionoccurs may indicate high packet loss on the path. Also,by checking if the ECN [13] bit is set in some incomingconnectivity check or probing packets, some insight can begained into the congestion situation on the path.

While a typical ICE module decides which path will beused, our enhanced ICE module does not make that decisionitself. Instead, if provides the policy module with all thenecessary information for the policy module to make thedecision, as described in Section VI-A.

C. SIMA ModuleWhen the policy module decides which path should be used

for each traffic flow, it instructs the SIMA module about theflow-path mapping to be used. The SIMA module executesthe decisions made by the policy module as described in [9].

VII. IMPLEMENTATION

We have evaluated the ideas proposed in previous sectionsby implementing both ICE and PathMon based path character-istics measurements and testing what kind of path selectionsour algorithm makes for different access, path, and traffictypes.

Our basic HIP implementation [14] consists of approxi-mately 25,000 lines of C code and can run on Linux and


Fig. 3. Discovered paths between two HIP hosts

FreeBSD platforms. The implementation runs as a user spacedaemon and it uses the PF KEY [15] socket to control theIPsec policies and security associations. The extensions toimplement the architecture described in this paper in a proof-of-concept prototype consist of approximately 11,000 lines ofC code: the SIMA extensions including the policy module takeroughly 2,000, our ICE implementation 8,000, and our STUN-based implementation of the PathMon bandwidth probingmethodology around 1,000 lines of code.

A. Example Scenario

As an example, we connected a HIP host with two accesses(Ethernet and 3G cellular) with a remote HIP host with justone access (Ethernet). Our ICE module found five workingpaths1 that could be used to communicate with the remotehost. The paths are shown in Figure 3. Table I shows themeasured characteristics for those paths. The remote HIP hostwas not behind a NAT so it has two working candidates: host(H) and relayed (R). The local HIP host’s Ethernet access (E)was behind a NAT, but the cellular (C) was not. So, the hosthad a server reflexive candidate from E and a host candidatefrom C. Also, the local HIP host had a relayed (R) candidatefrom the Ethernet access. Both HIP hosts were located inFinland, the remote host’s relay was located in East Europeand local host’s relay in South America (and thus connectionsthrough it have considerably long measured RTT). This settingrepresents two roaming hosts in Finland, one from East Europeand one from South America, both of which use their homerelays. The setting can also represent two hosts in an overlaythat get relay services from other peers in the overlay. TheRTT measurements were based on the ICE transactions andconfirmed by the PathMon transactions. Jitter and bandwidthmeasurements were based on PathMon probing results.

TABLE IMEASURED CHARACTERISTICS FOR DIFFERENT PATHS

Path (local-remote) E-H E-R R-H R-R C-HRTT (ms) 13 95 462 526 115Jitter (ms) 0.1 0.2 0.7 0.5 8.0

Bandwidth (Mbps) 10.80 10.56 7.68 6.96 0.32

1Also paths from cellular access via relays were found but for the sake ofsimplicity they are excluded from the analysis

In our test scenario we had two data flows, one for dataand another for control signaling. We specified the require-ments for the traffic as shown in Table II. To take also pathavailability into account, we defined the availability metricvalue (in range of [0, 1]) as 0.7 for E-H path, 0.6 for all pathswith a relay, and 0.9 for the highly likely available C-H path.For the sake of simplicity, all values had equal significancecoefficients with value 1.

TABLE IIEXAMPLE REQUIREMENTS FOR TWO TRAFFIC TYPES

Bandwidth min / OK RTT max / OK Availability min / OKControl 0.1 / 0.4 (Mbps) 200 / 100 (ms) 0.6 / 0.9

Data 0.5 / 2.0 (Mbps) 500 / 20 (ms) 0.3 / 0.9

Table III shows the error values that resulted from usingformula 3 with the requirements in Table II and the path valuesin Table I. The R-H path does not have a value for controltraffic since its RTT was too high. Similarly, the RTT of theR-R path was too high for both data flows and the C-H path’sbandwidth was too low for data traffic. From the remainingvalues we see that C-H and the E-H paths were the best choicesfor control and data traffic respectively. Hence, in this scenario,the policy module instructed the SIMA module to route controltraffic without a relay via the cellular interface and data trafficvia the Ethernet interface.

TABLE IIIERROR VALUES FOR DIFFERENT PATHS

Path E-H E-R R-H R-R C-HError (control) 0.67 1.00 - - 0.31

Error (data) 0.33 0.52 1.05 - -

When we used a typical ICE implementation for path selec-tion instead of our enhanced implementation, the results weredifferent. The typical ICE implementation always preferred theonly host-host candidate pair (C-H) over the other candidatepairs. While this was a good choice for the control traffic, theC-H path was not suitable for the data traffic because of itshigh latency and low bandwidth.

This example shows how the ability to use different pathsfor different traffic flows, to discover all available paths to andfrom the remote host, and to measure the characteristics of allthose paths allowed our implementation (which follows thearchitecture proposed in this paper) to use the network in abetter way.

B. Learnings from Implementing PathMonFrom implementing the PathMon bandwidth determining

methodology we learned that the basic algorithm proposedin [12] is often not sufficiently reliable in measurements doneover the Internet. For example, high variations in jitter overtime often resulted in incorrect estimations of the availablebandwidth. Instead, averaging delay-difference values overa few samples and focusing on the delay-difference trend,


instead of on single values, gave fairly consistent and accurateestimates on the Ethernet access.

Cellular accesses turned out to be even harder to measurebecause of the rate adaptation 3G cellular network performsdepending on the amount of traffic offered on the link. Byusing longer probing times and larger amount of packets, wewere still able to get a rough estimate of the bandwidth thatwas used as input for the SIMA path selection algorithm.

Also, the PathMon probing results get much more incon-sistent when the Ethernet access is placed behind a consumergrade NAT device2. Sometimes the NAT increased the delayof some packets up to milliseconds and that affects heavily thePathMon algorithm when trying to measure a high bandwidthlink. Also in this case averaging values over multiple measure-ments, while slightly slowing down the selection of the path,helped getting usable estimates of the available bandwidth. Weused all these enhancements in the experiments described inSection VII-A.

VIII. CONCLUSIONS

In this paper we have proposed an architecture to managethe paths taken by multiple simultaneous traffic flows betweentwo hosts using HIP. In order to choose the most appropriatepath for a traffic flow at any given point, it is necessary tomeasure the characteristics of the available paths and comparethem with the policy for the traffic flow.

Instead of designing a system to find available paths andmeasure path characteristics from scratch, we combine pathmeasurements with the ICE-based NAT traversal procedures.This combination allows our architecture to get better resultsand make a more efficient use of network resources. ICE isable to find more available paths than previously-proposedsimultaneous access solutions. We also reuse the traffic sentby ICE to keep NAT bindings alive in order to performmeasurements such as round trip times.

Once our policy module obtains the characteristics of allavailable paths, it chooses the path that minimizes the distancebetween the characteristics required for the traffic flow and thecharacteristics of the path.

This architecture is especially useful for HIP hosts ex-changing different types of traffic simultaneously becauseeach traffic flow can be treated differently. For example, twomultimedia applications running at two HIP hosts can handlesignaling, video, voice, instant-messaging, and file transfers.Using the architecture proposed in this paper, each traffic flowuses the most appropriate path for its needs.

2We used a D-Link DIR-635 wireless router

We have implemented the architecture proposed in thispaper in a proof-of-concept prototype. Our implementationincludes HIP, policy handling, ICE, SIMA control, and Path-Mon. We implemented an enhanced version of the PathMonmethodology for situations where knowing the available band-width is important. PathMon provides more accurate RTT andjitter estimates at the expense of a higher bandwidth usage. Wealso identified shortcomings in PathMon algorithm for Internetenvironments and proposed enhancements to overcome thoseshortcomings.

REFERENCES

[1] R. Moskowitz, P. Nikander, P. Jokela, and T. Henderson, “Host IdentityProtocol,” RFC 5201, Apr. 2008.

[2] P. Jokela, R. Moskowitz, and P. Nikander, “Using the EncapsulatingSecurity Payload (ESP) Transport Format with the Host Identity Protocol(HIP),” RFC 5202, Apr. 2008.

[3] J. Rosenberg, “Interactive Connectivity Establishment (ICE): A Protocolfor Network Address Translator (NAT) Traversal for Offer/AnswerProtocols,” draft-ietf-mmusic-ice-19.txt (work in progress), Internet En-gineering Task Force, Oct. 2007, expires: May 1, 2008.

[4] P. Saint-Andre, “Jingle: Jabber does multimedia,” IEEE MultiMedia,vol. 14, no. 1, pp. 90–94, 2007.

[5] M. Komu, T. Henderson, H. Tschofenig, J. Melen, and A. Keranen,“Basic HIP Extensions for Traversal of Network Address Translators,”draft-ietf-hip-nat-traversal-09.txt (work in progress), Internet Engineer-ing Task Force, Oct. 2009, expires: April 26, 2010.

[6] J. Rosenberg, R. Mahy, P. Matthews, and D. Wing, “Session TraversalUtilities for (NAT) (STUN),” RFC 5389, Oct. 2008.

[7] F. Audet and C. Jennings, “Network Address Translation (NAT) Behav-ioral Requirements for Unicast UDP,” RFC 4787, Jan. 2007.

[8] J. Rosenberg, R. Mahy, and C. Huitema, “Traversal Using Relaysaround NAT (TURN): Relay Extensions to Session Traversal Utilities forNAT (STUN),” draft-ietf-behave-turn-16.txt (work in progress), InternetEngineering Task Force, Jul. 2009, expires: January 4, 2010.

[9] S. Pierrel, P. Jokela, J. Melen, and K. Slavov, “A Policy systemfor Simultaneous Multi-Access with the Host Identity Protocol,” inProceedings of the 1st IEEE Workshop on Autonomic Communicationsand Network Management (ACNM 2007), May 2007.

[10] G. Camarillo, P. Nikander, J. Hautakorpi, A. Keranen, and A. Johnston,“HIP BONE: Host Identity Protocol (HIP) Based Overlay NetworkingEnvironment,” draft-ietf-hip-bone-03.txt (work in progress), InternetEngineering Task Force, Oct. 2009, expires: April 29, 2010.

[11] A. Ford, C. Raiciu, S. Barre, J. Iyengar, and B. Ford, “Architec-tural Guidelines for Multipath TCP Development,” draft-ford-mptcp-architecture-00.txt (work in progress), Internet Engineering Task Force,Oct. 2009, expires: April 22, 2010.

[12] D. Kiwior, J. Kingston, and A. Spratt, “PathMon, a Methodologyfor Determining Available Bandwidth over an Unknown Network,”Advances in Wired and Wireless Communication, 2004 IEEE/SarnoffSymposium on, pp. 27–30, 26-27 Apr 2004.

[13] K. Ramakrishnan, S. Floyd, and D. Black, “The addition of explicitcongestion notification (ECN) to IP,” RFC 3168, Sep. 2001.

[14] “hip4bsd,” http://www.hip4inter.net, HIP implementation for BSD andLinux. Referenced on 14.9.2009.

[15] D. McDonald, C. Metz, and B. Phan, “PF KEY key management API,version 2,” RFC 2367, Jul. 1998.


publication vii - universitylib.tkk.fi/diss/2011/isbn9789526044026/article7.pdf · allow hip to use...

Documents