idnits 2.17.1 draft-irtf-hip-experiment-15.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document seems to contain a disclaimer for pre-RFC5378 work, and may have content which was first submitted before 10 November 2008. The disclaimer is necessary when there are original authors that you have been unable to contact, or if some do not wish to grant the BCP78 rights to the IETF Trust. If you are able to get all authors (current and original) to grant those rights, you can and should remove the disclaimer; otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (December 16, 2011) is 4487 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Obsolete informational reference (is this intentional?): RFC 2988 (Obsoleted by RFC 6298) -- Obsolete informational reference (is this intentional?): RFC 4423 (Obsoleted by RFC 9063) -- Obsolete informational reference (is this intentional?): RFC 5201 (Obsoleted by RFC 7401) -- Obsolete informational reference (is this intentional?): RFC 5202 (Obsoleted by RFC 7402) -- Obsolete informational reference (is this intentional?): RFC 5203 (Obsoleted by RFC 8003) -- Obsolete informational reference (is this intentional?): RFC 5204 (Obsoleted by RFC 8004) -- Obsolete informational reference (is this intentional?): RFC 5205 (Obsoleted by RFC 8005) -- Obsolete informational reference (is this intentional?): RFC 5206 (Obsoleted by RFC 8046) -- Obsolete informational reference (is this intentional?): RFC 3775 (Obsoleted by RFC 6275) -- Obsolete informational reference (is this intentional?): RFC 6253 (Obsoleted by RFC 8002) == Outdated reference: A later version (-33) exists of draft-ietf-hip-native-nat-traversal-01 == Outdated reference: A later version (-24) exists of draft-ietf-lisp-18 == Outdated reference: A later version (-11) exists of draft-henderson-hip-vpls-03 == Outdated reference: A later version (-04) exists of draft-zhang-hip-privacy-protection-03 == Outdated reference: A later version (-05) exists of draft-irtf-hiprg-proxies-04 == Outdated reference: A later version (-06) exists of draft-moskowitz-hip-rg-dex-05 Summary: 0 errors (**), 0 flaws (~~), 7 warnings (==), 12 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IRTF HIP Research Group T. Henderson 3 Internet-Draft The Boeing Company 4 Intended status: Informational A. Gurtov 5 Expires: June 18, 2012 University of Oulu 6 December 16, 2011 8 HIP Experiment Report 9 draft-irtf-hip-experiment-15 11 Abstract 13 This document is a report from the IRTF HIP research group 14 documenting the collective experiences and lessons learned from 15 studies, related experimentation, and designs completed by the 16 research group. The documents summarizes implications of adding HIP 17 to host protocol stacks, Internet infrastructure, and applications. 18 The perspective of a network operator, as well as a list of HIP 19 experiments, are presented as well. Portions of this report may be 20 relevant also to other network overlay-based architectures or to 21 attempts to deploy alternative networking architectures. 23 Status of this Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at http://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on June 18, 2012. 40 Copyright Notice 42 Copyright (c) 2011 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (http://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 This document may contain material from IETF Documents or IETF 56 Contributions published or made publicly available before November 57 10, 2008. The person(s) controlling the copyright in some of this 58 material may not have granted the IETF Trust the right to allow 59 modifications of such material outside the IETF Standards Process. 60 Without obtaining an adequate license from the person(s) controlling 61 the copyright in such materials, this document may not be modified 62 outside the IETF Standards Process, and derivative works of it may 63 not be created outside the IETF Standards Process, except to format 64 it for publication as an RFC or to translate it into languages other 65 than English. 67 Table of Contents 69 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 70 1.1. What is HIP? . . . . . . . . . . . . . . . . . . . . . . . 4 71 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5 72 1.3. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 5 73 1.4. Organization . . . . . . . . . . . . . . . . . . . . . . . 6 74 2. Host Stack Implications . . . . . . . . . . . . . . . . . . . 7 75 2.1. Modifications to TCP/IP stack implementations . . . . . . 7 76 2.1.1. ESP implementation extensions . . . . . . . . . . . . 9 77 2.2. User-space implementations . . . . . . . . . . . . . . . . 10 78 2.3. Issues common to both implementation approaches . . . . . 10 79 2.3.1. User-space handling of HITs . . . . . . . . . . . . . 10 80 2.3.2. Opportunistic mode . . . . . . . . . . . . . . . . . . 11 81 2.3.3. Resolving HITs to addresses . . . . . . . . . . . . . 12 82 2.3.4. IPsec management API extensions . . . . . . . . . . . 13 83 2.3.5. Transport protocol issues . . . . . . . . . . . . . . 13 84 2.3.6. Legacy NAT traversal . . . . . . . . . . . . . . . . . 15 85 2.3.7. Local management of host identity namespace . . . . . 15 86 2.3.8. Interactions with host firewalls . . . . . . . . . . . 16 87 2.4. IPv4 vs. IPv6 issues . . . . . . . . . . . . . . . . . . . 16 88 2.5. What have early adopters learned from experience? . . . . 17 89 3. Infrastructure Implications . . . . . . . . . . . . . . . . . 19 90 3.1. Impact on DNS . . . . . . . . . . . . . . . . . . . . . . 19 91 3.2. HIP aware middleboxes . . . . . . . . . . . . . . . . . . 19 92 3.3. HIT resolution infrastructure . . . . . . . . . . . . . . 19 93 3.4. Rendezvous servers . . . . . . . . . . . . . . . . . . . . 20 94 3.5. Hybrid DNS-DHT resolution . . . . . . . . . . . . . . . . 21 95 4. Application Implications . . . . . . . . . . . . . . . . . . . 22 96 4.1. Non-intrusive HIP insertion . . . . . . . . . . . . . . . 22 97 4.2. Referrals . . . . . . . . . . . . . . . . . . . . . . . . 22 98 4.3. Latency . . . . . . . . . . . . . . . . . . . . . . . . . 22 99 5. Network Operator's Perspective . . . . . . . . . . . . . . . . 23 100 5.1. Management of the host identity namespace . . . . . . . . 23 101 5.2. Use of ESP encryption . . . . . . . . . . . . . . . . . . 23 102 5.3. Access control lists based on HITs . . . . . . . . . . . . 24 103 5.4. Firewall issues . . . . . . . . . . . . . . . . . . . . . 24 104 6. User Privacy Issues . . . . . . . . . . . . . . . . . . . . . 26 105 7. Experimental Basis of this Report . . . . . . . . . . . . . . 28 106 8. Related Work on ID-Locator Split . . . . . . . . . . . . . . . 30 107 9. Security Considerations . . . . . . . . . . . . . . . . . . . 32 108 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 33 109 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 34 110 12. Informative References . . . . . . . . . . . . . . . . . . . . 35 111 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 42 113 1. Introduction 115 This document summarizes the work and experiences of the Host 116 Identity Protocol IRTF Research Group (HIP-RG) from the 2004-2009 117 timeframe. The HIP-RG was chartered to explore the possible benefits 118 and consequences of deploying the Host Identity Protocol architecture 119 [RFC4423] in the Internet, and to explore extensions to HIP. 121 This document was developed over several years as the main charter 122 item for the HIP research group, and has received inputs and reviews 123 from most of the active research group participants. There is 124 research group consensus to publish it. 126 1.1. What is HIP? 128 The Host Identity Protocol architecture introduces a new name space, 129 the "host identity" name space, to the Internet architecture. The 130 express purpose of this new name space is to allow for the decoupling 131 of identifiers (host identities) and locators (IP addresses) at the 132 internetworking layer of the architecture. The contributors to HIP 133 have expected that HIP will enable alternative solutions for several 134 of the Internet's challenging technical problems, including 135 potentially host mobility, host multihoming, site multihoming, IPv6 136 transition, NAT traversal, and network-level security. Although 137 there have been many architectural proposals to decouple identifiers 138 and locators over the past 20 years, HIP is one of the most actively 139 developed proposal in this area. 141 The Host Identity Protocol itself provides a rapid exchange of host 142 identities (public keys) between hosts and uses a Sigma ("SIGn-and- 143 MAc")-compliant Diffie-Hellman key exchange to establish shared 144 secrets between such endpoints [RFC5201]. The protocol is designed 145 to be resistant to Denial-of-Service (DoS) and Man-in-the-middle 146 (MitM) attacks, and when used together with another suitable security 147 protocol, such as Encapsulated Security Payload (ESP) [RFC4303], it 148 provides encryption and/or authentication protection for upper layer 149 protocols such as TCP and UDP, while enabling continuity of 150 communications across network layer address changes. 152 A number of experimental RFC specifications were published by the 153 IETF's HIP Working Group, including the HIP base protocol [RFC5201], 154 ESP encapsulation [RFC5202], registration extensions [RFC5203], HIP 155 rendezvous servers [RFC5204], DNS resource records [RFC5205], and 156 mobility management [RFC5206]. Host identities are represented as 157 ORCHIDs [RFC4853] in Internet protocols. Additionally, the research 158 group published one RFC on requirements for traversing NATs and 159 firewalls [RFC5207] and the working group later published 160 specification text for legacy NAT traversal [RFC5770]. As of this 161 writing, work has commenced on moving the above specifications to 162 Standards Track status. 164 1.2. Terminology 166 The terms used in this document are defined elsewhere in various 167 documents. In particular, readers are suggested to review section 3 168 of [RFC4423] for a listing of HIP-specific terminology. 170 1.3. Scope 172 The research group has been tasked with producing an "experiment 173 report" documenting the collective experiences and lessons learned 174 from other studies, related experimentation, and designs completed by 175 the research group. The question of whether the basic identifier- 176 locator split assumption is valid falls beyond the scope of this 177 research group. When indicated by its studies, the HIP RG can 178 suggest extensions and modifications to the protocol and 179 architecture. It has also been in scope for the RG to study, in a 180 wider sense, what the consequences and effects that wide-scale 181 adoption of any type of separation of the identifier and locator 182 roles of IP addresses is likely to have. 184 During the period of time when the bulk of this report was drafted 185 (2004-2009), several research projects and open source software 186 projects were formed to study HIP. These projects have been 187 developing software enabling HIP to be interoperable according to the 188 experimental RFCs as well as supporting extensions not yet specified 189 by RFCs. 191 The research group has been most active in two areas. First and 192 foremost, the research group has studied extensions to the HIP 193 protocol that went beyond the scope and charter of the IETF HIP 194 working group and the set of RFCs (RFC 5201-5206) initially published 195 in April 2008. Some of this work (NAT traversal, certificate formats 196 for HIP, legacy application support, and a native sockets API for 197 HIP) ultimately flowed into the IETF HIP working group upon its 198 recharter in 2008. Other extensions (e.g. HIP in the i3 overlay, 199 use of distributed hash tables for Host Identity Tag (HIT)-based 200 lookups, mobile router extensions, etc.) are either still being 201 worked on in the research group or have been abandoned. Most of the 202 energy of the research group during this time period has been in 203 studying extensions of HIP protocols or the application of HIP to new 204 problem domains (such as the Internet of Things). Second, the 205 research group has discussed the progress and outcome of the 206 implementations and experiments conducted so far, as well as 207 discussing perspectives from different participants (end users, 208 operators, enterprises) on HIP deployment. It is this latter 209 category of work (and not the extensions to HIP) on which this report 210 is focused. 212 Finally, the research group was chartered to study, but did not 213 rigorously study (due to lack of inputs), the following questions: 215 o Objective comparisons of HIP with other mechanisms (although the 216 research group did hold some discussions concerning the relation 217 of HIP to other efforts such as the End-Middle-End (EME) research 218 group, the Routing research group (RRG) and shim6-based 219 protocols). 221 o Large scale deployments (thousands of hosts or greater). 223 o Exploration of whether introducing an identity-locator mechanism 224 would be architecturally sound, deployed at wide scale. 226 o Changes to the HIP baseline architecture and protocol, or other 227 identity-locator separation architectures. 229 1.4. Organization 231 In this report, we summarize the collective experience of early 232 implementers and adopters of HIP, organized as follows: 234 o Section 2 describes the implications of supporting HIP on an end- 235 host. 237 o Section 3 covers a number of issues regarding the deployment of 238 and interaction with network infrastructure, including middlebox 239 traversal, name resolution, ACLs, and HIP infrastructure such as 240 rendezvous servers. 242 Whereas the two previous sections focus on the implementation and 243 deployment of the network plumbing to make HIP work, the next three 244 focus on the impact on users and operators of the network. 246 o Section 4 examines how the support of HIP in the host and network 247 infrastructure affects applications; whether and how HIP provides 248 benefits or drawbacks to HIP-enabled and legacy applications. 250 o Section 5 provides an operator's perspective on HIP deployment. 252 o Section 6 discusses user privacy issues. 254 In closing, in Section 7, we list the experimental activities and 255 research that have contributed to this report, and in Section 8 we 256 briefly summarize related work. 258 2. Host Stack Implications 260 HIP is primarily an extension to the TCP/IP stack of Internet hosts, 261 and, in this section, we summarize some experiences that several 262 implementation groups have encountered in developing this extension. 263 Our discussion here draws on experience of implementers in adding HIP 264 to general-purpose computing platforms such as laptops, desktops, 265 servers, and PDAs. There are two primary ways to support HIP on such 266 an end host. The first is to make changes to the kernel 267 implementation to directly support the decoupling of identifier and 268 locator. Although this type of modification has data throughput 269 performance benefits, it is also the more challenging to deploy. The 270 second approach is to implement all HIP processing in user-space, and 271 configure the kernel to route packets through user-space for HIP 272 processing. 274 The following public HIP implementations are known and actively 275 maintained: 277 o HIP4BSD (http://www.hip4inter.net)-- FreeBSD kernel modifications 278 and user-space keying daemon; 280 o HIPL (http://hipl.hiit.fi)-- Linux kernel and user-space 281 implementation; 283 o OpenHIP (http://www.openhip.org)-- User-space keying daemon and 284 packet processing for Linux, Windows XP/Vista/7, and Apple OS X. 286 In the following, we first describe issues specific to the way in 287 which HIP is added to a stack, then we discuss general issues 288 surrounding both implementation approaches. 290 2.1. Modifications to TCP/IP stack implementations 292 In this section, we focus on the support of HIP assuming the 293 following: 295 o HIP is implemented by directly changing the TCP/IP stack 296 implementation 298 o Applications (using the sockets API) are unaware of HIP 300 A HIP implementation typically consists of a key management process 301 that coordinates with an IPsec-extended stack, as shown in Figure 1. 302 In practice, HIP has been implemented entirely in user-space, 303 entirely in the kernel, or as a hybrid with a user-space key 304 management process and a kernel-level ESP. 306 +--------------------+ +--------------------+ 307 | | 308 | | 309 | +------------+ | | +------------+ | 310 | | Key | | HIP | | Key | | 311 | | Management | <-+-----------------------+-> | Management | | 312 | | Process | | | | Process | | 313 | +------------+ | | +------------+ | 314 | ^ | | ^ | 315 | | | | | | 316 | v | | v | 317 | +------------+ | | +------------+ | 318 | | IPsec- | | ESP | | IPsec- | | 319 | | extended | | | | extended | | 320 | | Stack | <-+-----------------------+-> | Stack | | 321 | | | | | | | | 322 | +------------+ | | +------------+ | 323 | | | | 324 | | | | 325 | Initiator | | Responder | 326 +--------------------+ +--------------------+ 328 Figure 1: HIP deployment model 330 Figure 2 summarizes the main implementation impact of supporting HIP, 331 and is discussed further in subsequent sections. To enable HIP 332 natively in an implementation requires extensions to the key 333 management interface (here depicted as PF_KEY API [RFC2367]) with the 334 security association database (SAD) and security policy database 335 (SPD). It also requires changes to the ESP implementation itself to 336 support Bound End-to-End Tunnel (BEET)-mode processing 337 [I-D.nikander-esp-beet-mode], extensions to the name resolution 338 library, and (in the future) interactions with transport protocols to 339 respond correctly to mobility and multihoming events 340 [I-D.schuetz-tcpm-tcp-rlci]. 342 |-----------------------| 343 -------- | ---------- ---------- 344 | HIP |-- ----| App v6 | | App v4 | 345 -------- | | ---------- ---------- 346 | | | | HIT | LSI 347 | ------------ | AF_INET6 | AF_INET 348 | | resolver | | | 349 | ------------ | sockets API | user-space 350 --|-------------------|------------------------------- 351 | sockets and | | kernel 352 | PF_KEY API --------- | 353 |-------------> |TCP/UDP|<----------- 354 | --------- 355 | | 356 ---------- --------- 357 | SAD/SPD|<-----> | ESP | {HIT_s, HIT_d} <-> SPI 358 ---------- --------- {HIT_s, HIT_d, SPI} <-> {IP_s,IP_d,SPI} 359 | 360 --------- 361 | IP | 362 --------- 364 Figure 2: Overview of typical implementation changes to support HIP 366 Legacy applications can continue to use the standard AF_INET6 (for 367 IPv6) and AF_INET (for IPv4) socket API. IPv6 applications bind 368 directly to a Host Identity Tag (HIT), which is a part of IPv6 369 address space reserved for ORCHIDs. IPv4 applications bind to a 370 Local Scope Identifier (LSI) that has significance only within a 371 host; the HIP layer translates from LSIs and HITs to the IP addresses 372 that are still used underneath for HIP base exchange. 374 2.1.1. ESP implementation extensions 376 HIP uses a Bound End-to-End Tunnel (BEET) mode of ESP operation, 377 which mixes tunnel-mode semantics with transport-mode syntax. BEET 378 is not supported by all operating system distributions at present, so 379 kernel modifications might be needed to obtain true kernel support 380 using existing IPsec code. At the time of writing, the BEET mode has 381 been adopted to vanilla Linux and FreeBSD kernels. 383 The HIPL project has contributed an IPsec BEET patch for the Linux 384 kernel. The kernel-level support could potentially allow all Linux 385 implementations of HIP to run in the userspace and use a common 386 interface towards the kernel. 388 One inconvenience experienced in current Linux IPsec implementation 389 (due to the native IPsec implementation, not HIP specifically) is a 390 loss of the first data packet that triggers the HIP association 391 establishment. Instead, this packet should be cached and transmitted 392 after the association is established. 394 2.2. User-space implementations 396 HIP can be implemented entirely in user-space, an approach that is 397 essential for supporting HIP on hosts for which operating system 398 modifications are not possible. Even on modifiable operating 399 systems, there is often a significant deployment advantage in 400 deploying HIP only as a user-space implementation. All three open- 401 source implementations provide user-space implementations and binary 402 packages (RPMs, DEBs, self-extracting installers) typical of 403 application deployment on the target systems. 405 When HIP is deployed in user-space, some technique is necessary to 406 identify packets that require HIP processing and divert them to user- 407 space for such processing, and to re-inject them into the stack for 408 further transport protocol processing. A commonly used technique is 409 to deploy a virtual device in the kernel such as a network tap (TAP) 410 device, although operating systems may provide other means for 411 diverting packets to user-space. Routing or packet filtering rules 412 must be applied to divert the right packets to these devices. 414 As an example, the user-space implementation may install a route that 415 directs all packets with destination addresses corresponding to HITs 416 or LSIs to such a virtual device. In the user-space daemon, the ESP 417 header and possibly UDP header is applied, an outer IP address 418 replaces the HIT, and the packet is resent to the kernel. In the 419 reverse direction, a socket associated to ESP or a UDP port number 420 may be used to receive ESP-protected packets. HIP signaling packets 421 themselves may be sent and received by a raw socket bound to the HIP 422 protocol number or UDP port when UDP encapsulation is used. 424 2.3. Issues common to both implementation approaches 426 2.3.1. User-space handling of HITs 428 Much initial experimentation with HIP has involved using HITs 429 directly in IPv6 socket calls, without any resolution infrastructure 430 to learn the HIT based on, for example, a domain name, or to resolve 431 the IP address. To experiment with HIP using HITs requires a priori 432 HIT exchange, in the absence of a resolution service. Manual 433 exchange of HITs has been a major inconvenience for experimentation. 434 It can be overcome via 1) opportunistic HIP mode (RFC5201, Section 435 4.1.6), 2) storing HITs in DNS AAAA entries and looking them up by 436 domain name, 3) name resolution service for HITs such as OpenDHT 437 [I-D.irtf-hiprg-dht], 4) an ad-hoc HIT exchange service to populate 438 files on each machine, or 5) support for DNS extensions described in 439 RFC 5205. 441 Over time, support for these techniques has varied. The HIPL project 442 has experimented with all of them. OpenHIP lacks support for option 443 2), and HIP4BSD lacks support for options 1) and 3). 445 Implementing opportunistic HIP mode in a clean way is challenging, as 446 HITs need to be known when an application binds or connects to a 447 socket. Approach 2) has been difficult in practice due to resistance 448 of sysadmins to include AAAA entries for HITs in the DNS server, and 449 is a non-standards-compliant use of the resource record. Approach 3) 450 is being progressed with two independent implementations of a HIP- 451 OpenDHT interface. At the moment, the easiest way for enabling 452 experimentation appears to be the approach 4) when a shell script 453 based on SSH and SCP can connect to a peer machine and copy HITs to 454 the local configuration files. However, this approach is not 455 scalable or secure for the long run. HIPL developers have had 456 positive experiences with alternative 5). 458 2.3.2. Opportunistic mode 460 In opportunistic mode, the Initiator starts a base exchange without 461 knowledge of the Responder's HIT. The main advantage of the 462 opportunistic mode is that it does not require additional look-up 463 infrastructure for HIs [RFC5205], [I-D.irtf-hiprg-dht]. 465 The opportunistic mode has also a few disadvantages. Firstly, the 466 Initiator may not identify the Responder uniquely just based on the 467 IP address in the presence of private address realms [RFC5770]. 468 Secondly, the Initiator has to settle for a "leap of faith"; that is, 469 assume there is no man in the middle attack. However, this can be 470 partially mitigated by using certificates at the Responder side 471 [RFC6253], or by prompting the user using a graphical interface to 472 explicitly accept the connection [paper.usable-security]. 474 The opportunistic mode requires only minor changes in the state 475 machine of the Responder and small changes for the Initiator 476 [paper.opp]. While the Responder can just select a suitable HIT upon 477 receiving the first HIP base exchange packet (known as an "I1") 478 without a predefined HIT for the Responder, the Initiator should be 479 more careful in processing the first packet from the responder, known 480 as the "R1". For example, the Initiator should make sure that it can 481 disambiguate simultaneously initiated opportunistic base exchanges 482 from each other. 484 In the context of the HIPL project, the opportunistic mode has been 485 successfully applied at the HIP layer for service registration 487 [RFC5203]. HIP4BSD implemented opportunistic mode successfully with 488 small modifications to the FreeBSD socket layer to support 489 opportunistic mode. However, the Linux implementation was more 490 challenging as described below. 492 The HIPL project experimented with opportunistic mode by interposing 493 a shim at two different layers. In the first approach, an API-based 494 shim was implemented to capture socket calls from the application. 495 This was somewhat complicated to implement and required to explicitly 496 enable an individual application (or groups of applications) to use 497 the opportunistic mode. In the second approach 498 [paper.leap-of-faith], the shim was placed between the network and 499 transport layers. Upon successful base exchange, the shim translated 500 IP-based packet flows to HIT-based packet flows by reinjecting the 501 translated packets back to the networking stack. 503 Unless separately disabled, both of the opportunistic mode 504 implementation approaches in HIPL subjected the application(s) to 505 undergo opportunistic mode procedures also for DNS requests. Both 506 approaches also implemented an optional "fall back" to non-HIP base 507 connectivity if the peer did not support HIP. The detection of peer 508 support for HIP was based on timeouts. To avoid timeouts completely 509 and to reduce the delay to a single round-trip time for TCP, the 510 project experimented also with TCP-specific extensions 511 [thesis.bishaj]. 513 The OpenHIP project experimented with opportunistic mode through the 514 use of an opportunistic (-o) option. For the responder, this option 515 determines whether or not HIP accepts I1s received with a zeroed 516 receiver's HIT. On the initiator's side, this option allows one to 517 configure a name and LSI in the known Host Identities file. When the 518 HIT field is missing, an I1 is sent with a zeroed receiver's HIT. 519 The LSI is needed by an IPv4 application to trigger the association. 520 Note that normally the LSI used is based on the bottom 24 bits of the 521 HIT, but in the case of opportunistic mode, the HIT is unknown; thus 522 the LSI may differ from the HIT. 524 As a summary of the opportunistic mode experimentation, it is 525 possibly best suited for HIP-aware applications. Either it can be 526 used by HIP itself in registration extensions or by native HIP 527 applications [RFC6317]. This way, the inherent security trade-offs 528 of the opportunistic are explicitly visible to the user through the 529 HIP-aware application. 531 2.3.3. Resolving HITs to addresses 533 When HIP is used in opportunistic mode, the initiator does not know 534 the responder's HIT but does know its IP address. In most other 535 cases, however, the kernel or applications may know the HITs and not 536 the IP addresses; in this case, an IP address resolution step for 537 HITs must take place. 539 A few techniques have been experimented with. First, OpenDHT can 540 also use HITs as keys for IP address records. Second, work by 541 Ponomarev has shown that the reverse DNS tree may be used for reverse 542 lookups of the ORCHID space [I-D.ponomarev-hip-hit2ip]. Third, the 543 need for resolution may trigger some type of HIP bootstrap message, 544 similar in some sense to an ARP message (to resolve the HIT). The 545 BOS packet used to be present in the early revisions of the HIP base 546 specifications, but was removed from the final specifications due to 547 insufficient interest at the time. The HIPL implementation currently 548 sends an I1 to a link broadcast IP address if it doesn't know the IP 549 address of the peer. It has triggered warnings in some Windows hosts 550 running antivirus software, that classified broadcasts with unknown 551 protocol number as intrusion attempts. The utility of this technique 552 is limited to the local link. 554 2.3.4. IPsec management API extensions 556 A generic key management API for IP security is known as PF_KEY API 557 [RFC2367]. PK_KEY is a socket protocol family that can be used by 558 trusted applications to access the IPsec key engine in the operating 559 system. Users of this interface typically need sysadmin privileges. 561 HIP-related extensions to the PF_KEY interface define a new protocol 562 IPPROTO_HIP. Their main functionality is replacing TCP and UDP 563 checksum with a HIP-compatible checksum (because the transport 564 pseudoheader is based on HITs) in incoming and outgoing packets. 565 Recent Linux kernel versions do not require patching for these 566 extensions. 568 2.3.5. Transport protocol issues 570 When an application triggers a HIP base exchange through the 571 transport protocol, the first data packet can be lost unless the HIP 572 and IPsec implementation is able to buffer the packet until the base 573 exchange completes and IPsec SAs are set up. The loss of the data 574 packet, when it is a TCP SYN packet, results into TCP timeout 575 [RFC2988] that unnecessarily delays the application. A loss of a UDP 576 packet can cause even longer timeouts in applications. Therefore, it 577 was found to be important for HIP implementations to support the 578 buffering of the packet. On the other hand, if the HIP base exchange 579 or UPDATE takes longer than 1 second, which is the case on 580 lightweight devices, a spurious timeout can occur at the transport 581 layer. The HIP implementation could prevent this scenario by 582 manipulating timeout values at the transport layer or, alternatively, 583 drop the original or retransmitted duplicate packet. 585 The multihoming support in [RFC5206] is intended for the purpose of 586 failover, when a host starts using an alternative locator when a 587 current locator fails. However, a host could used this multihoming 588 support for load balancing across different locators. Multihoming in 589 this manner could potentially cause issues with transport protocol 590 congestion control and loss detection mechanisms. However, no 591 experimental results from using HIP multihoming in this capacity have 592 been reported. 594 The use of paths with different characteristics can also impact the 595 estimate of a retransmission timer at the sender's transport layer. 596 TCP uses a smoothed average of the path's Round Trip Time and its 597 variation as the estimate for a retransmission timeout. After the 598 retransmission timer expires, the sender retransmits all outstanding 599 packets in go-back-N fashion. 601 When multihoming is used for simultaneous data transmission from 602 several locators, there can easily be scenarios when the 603 retransmission timeout does not correspond to the actual value. When 604 packets simply experience different RTT, its variation is high, which 605 sets the retransmission timeout value unnecessarily high. When 606 packets are lost, the sender waits excessively long before 607 retransmitting. Fortunately, modern TCP implementations deploying 608 Selective Acknowledgments (SACK) and Limited Transmit are not relying 609 on retransmission timeouts except when most outstanding packets are 610 lost. 612 Load balancing among several paths requires some estimate of each 613 path's capacity. The TCP congestion control algorithm assumes that 614 all packets flow along the same path. To perform load balancing, the 615 HIP layer can attempt to estimate parameters such as delay, 616 bandwidth, and loss rate of each path. A HIP scheduler could then 617 distribute packets among the paths according to their capacity and 618 delay, to maximize overall utilization and minimize reordering. The 619 design of the scheduler is a topic of current research work; none are 620 reported to exist. Different network paths can have different 621 Maximum Transmission Unit (MTU) sizes. Transport protocols perform 622 MTU discovery typically only in the beginning of a connection. As 623 HIP hides mobility from the transport layer, it can happen that 624 packets on the new path get fragmented without knowledge of the 625 transport protocol. To solve this problem, the HIP layer could 626 inform the transport layer of mobility events. Protocols to support 627 such notifications to the transport layer have been proposed to the 628 IETF in the past, including transport triggers 629 [I-D.dawkins-trigtran-framework], lightweight mobility detection and 630 response (LMDR) [I-D.swami-tcp-lmdr], and TCP response to 631 connectivity change [I-D.schuetz-tcpm-tcp-rlci]. 633 2.3.6. Legacy NAT traversal 635 Legacy NAT traversal for outbound-initiated connections to a publicly 636 addressed responder has been implemented by all three HIP 637 implementations; two (HIPL and HIP4BSD) implement ICE techniques 638 [RFC5770] for inbound NAT traversal. It has also been reported that 639 the use of Teredo [RFC4380] over HIP was simpler than the 640 modifications required for ICE techniques because Teredo effectively 641 manifests itself as a routable, virtual locator to system. UDP 642 encapsulation is now the default mode of HIP operation for OpenHIP's 643 IPv4 HIP implementation. Finding an IPv6 NAT implementation for 644 experiments has been difficult. In addition, the initial 645 implementations of NAT traversal for HIP based on ICE techniques 646 proved to be complicated to implement or integrate, and a native NAT 647 traversal mode is now under development for HIP 648 [I-D.ietf-hip-native-nat-traversal]. NAT traversal is expected to be 649 a major mode of HIP operation in the future. 651 2.3.7. Local management of host identity namespace 653 One issue not being addressed by some experimental implementations is 654 how to perform source HIT selection across possibly multiple host 655 identities (some may be unpublished). This is akin to source address 656 selection for transport sockets. How much HIP policy to expose to 657 users is a user interface issue. Default or automatic configuration 658 guesses might have undesirable privacy implications for the user. 660 Helsinki University of Technology (TKK, now Aalto) has implemented an 661 extension of the native HIP API to control multiple host identities 662 [thesis.karlsson]. A problem with Linux routing and multiple 663 identities was discovered by the HIPL development group. As Linux 664 routing is based on longest prefix match, having multiple HITs on 665 virtual devices was problematic from the view point of access control 666 because the stack selects the source HIT based on the destination 667 HIT. A coarse-grained solution for this is to terminate the longest- 668 prefix match for ORCHIDs in the Linux networking statck. However, a 669 more fine-grained solution tries to return a source HIT matching to 670 the algorithm used for generating the destination HIT in order to 671 facilitate compatibility with new algorithms standardized in the 672 future. 674 There are security and privacy issues with storing private keys 675 securely on a host. Current implementations simply store private 676 keys in a file that is readable only by applications with root 677 privileges. This may not be a sufficient level of protection, as 678 keys could be read directly from the disk or e.g. some application 679 with set-user-id flag. Keys may be stored on a trusted platform 680 module (TPM) but there are no reported HIP experiments with such a 681 configuration. In a Boeing pilot project, temporary certificates 682 were generated from a key on a USB SIM chip and used in the HIP base 683 exchange. Use of certificates in HIP requires extensions to the HIP 684 specifications [RFC6253]. Another option is encrypting keys on disks 685 and keeping a passkey in memory (like in SSL certificates on servers, 686 that ask for a password when booting Linux). 688 2.3.8. Interactions with host firewalls 690 HIP is presently an experimental protocol, and some default firewall 691 configuration scripts on popular Linux distributions do not permit 692 the HIP protocol number. Determining which rules to modify without 693 compromising other policies can be tricky; the default rule set on a 694 previous SuSE Linux distribution was discovered to contain over one 695 hundred rules. Moreover, it may be the case that the end user has no 696 control over the firewall settings, if administered by an enterprise 697 IT department. However, the use of HIP over UDP has alleviated some 698 of these concerns. When using HIP over UDP, the firewall needs to 699 allow outbound UDP packets and responses to them. 701 2.4. IPv4 vs. IPv6 issues 703 HIP has been oriented towards IPv6 deployment, but all 704 implementations have also added support for IPv4. HIP supports IPv6 705 applications well, as the HITs are used from the general IPv6 address 706 space using the ORCHID prefix. HITs are statistically unique, 707 although are not routable at the IP layer. Therefore a mapping 708 between HITs and routable IP addresses is necessary at the HIP layer, 709 unless an overlay network or broadcast techniques are available to 710 route packets based on HITs. 712 For IPv4 applications, a 32-bit Local Scope Identifier (LSI) is 713 necessary at the sockets API. The LSI is an alias for a host 714 identity and is only meaningful within one host. Note that an IPv4 715 address may be used as an LSI if it is configured to refer to a 716 particular host identity on a given host, or LSIs may be drawn from 717 an unallocated IPv4 address range, but lack of coordination on the 718 LSI space may hinder implementation portability. 720 HIP makes it possible to use IPv6 applications over the IPv4 network 721 and vice versa. This has been called interfamily operation 722 (flexibility between different address families) and is enabled by 723 the fact that the transport pseudoheader is always based on HITs 724 regardless of whether the application or the underlying network path 725 is based on IPv4. All three open source HIP implementations have 726 demonstrated some form of interfamily handoff support. The 727 interfamily portion of the BEET patch in the Linux kernel was found 728 more difficult to complete compared with the single-family 729 processing. 731 HIP also provides the potential to perform cross-family support, 732 whereby one side of a transport session is IPv6-based, and another is 733 IPv4-based [paper.handovers]. 735 2.5. What have early adopters learned from experience? 737 Implementing HIP in current stacks or as overlays on unmodified 738 stacks has generally been successful. Below are some caveats and 739 open issues. 741 Experimental results comparing kernel vs. userspace HIP 742 implementations in terms of performance and DoS resilience would be 743 useful. If the kernel implementation is shown to perform 744 significantly better than the userspace implementation, it may be a 745 sufficient justification to incorporate HIP within the kernel. 746 However, experiences on general purpose laptops and servers suggests 747 that for typical client use of HIP, user-space implementations 748 perform adequately. 750 Although the HIPL kernel-based keying implementation was submitted to 751 the Linux kernel development process, the implementation was not 752 accepted. The kernel developers felt that since MIP and IKE are 753 implemented as user-space signaling daemons in Linux, that should be 754 the approach for HIP too. Furthermore, the kernel-patch was somewhat 755 big, affecting the kernel in many places and having several 756 databases. The Linux kernel maintainers did eventually accept the 757 BEET patch. 759 Some users have been explicitly asking about co-existence of HIP with 760 other VPN and Mobile IP software. E.g., on Windows those tend to 761 install their own versions of TAP drivers which might conflict with 762 the driver used by the OpenHIP implementation. There may also be 763 issues due to lack of coordination leading to unintended HIP-over-VPN 764 sessions, or lack of coordination of the ESP SPI space. However, 765 these types of conflicts are only speculation and were not reported 766 to the research group; only some positive reports of HIP and VPN 767 software properly coexisting have been reported by the HIPL group. 769 With legacy applications, LSI support is important because IPv6 is 770 not widely used in applications. The main issues in getting 771 applications to work well over HIP have been related to bugs in the 772 implementations themselves, or latency related issues (such as TCP 773 timeouts due to Linux IPsec implementation). There have been no 774 major obstacles encountered in practice, and there has been some 775 experience also in using HIP with native applications [paper.p2psip]. 777 3. Infrastructure Implications 779 This section focuses on the deployment of infrastructure to support 780 HIP hosts. 782 3.1. Impact on DNS 784 HIP DNS extensions [RFC5205] were developed by NEC Eurolabs and 785 contributed to OpenHIP, and were also developed by the HIPL project, 786 both for the BIND9 DNS server. Legacy applications do not query for 787 HIP resource records, but DNS proxies (local resolvers) interpose 788 themselves in the resolution path and can query for HI records. The 789 DNS proxy for HIPL uses binary blob format to store the HIP resource 790 records; this means that no changes to the DNS server are required. 792 There have been no studies reported on the impact of RFC 5205 changes 793 to HIP on the existing DNS. There have been some studies on using 794 DNS to store HITs in the reverse tree [I-D.ponomarev-hip-hit2ip]. 796 3.2. HIP aware middleboxes 798 A design of a HIP registration protocol for architectured NATs (NATs 799 that are HIP aware and use HIP identifiers to distinguish between 800 hosts) has been completed and published as RFC 5204. Performance 801 measurement results with a prototype are available, but 802 experimentation on a wide scale is still missing. RFC 5207 provides 803 a problem statement for HIP-aware NATs and middleboxes [RFC5207]. 805 As argued by Aura et al. [paper.hipanalysis], the encryption of the 806 Initiator Host Identity (HI) prevents policy-based NAT and firewall 807 support, and middlebox authentication, for HIP. The catch is that 808 when the HI is encrypted, middleboxes in the network cannot verify 809 the signature of the second base exchange packet from the initiator 810 (I2) and, thus, cannot safely create a state for the HIP association. 811 On the other hand, if the HI is not encrypted, a stateful middlebox 812 can process the I2 and create protocol state for the session. 814 3.3. HIT resolution infrastructure 816 OpenDHT HIT-to-IP address resolution has been implemented by Aalborg 817 University, Denmark, Helsinki Institute for Information Technology 818 for HIPL, and by Boeing for OpenHIP [I-D.irtf-hiprg-dht]. 820 The prototype of the Host Identity Indirection Infrastructure (Hi3) 821 has been implemented using OpenHIP and HIPL. A set of 25 i3 servers 822 was running on PlanetLab for several years. While a PlanetLab 823 account is required to run the servers, anybody could openly use the 824 provided service. 826 The main idea of Hi3 is to transmit HIP control packets using the i3 827 system as a lookup and rendezvous service, while transmitting data 828 packets efficiently end-to-end using IPsec. Performance measurements 829 were conducted comparing the association setup latency, throughput, 830 and RTT of Hi3 with plain IP, HIP and i3 [paper.hi3] 832 One difficulty has been with debugging the i3 system. In some cases 833 the messages did not traverse i3 correctly; due to its distributed 834 nature and lack of tracing tools, making the system work has been 835 challenging. Further, since the original research work was done, the 836 i3 servers have gone offline. 838 NATs and firewalls have been a major disturbance in Hi3 experiments. 839 Many networks did not allow incoming UDP packets to go through, 840 therefore, preventing messages from i3 servers to reach the client. 842 So far the Hi3 system has been evaluated on a larger scale only 843 analytically. The problem is that running a larger number of clients 844 to create a sufficient load for the server is difficult. A cluster 845 on the order of a hundred Linux servers is needed for this purpose. 846 Contacts to a State Supercomputer Centre in Finland have not been 847 successful so far. A possible opportunity is to use one of existing 848 Emulab installations, e.g. in Utah for these tests. 850 3.4. Rendezvous servers 852 A rendezvous server (RVS) [RFC5204] has been implemented by HIIT for 853 HIPL, and an implementation also exists for OpenHIP. The concept has 854 been extended to a relay server in [RFC5770]. Initial 855 experimentation with the HIPL implementation produced the following 856 observations. 858 o RVS may be better than dynamic DNS updates for hosts that change 859 their address rapidly. 861 o Registration of a HIP host to RVS costs a base exchange. 863 o Sending of UPDATE and CLOSE packets through rendezvous servers is 864 advised; RVS handling of UPDATE messages can typically solve the 865 double jump [I-D.huitema-multi-homed] mobility problem. 867 The following advanced concepts need further study. 869 o Multiple RVS per host for fault tolerance (e.g. one rendezvous 870 node crashes), and an algorithm for selecting the best RVS. 872 o Load balancing. A RVS server could distribute I1s to different 873 responders if the responder's identity is shared or opportunistic 874 HIP is used. 876 o Offering a rendezvous service in a P2P fashion by HIP hosts. 878 3.5. Hybrid DNS-DHT resolution 880 In addition to pure DNS and pure DHT HIP name resolution, a hybrid 881 approach combining standard DNS interface for clients with last-hop 882 DHT resolution was developed. The idea is that the benefits of DNS 883 solution (wide deployment, support for legacy applications) could be 884 combined with advantages of DHT (fault tolerance, efficiency in 885 handling flat data keys). The DHT is typically run internally by the 886 organization managing the last-hop DNS zone and the DNS server. That 887 way, the HITs belonging to that organization could be stored locally 888 by the organization that improves deployability of the resolution 889 system. However, organizations could also share a DHT between 890 themselves, or connect their DNS servers to a publicly available DHT, 891 such as OpenDHT. The benefit of running a DHT on a local server 892 cluster compared to a geographically spread DHT is also higher 893 performance due to decreased internal DHT latencies. 895 The system was prototyped by modifying the BIND DNS server to 896 redirect the queries for HITs to a DHT server. The interface was 897 implemented in XML according to specifications [I-D.irtf-hiprg-dht]. 898 The system is completely backward compatible to legacy applications 899 since the standard DNS resolver interface is used. 901 Performance of the system was evaluated by performing a rapid 902 sequence of requests for querying and updating the HIT to IP address 903 mapping. The request rate was varied from 1 to 200 requests per 904 second. The average latency of one query request was less than 50 ms 905 and the secured updated latency less than 100 ms with a low request 906 rate. However, the delay was increasing exponentially with the 907 request rate, reaching 1 sec for 200 requests per second (update rate 908 0) and almost 2 sec (update rate 0.5). Furthermore, the maximum 909 delay exceeded the mean by several times. 911 Based on experiments, a multi-processor system could handle more than 912 1000 queries per second. The latencies are dominated by the DHT 913 resolution delay, and the DNS component is rather small. This is 914 explained by the relative inefficiency of used DHT implementation 915 (Bamboo) and could be definitely improved in future. 917 4. Application Implications 919 In a deployed HIP environment, applications may be HIP-aware or HIP- 920 unaware. RFC5338 [RFC5338] describes various techniques to allow HIP 921 to support unmodified applications. Below are listed some additional 922 application considerations. 924 4.1. Non-intrusive HIP insertion 926 One way to support legacy applications that use dynamic linking is to 927 dynamically interpose a modified resolver library. Using HIPL, 928 several legacy applications were shown to work without changes using 929 dynamic re-linking of the resolver library. For example, Firefox web 930 browser successfully worked with an Apache web server. The re- 931 linking just requires configuring a LD_PRELOAD system variable that 932 can be performed in a user shell profile file or as a start-up 933 wrapper for an application. This provides the user with fine-grained 934 policy control over which applications use HIP, which could 935 alternately be considered a benefit or a drawback depending on 936 whether the user is burdened with such policy choices. The technique 937 was also found to be sensitive to loading LD_PRELOAD twice, in which 938 case the order of linking dynamic libraries must be coded carefully. 940 Another method for transparently using HIP, which has no reported 941 implementation experience, is via local application proxies (e.g. 942 squid web proxy) that are modified to be HIP-aware. Discussion of 943 proxies for HIP is a current focus of research group activities 944 [I-D.irtf-hiprg-proxies]. 946 4.2. Referrals 948 A concern that FTP would not work due to the problem of application 949 referrals, i.e. passing the IP address within application messages, 950 was discovered not to be a problem for FTP in practice. It is shown 951 to work well both in the passive and active modes [paper.namespace]. 952 It remains an open question how big problem referrals really are in 953 the practice. At least, they do not seem used for the client side 954 because they are behind NATs, and, therefore, client addresses are 955 unsuitable as referrals. 957 4.3. Latency 959 Some applications may be sensitive to additional RTTs or processing 960 due to HIP resolutions or the protocol itself. For instance, page 961 load speed for web browsers is a critical metric for browser 962 designers. Some applications or deployments may not wish to trade 963 application speed for the security and mobility management that HIP 964 offers. 966 5. Network Operator's Perspective 968 There is no known deployment of HIP by a data service provider. 969 However, some issues regarding HIP have been brought to the HIP 970 research group by a network provider and are summarized below and in 971 [I-D.dietz-hip-operator-issues]. 973 5.1. Management of the host identity namespace 975 When a network operator deploys HIP for its customers, several issues 976 with management of host identities arise. The operator may prefer to 977 generate the host identity itself rather than let each host create 978 the identities. Several factors can create such a need. Public- 979 private key generation is a demanding operation that can take tens of 980 seconds on a lightweight device, such as a mobile phone. After 981 generating a host identity, the operator can immediately insert it 982 into its own AAA databases and network firewalls. This way, the 983 users would not need to be concerned with technical details of host 984 identity management. 986 The operator may use a Public Key Infrastructure (PKI) to certify 987 host identities of its customers. Then, it uses the private key of 988 operator's Certificate Authority (CA) to sign the public key of its 989 customers. This way, third parties possessing the public key of the 990 CA can verify the customer's host identity and use this information 991 e.g. for admission control to infrastructure. Such practice raises 992 the security level of HIP when self-generated host identities are 993 used. 995 When the operator is using neither PKI nor DNSSEC host names, the 996 problem of securely exchanging host identities remains. When HIP is 997 used in opportunistic mode, a man-in-the-middle can still intercept 998 the exchange and replace the host identities with its own. For 999 instance, the signaling provided by the SIP protocol could be used to 1000 deliver host identities if it were secured by existing mechanisms in 1001 operator's network. 1003 5.2. Use of ESP encryption 1005 The research group has discussed whether operators can provide 1006 "value-added" services and priority, and comply with wiretapping 1007 laws, if all sessions are encrypted. This is not so much a HIP issue 1008 as a general end-to-end encryption issue. 1010 The processing power of mobile devices also must be considered. One 1011 study evaluated the use of HIP and ESP on lightweight devices (Nokia 1012 N770 Internet Tablets having 200 MHz processors) [paper.mobiarch]. 1013 The overhead of using ESP on such platform was found to be tolerable, 1014 about 30% in terms of throughput. With a bulk TCP transfer over 1015 WiFi, transfer without HIP was producing 4.86 Mbps, while over ESP 1016 security associations set up by HIP it was 3.27 Mbps. A lightweight 1017 HIP base exchange for this purpose is being developed at the time of 1018 this writing [I-D.moskowitz-hip-rg-dex]. 1020 It is also possible to use HIP in a NULL encryption configuration if 1021 one of SHA1 or MD5 authentication are used. 1023 5.3. Access control lists based on HITs 1025 A firewall typically separates an organization's network from the 1026 rest of the Internet. An Access Control List (ACL) specifies packet 1027 forwarding policies in the firewall. Current firewalls can filter 1028 out packets based on IP addresses, transport protocol, and port 1029 values. These values are often unprotected in data packets and can 1030 be spoofed by an attacker. By trying out common well-known ports and 1031 a range of IP addresses, an attacker can often penetrate the firewall 1032 defenses. 1034 Furthermore, legacy firewalls often disallow IPsec traffic and drop 1035 HIP control packets. HIP allows ACLs to be protected based on packet 1036 exchanges that may be authenticated by middleboxes. However, HITs 1037 are not aggregatable, so HIT-based ACLs may be longer in length (due 1038 to inability to group hosts with a single entry) and harder to deal 1039 with by human users (due to the length of the HIT compared with an 1040 IPv4 or IPv6 prefix)). 1042 Additionally, operators would like to grant access to the clients 1043 from domains such as example.com regardless of their current locators 1044 or HITs. This is difficult without a forward confirmed reverse DNS 1045 to use for non-repudiation purposes. 1047 5.4. Firewall issues 1049 Helsinki University of Technology (TKK, now Aalto) has implemented a 1050 HIP firewall based on Linux iptables [thesis.vehmersalo] which 1051 operates in userspace. 1053 In general, firewalls can be stateless, filtering packets based only 1054 on the ACL, and stateful, which can follow and remember packet flows. 1055 Stateless firewalls are simple to implement but provide only coarse- 1056 grained protection. However, their performance can be efficient 1057 since packet processing requires little memory or CPU resources. A 1058 stateful firewall determines if a packet belongs to an existing flow 1059 or starts a new flow. A flow identifier combines information from 1060 several protocol headers to classify packets. A firewall removes the 1061 state when the flow terminates (e.g., a TCP connection is closed) or 1062 after a timeout. A firewall can drop suspicious packets that fail a 1063 checksum or contain sequence numbers outside of the current sliding 1064 window. 1066 A transparent firewall does not require that hosts within the 1067 protected network register or even know of the existence of the 1068 firewall. An explicit firewall requires registration and 1069 authentication of the hosts. 1071 A HIP-aware firewall operating in the middle identifies flows using 1072 HITs of communicating hosts, as well as SPI values and IP addresses. 1073 The firewall must link together the HIP base exchange and subsequent 1074 IPsec ESP data packets. During the base exchange, the firewall 1075 learns the SPI values from I2 and R2 packets. Then, the firewall 1076 only allows ESP packets with a known SPI value and arriving from the 1077 same IP address as during the base exchange. If the host changes its 1078 location and the IP address, the firewall, if still on the path, 1079 learns about the changes by following the mobility update packets. 1081 It is possible to implement a stateless, end-host-based firewall to 1082 reuse existing higher-layer mechanisms such as access control lists 1083 in the system. In this mode of operation, HITs would be used in the 1084 access control lists, and while the base exchange might complete, ESP 1085 is not passed to the transport layer unless the HITs are allowed in 1086 the access control list. 1088 A HIP host can register to an explicit firewall using the usual 1089 procedure [RFC5203]. The registration enables the host and the 1090 firewall to authenticate each other. In a common case, where the 1091 Initiator and Responder hosts are located behind different firewalls, 1092 the Initiator may need to first register with its own firewall, and 1093 afterward, with the Responder's firewall. 1095 Some researchers have suggested that a firewall for security-critical 1096 environments should get involved in the base exchange and UPDATE 1097 procedures with middlebox-injected echo requests. Otherwise, the 1098 firewall can be circumvented with replay attacks if there is a 1099 compromised node within the network that the firewall is trying to 1100 protect [I-D.heer-hip-middle-auth]. 1102 6. User Privacy Issues 1104 Using public keys for identifying hosts creates a privacy problem as 1105 third parties can determine the source host even if attached to a 1106 different location in the network. Various transactions of the host 1107 could be linked together if the host uses the same public key. 1108 Furthermore, using a static IP address also allows linking of 1109 transactions of the host. Multiplexing multiple hosts behind a 1110 single NAT or using short address leases from DHCP can reduce the 1111 problem of user tracking. However, IPv6 addresses could reduce the 1112 occurrence of NAT translation and cause additional privacy issues 1113 related to the use of MAC addresses in IPv6 address 1114 autoconfiguration. HIP does provide for the use of anonymous 1115 (unpublished) HITs in cases in which the initiator prefers to remain 1116 anonymous, but the responder must be willing to accept sessions from 1117 anonymous peers. 1119 With mutual authentication, the HIP initiator should not have to 1120 reveal its identity (public key) to either a passive adversary or an 1121 active attacker. The HIP initiator can authenticate the responder's 1122 R1 packet before encrypting its host identity with the Diffie 1123 Hellman-generated keying material and sending it in the I2 packet. 1124 The authentication step upon receiving an R1 defeats the active 1125 attacker (impersonator) of the responder, and the act of encrypting 1126 the identity defeats the passive adversary. Since the Responder 1127 sends its public key unencrypted in the first reply message (R1) to 1128 the Initiator, the Responder's identity will be revealed to third 1129 party on-path eavesdroppers. However, if the Responder authenticates 1130 the Initiator and performs access controls before sending the R1, the 1131 Responder can avoid disclosing its public key to an active attacker. 1133 DNS records can provide information combining host identity and 1134 location information, the host public key, and host IP address. 1135 Therefore, identity and location privacy are related and should be 1136 treated in an integrated approach. The goal of the BLIND is to 1137 provide a framework for identity and location privacy [paper.blind], 1138 [I-D.zhang-hip-privacy-protection]. The identity protection is 1139 achieved by hiding the actual public keys from third parties so that 1140 only the trusted hosts can recognize the keys. Location privacy is 1141 achieved by integrating traffic forwarding with NAT translation and 1142 decoupling host identities from locators. The use of random IP and 1143 MAC addresses also reduces the issue of location privacy shifting the 1144 focus to protecting host identifiers from third parties. This 1145 approach is, by its very nature, incompatible with middlebox 1146 authentication. 1148 To prevent revealing the identity, the host public key and its hash 1149 (HIT) can be encrypted with a secret key known beforehand to both 1150 Initiator and Responder. However, this is a requirement that cannot 1151 be easily implemented in practice. The BLIND framework provides 1152 protection from active and passive attackers using a modified HIP 1153 base exchange. If the host avoids storing its public keys in the 1154 reverse DNS or DHT repository, the framework achieves full location 1155 and identity privacy. 1157 An alternative approach to reducing privacy threats of persistent 1158 identifiers is to replace them with short-lived identifiers that are 1159 changed regularly to prevent user tracking. Furthermore, identifiers 1160 must be changed simultaneously at all protocol layers, or otherwise 1161 an adversary could still link the new identifier by looking at an 1162 identifier at another protocol layer that remained the same after the 1163 change. The HIP privacy architecture that simultaneously changes 1164 identifiers on MAC, IP, and HIP/IPsec layers was developed at 1165 Helsinki University of Technology (TKK, now Aalto) [thesis.takkinen]. 1166 HIP could be extended in the future to allow active sessions to 1167 migrate identities. 1169 7. Experimental Basis of this Report 1171 This report is derived from reported experiences and research results 1172 of early adopters, implementers, and research activities. In 1173 particular, a number of implementations have been in development 1174 since 2002 (Section 2). 1176 One production-level deployment of HIP has been reported. Boeing has 1177 described how it uses HIP to build layer-2 VPNs over untrusted 1178 wireless networks [I-D.henderson-hip-vpls]. This use case is not a 1179 traditional end-host-based use of HIP but rather is one that uses 1180 HIP-aware middleboxes to create ESP tunnels on-demand between 1181 provider-edge (PE) devices. 1183 The InfraHIP II project is deploying HIP infrastructure (test 1184 servers, rendezvous and relay servers) in the public Internet. 1186 The following is a possibly incomplete list of past and current 1187 research activities related to HIP. 1189 o Boeing Research & Technology (T. Henderson, J. Ahrenholz, J. 1190 Meegan. OpenHIP implementation, Secure Mobile Architecture) 1192 o NomadicLab, Ericsson (P. Jokela, P. Nikander, J. Melen. BSD HIP 1193 implementation) 1195 o Helsinki Institute for Information Technology (HIIT) (A. Gurtov, 1196 M. Komu, A. Pathak, D. Beltrami. HIPL, legacy NAT traversal, 1197 firewall, i3, native API) 1199 o Helsinki University of Technology (TKK, now Aalto) (Janne 1200 Lindqvist, Niklas Karlsson, Laura Takkinen, and Essi Vehmersalo. 1201 HIP security and firewalls, multiple identities, and privacy 1202 management) 1204 o University of California, Berkeley (D. Joseph, HIP proxy 1205 implementation) 1207 o Laboratory of Computer Architecture and Networks, Polytechnic 1208 School of University of Sao Paulo, Brazil (T. Carvalho, HIP 1209 measurements, Hi3) 1211 o Telecom Italia (M. Morelli, comparing existing HIP 1212 implementations) 1214 o NEC Heidelberg (L. Eggert, M. Esteban, V. Schmitt working on RVS 1215 implementation, DNS, NAT traversal) 1217 o University of Hamburg-Harburg (M. Shanmugam, A. Nagarajan, HIP 1218 registration protocol) 1220 o University of Tuebingen (K. Wehrle, T. Lebenslauf to work on Hi3 1221 or HIP-OpenDHT) 1223 o University of Parma (UNIPR), Department of Information Engineering 1224 Parma, Italy. N. Fedotova (HIP for P2P) 1226 o Siemens (H. Tschofenig, HIP middleboxes) 1228 o Denmark (Aalborg University, Lars Roost, Gustav Haraldsson, Per 1229 Toft, HIP evaluation project, OpenDHT-HIP interface) 1231 o Microsoft Research, Cambridge (T. Aura, HIP analysis) 1233 o MIT (H. Balakrishnan. Delegation-Oriented Architecture) 1235 o Huawei, hierarchical HIP architecture, HIP proxy, key revocation 1236 (D. Zhang, X. Xu) 1238 8. Related Work on ID-Locator Split 1240 This section briefly summarizes the related work on ID-locator split 1241 with particular focus on recent IETF and IRTF activity. In the 1242 academic research community, several related proposals were explored 1243 prior to the founding of this research group, such as the Internet 1244 Indirection Infrastructure (i3) [paper.i3], IPNL [paper.layered], 1245 DataRouter [paper.datarouter], Network Pointers [paper.netpointers], 1246 FARA [paper.fara], and TRIAD [paper.triad]. 1248 The topic of whether a new name space is needed for the Internet has 1249 been controversial. The Name Space Research Group (NSRG) at the IRTF 1250 was not able to reach consensus on the issue, nor even to publish a 1251 final report. Yet, there seems to be little disagreement that, for 1252 many scenarios, some level of indirection from network name to 1253 network location is essential or highly desirable to provide adequate 1254 service. Mobile IP [RFC3775] is one example that reuses an existing 1255 name space for host naming. Since Mobile IP was finalized, many new 1256 variants to providing this indirection have been suggested. Even 1257 prior to Mobile IP, the IETF has published informational documents 1258 describing architectures separating network name and location, 1259 including the work of Jerome Saltzer [RFC1498], and Nimrod [RFC1992]. 1261 Most recently, there has been standardization and development efforts 1262 in the IETF and IRTF as follows: 1264 o The Site Multihoming in IPv6 (multi6) WG documented the ways that 1265 multihoming is currently implemented in IPv4 networks and 1266 evaluated several approaches for advanced multihoming. The 1267 security threats and impact on transport protocols were covered 1268 during the evaluation. The work continued in another WG, Site 1269 Multihoming by IPv6 Intermediation (shim6), which focusing on 1270 specifications of one selected approach [RFC5533]. shim6 uses the 1271 approach of inserting a shim layer between the IP and the 1272 transport layers that hides effects of changes in the set of 1273 available addresses. The applications are using one active 1274 address that supports referrals. Shim6 relies on 1275 cryptographically generated IPv6 addresses to solve the address 1276 ownership problem. HIP and shim6 are architecturally similar and 1277 use a common format for control packets. HIP specifications 1278 define only simple multihoming scenarios leaving such important 1279 issues as interface selection untouched. Shim6 offers 1280 complementary functionality that can be be reused in HIP 1281 [I-D.oliva-hiprg-reap4hip]. The OpenHIP implementation integrates 1282 HIP and shim6 protocols in the same framework, with the goal of 1283 allowing HIP to reuse the shim6 failure detection protocol. 1284 Furthermore, HIP and shim6 socket APIs have been jointly designed 1285 [RFC6317] [RFC6316]. 1287 o The IRTF Routing Research Group (RRG) has explored a class of 1288 solutions to the global routing scalability problem that involve 1289 either separation of the existing IP address space into those used 1290 for identifiers and locators as in LISP ([I-D.ietf-lisp]) and Six/ 1291 One Router ([I-D.vogt-rrg-six-one]), and those advocating a fuller 1292 separation of these roles including ILNP ([I-D.rja-ilnp-intro]), 1293 and RANGI ([I-D.xu-rangi]). 1295 o The End-Middle-End research group considered the potential for an 1296 explicit signaling and policy control plane for middleboxes and 1297 endpoints [I-D.irtf-eme-francis-nutss-design], and at a joint 1298 meeting at IETF 69, the HIP and EME research groups discussed 1299 whether the EME framework could help HIP with middlebox traversal. 1301 o The IETF Multipath TCP working group is developing mechanisms to 1302 simultaneously use multiple paths in a regular TCP session. The 1303 MPTCP solution aims to solve the multihoming problem also 1304 addressed by HIP but by solving it for TCP specifically. 1306 o The Unmanaged Internet Protocol bears several similarities to the 1307 HIP architecture, such as the focus on identifiers that are not 1308 centrally managed that are also based on a cryptographic hash of a 1309 node's public key [thesis.ford]. 1311 o Apple Back To My Mac service provides secure connections between 1312 hosts using IPsec between a pair of host identifiers. However, 1313 the host identifier is reported to be an IPv6 ULA address rather 1314 than a HIP identifier [RFC6281] 1316 Although the HIP research group has not formally tried to compare HIP 1317 with other ID-locator split approaches, such discussions have 1318 occurred on other lists such as the Routing research group mailing 1319 list, and a comparison of HIP's mobility management solution with 1320 other approaches was published in [I-D.thaler-mobility-comparison]. 1322 9. Security Considerations 1324 This document is an informational survey of HIP-related research and 1325 experience. Space precludes a full accounting of all security issues 1326 associated with the approaches surveyed here, but the individually 1327 referenced documents may discuss security considerations for their 1328 respective protocol component. HIP security considerations for the 1329 base HIP protocol can be found in Section 8 of [RFC5201]. 1331 10. IANA Considerations 1333 This document has no actions for IANA. 1335 11. Acknowledgments 1337 Miika Komu, Pekka Nikander, Ari Keranen, and Jeff Ahrenholz have 1338 provided helpful comments on earlier versions of this draft. Miika 1339 Komu also contributed the section on opportunistic mode. We also 1340 thank Dacheng Zhang for contributions on hierarchical HIP 1341 architectures, and the Crypto Forum Research Group (Adam Back and 1342 Paul Hoffman) for clarification of Diffie Hellman privacy properties. 1344 12. Informative References 1346 [RFC2988] Paxson, V. and M. Allman, "Computing TCP's Retransmission 1347 Timer", RFC 2988, November 2000. 1349 [RFC4423] Moskowitz, R. and P. Nikander, "Host Identity Protocol 1350 (HIP) Architecture", RFC 4423, May 2006. 1352 [RFC5201] Moskowitz, R., Nikander, P., Jokela, P., and T. Henderson, 1353 "Host Identity Protocol", RFC 5201, April 2008. 1355 [RFC5202] Jokela, P., Moskowitz, R., and P. Nikander, "Using the 1356 Encapsulating Security Payload (ESP) Transport Format with 1357 the Host Identity Protocol (HIP)", RFC 5202, April 2008. 1359 [RFC5203] Laganier, J., Koponen, T., and L. Eggert, "Host Identity 1360 Protocol (HIP) Registration Extension", RFC 5203, 1361 April 2008. 1363 [RFC5204] Laganier, J. and L. Eggert, "Host Identity Protocol (HIP) 1364 Rendezvous Extension", RFC 5204, April 2008. 1366 [RFC5205] Nikander, P. and J. Laganier, "Host Identity Protocol 1367 (HIP) Domain Name System (DNS) Extensions", RFC 5205, 1368 April 2008. 1370 [RFC5206] Nikander, P., Henderson, T., Vogt, C., and J. Arkko, "End- 1371 Host Mobility and Multihoming with the Host Identity 1372 Protocol", RFC 5206, April 2008. 1374 [RFC5207] Stiemerling, M., Quittek, J., and L. Eggert, "NAT and 1375 Firewall Traversal Issues of Host Identity Protocol (HIP) 1376 Communication", RFC 5207, April 2008. 1378 [RFC5770] Komu, M., Henderson, T., Tschofenig, H., Melen, J., and A. 1379 Keranen, "Basic Host Identity Protocol (HIP) Extensions 1380 for Traversal of Network Address Translators", RFC 5770, 1381 April 2010. 1383 [RFC4380] Huitema, C., "Teredo: Tunneling IPv6 over UDP through 1384 Network Address Translations (NATs)", RFC 4380, 1385 February 2006. 1387 [RFC4853] Housley, R., "Cryptographic Message Syntax (CMS) Multiple 1388 Signer Clarification", RFC 4853, April 2007. 1390 [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", 1391 RFC 4303, December 2005. 1393 [RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support 1394 in IPv6", RFC 3775, June 2004. 1396 [RFC1498] Saltzer, J., "On the Naming and Binding of Network 1397 Destinations", RFC 1498, August 1993. 1399 [RFC1992] Castineyra, I., Chiappa, N., and M. Steenstrup, "The 1400 Nimrod Routing Architecture", RFC 1992, August 1996. 1402 [RFC2367] McDonald, D., Metz, C., and B. Phan, "PF_KEY Key 1403 Management API, Version 2", RFC 2367, July 1998. 1405 [RFC5338] Henderson, T., Nikander, P., and M. Komu, "Using the Host 1406 Identity Protocol with Legacy Applications", RFC 5338, 1407 September 2008. 1409 [RFC5533] Nordmark, E. and M. Bagnulo, "Shim6: Level 3 Multihoming 1410 Shim Protocol for IPv6", RFC 5533, June 2009. 1412 [RFC6253] Heer, T. and S. Varjonen, "Host Identity Protocol 1413 Certificates", RFC 6253, May 2011. 1415 [RFC6281] Cheshire, S., Zhu, Z., Wakikawa, R., and L. Zhang, 1416 "Understanding Apple's Back to My Mac (BTMM) Service", 1417 RFC 6281, June 2011. 1419 [RFC6316] Komu, M., Bagnulo, M., Slavov, K., and S. Sugimoto, 1420 "Sockets Application Program Interface (API) for 1421 Multihoming Shim", RFC 6316, July 2011. 1423 [RFC6317] Komu, M. and T. Henderson, "Basic Socket Interface 1424 Extensions for the Host Identity Protocol (HIP)", 1425 RFC 6317, July 2011. 1427 [paper.i3] 1428 Stoica, I., Adkins, D., Zhuang, S., Shenker, S., and S. 1429 Surana, "Internet Indirection Infrastructure (i3)", 1430 Proceedings of ACM SIGCOMM, August 2002. 1432 [paper.layered] 1433 Balakrishnan, H., Lakshminarayanan, K., Ratnasamy, S., 1434 Shenker, S., Stoica, I., and M. Walfish, "A Layered Naming 1435 Architecture for the Internet", Proceedings of ACM 1436 SIGCOMM, August 2004. 1438 [paper.datarouter] 1439 Touch, J. and V. Pingali, "DataRouter: A Network-Layer 1440 Service for Application-Layer Forwarding", Proceedings of 1441 International Workshop on Active Networks (IWAN), 1442 December 2003. 1444 [paper.netpointers] 1445 Tschudin, C. and R. Gold, "Network Pointers", ACM 1446 Computer Communications Review, January 2003. 1448 [paper.fara] 1449 Clark, D., Braden, R., Falk, A., and V. Pingali, "FARA: 1450 Reorganizing the Addressing Architecture", Proceedings of 1451 ACM SIGCOMM FDNA Workshop, August 2003. 1453 [paper.triad] 1454 Cheriton, D. and M. Gritter, "TRIAD: A New Next- 1455 Generation Internet Architecture", Unpublished, available 1456 at Citeseer, July 2000. 1458 [paper.blind] 1459 "BLIND: A Complete Identity Protection Framework for End- 1460 points", Proc. of the Twelfth International Workshop on 1461 Security Protocols, April 2004. 1463 [paper.usable-security] 1464 "Usable Security Management with Host Identity Protocol", 1465 Proc. of the IEEE/ACS International Conference on 1466 Computer Systems and Applications, May 2009. 1468 [paper.opp] 1469 "Leap-of-Faith Security is Enough for IP Mobility", Proc. 1470 of the Sixth IEEE Conference on Consumer Communications 1471 and Networking Conference, January 2009. 1473 [paper.hipanalysis] 1474 Aura, T., Nagarajan, A., and A. Gurtov, "Analysis of the 1475 HIP Base Exchange Protocol", Proc. of the 10th 1476 Australasian Conference on Information Security and 1477 Privacy (ACISP), July 2005. 1479 [paper.namespace] 1480 Komu, M., Tarkoma, S., Kangasharju, J., and A. Gurtov, 1481 "Applying a Cryptographic Namespace to Applications", 1482 Proc. of First International ACM Workshop on Dynamic 1483 Interconnection of Networks, September 2005. 1485 [paper.mobiarch] 1486 Khurri, A., Vorobyeva, E., and A. Gurtov, "Performance of 1487 Host Identity Protocol on Lightweight Hardware", 1488 Proceedings of ACM MobiArch, August 2007. 1490 [paper.hi3] 1491 Gurtov, A., Korzon, D., Lukyanenko, A., and P. Nikander, 1492 "Hi3: An Efficient and Secure Networking Architecture for 1493 Mobile Hosts", Unpublished, available at Citeseer, 1494 June 2008. 1496 [paper.p2psip] 1497 Koskela, J., Heikkila, J., and A. Gurtov, "A secure P2P 1498 SIP system with SPAM prevention", ACM Mobile Computer 1499 Communications Review, July 2009. 1501 [paper.handovers] 1502 Varjonen, S., Komu, M., and A. Gurtov, "Secure and 1503 Efficient IPv4/IPv6 Handovers Using Host-Based 1504 Identifier-Locator Split", Proceedings of the 17th 1505 International Conference Software, Telecommunications, 1506 and Computer Networks, September 2009. 1508 [paper.leap-of-faith] 1509 Komu, M. and J. Lindqvist, "Leap-of-faith security is 1510 enough for IP mobility", Proceedings of the 6th IEEE 1511 Conference on Consumer Communications and Networking 1512 Conference (CCNC 09), 2009. 1514 [thesis.takkinen] 1515 Takkinen, L., "Host Identity Protocol Privacy Management", 1516 Master thesis, TKK, March 2006. 1518 [thesis.vehmersalo] 1519 Vehmersalo, E., "Host Identity Protocol Enabled Firewall: 1520 A Prototype Implementation and Analysis", Master thesis, 1521 TKK, September 2005. 1523 [thesis.karlsson] 1524 Karlsson, N., "Enabling Multiple Host Identities on 1525 Linux", Master thesis, Helsinki University of Technology, 1526 September 2005. 1528 [thesis.ford] 1529 Ford, B., "UIA: A Global Connectivity Architecture for 1530 Mobile Personal Devices", Doctoral thesis, Massachusetts 1531 Institute of Technology, September 2008. 1533 [thesis.bishaj] 1534 Bishaj, B., "Efficient Leap of Faith Security with Host 1535 Identity Protocol", Master thesis, Helsinki University of 1536 Technology, June 2008. 1538 [I-D.nikander-esp-beet-mode] 1539 Melen, J. and P. Nikander, "A Bound End-to-End Tunnel 1540 (BEET) mode for ESP", draft-nikander-esp-beet-mode-09 1541 (work in progress), August 2008. 1543 [I-D.ietf-hip-native-nat-traversal] 1544 Keranen, A. and J. Melen, "Native NAT Traversal Mode for 1545 the Host Identity Protocol", 1546 draft-ietf-hip-native-nat-traversal-01 (work in progress), 1547 January 2011. 1549 [I-D.vogt-rrg-six-one] 1550 Vogt, C., "Six/One: A Solution for Routing and Addressing 1551 in IPv6", draft-vogt-rrg-six-one-02 (work in progress), 1552 October 2009. 1554 [I-D.irtf-eme-francis-nutss-design] 1555 Francis, P., "An EME Signaling Protocol Design", 1556 draft-irtf-eme-francis-nutss-design-00 (work in progress), 1557 April 2007. 1559 [I-D.ponomarev-hip-hit2ip] 1560 Ponomarev, O. and A. Gurtov, "Embedding Host Identity Tags 1561 Data in DNS", draft-ponomarev-hip-hit2ip-04 (work in 1562 progress), July 2009. 1564 [I-D.xu-rangi] 1565 Xu, X., "Routing Architecture for the Next Generation 1566 Internet (RANGI)", draft-xu-rangi-04 (work in progress), 1567 August 2010. 1569 [I-D.rja-ilnp-intro] 1570 Atkinson, R., "ILNP Concept of Operations", 1571 draft-rja-ilnp-intro-11 (work in progress), July 2011. 1573 [I-D.ietf-lisp] 1574 Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, 1575 "Locator/ID Separation Protocol (LISP)", 1576 draft-ietf-lisp-18 (work in progress), December 2011. 1578 [I-D.dietz-hip-operator-issues] 1579 Dietz, T., "Issues of HIP in an Operators Networks", 1580 draft-dietz-hip-operator-issues-00 (work in progress), 1581 October 2005. 1583 [I-D.huitema-multi-homed] 1584 Huitema, C., "Multi-homed TCP", 1585 draft-huitema-multi-homed-01 (work in progress), May 1995. 1587 [I-D.irtf-hiprg-dht] 1588 Ahrenholz, J., "Host Identity Protocol Distributed Hash 1589 Table Interface", draft-irtf-hiprg-dht-05 (work in 1590 progress), December 2011. 1592 [I-D.thaler-mobility-comparison] 1593 Thaler, D., "A Comparison of IP Mobility-Related 1594 Protocols", draft-thaler-mobility-comparison-02 (work in 1595 progress), October 2006. 1597 [I-D.dawkins-trigtran-framework] 1598 Dawkins, S., "Framework and Requirements for TRIGTRAN", 1599 draft-dawkins-trigtran-framework-00 (work in progress), 1600 February 2003. 1602 [I-D.schuetz-tcpm-tcp-rlci] 1603 Schuetz, S., Koutsianas, N., Eggert, L., Eddy, W., Swami, 1604 Y., and K. Le, "TCP Response to Lower-Layer Connectivity- 1605 Change Indications", draft-schuetz-tcpm-tcp-rlci-03 (work 1606 in progress), February 2008. 1608 [I-D.swami-tcp-lmdr] 1609 Swami, Y., "Lightweight Mobility Detection and Response 1610 (LMDR) Algorithm for TCP", draft-swami-tcp-lmdr-07 (work 1611 in progress), March 2006. 1613 [I-D.henderson-hip-vpls] 1614 Henderson, T., Venema, S., and D. Mattes, "HIP-based 1615 Virtual Private LAN Service (HIPLS)", 1616 draft-henderson-hip-vpls-03 (work in progress), 1617 September 2011. 1619 [I-D.oliva-hiprg-reap4hip] 1620 Oliva, A. and M. Bagnulo, "Fault tolerance configurations 1621 for HIP multihoming", draft-oliva-hiprg-reap4hip-00 (work 1622 in progress), July 2007. 1624 [I-D.heer-hip-middle-auth] 1625 Hummen, R., Heer, T., and M. Komu, "End-Host 1626 Authentication for HIP Middleboxes", 1627 draft-heer-hip-middle-auth-04 (work in progress), 1628 October 2011. 1630 [I-D.zhang-hip-privacy-protection] 1631 Zhang, D. and M. Komu, "An Extension of HIP Base Exchange 1632 to Support Identity Privacy", 1633 draft-zhang-hip-privacy-protection-03 (work in progress), 1634 July 2011. 1636 [I-D.irtf-hiprg-proxies] 1637 Zhang, D., Xu, X., Yao, J., and Z. Cao, "Investigation in 1638 HIP Proxies", draft-irtf-hiprg-proxies-04 (work in 1639 progress), October 2011. 1641 [I-D.moskowitz-hip-rg-dex] 1642 Moskowitz, R., "HIP Diet EXchange (DEX)", 1643 draft-moskowitz-hip-rg-dex-05 (work in progress), 1644 March 2011. 1646 Authors' Addresses 1648 Tom Henderson 1649 The Boeing Company 1650 P.O. Box 3707 1651 Seattle, WA 1652 USA 1654 Email: thomas.r.henderson@boeing.com 1656 Andrei Gurtov 1657 University of Oulu 1658 Centre for Wireless Communications CWC 1659 P.O. Box 4500 1660 FI-90014 University of Oulu 1661 Finland 1663 Email: gurtov@ee.oulu.fi