idnits 2.17.1 draft-ietf-hip-applications-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 19. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 620. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 631. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 638. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 644. 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 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (November 18, 2007) is 6003 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Obsolete informational reference (is this intentional?): RFC 4843 (ref. '2') (Obsoleted by RFC 7343) Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group T. Henderson 3 Internet-Draft The Boeing Company 4 Intended status: Informational P. Nikander 5 Expires: May 21, 2008 Ericsson Research NomadicLab 6 M. Komu 7 Helsinki Institute for Information 8 Technology 9 November 18, 2007 11 Using the Host Identity Protocol with Legacy Applications 12 draft-ietf-hip-applications-02 14 Status of this Memo 16 By submitting this Internet-Draft, each author represents that any 17 applicable patent or other IPR claims of which he or she is aware 18 have been or will be disclosed, and any of which he or she becomes 19 aware will be disclosed, in accordance with Section 6 of BCP 79. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF), its areas, and its working groups. Note that 23 other groups may also distribute working documents as Internet- 24 Drafts. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 The list of current Internet-Drafts can be accessed at 32 http://www.ietf.org/ietf/1id-abstracts.txt. 34 The list of Internet-Draft Shadow Directories can be accessed at 35 http://www.ietf.org/shadow.html. 37 This Internet-Draft will expire on May 21, 2008. 39 Copyright Notice 41 Copyright (C) The IETF Trust (2007). 43 Abstract 45 This document is an informative overview of how legacy applications 46 can be made to work with the Host Identity Protocol (HIP). HIP 47 proposes to add a cryptographic name space for network stack names. 48 From an application viewpoint, HIP-enabled systems support a new 49 address family of host identifiers, but it may be a long time until 50 such HIP-aware applications are widely deployed even if host systems 51 are upgraded. This informational document discusses implementation 52 and Application Programming Interface (API) issues relating to using 53 HIP in situations in which the system is HIP-aware but the 54 applications are not, and is intended to aid implementors and early 55 adopters in thinking about and locally solving systems issues 56 regarding the incremental deployment of HIP. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 61 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 62 3. Approaches for supporting legacy applications . . . . . . . . 5 63 3.1. Using IP addresses in applications . . . . . . . . . . . . 5 64 3.2. Using DNS to map domain names to HIs . . . . . . . . . . . 7 65 3.3. Connecting directly to a HIT . . . . . . . . . . . . . . . 8 66 3.4. Local address management . . . . . . . . . . . . . . . . . 9 67 4. Security Considerations . . . . . . . . . . . . . . . . . . . 11 68 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 69 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 13 70 7. Informative References . . . . . . . . . . . . . . . . . . . . 14 71 Appendix A. Changes from previous versions . . . . . . . . . . . 15 72 A.1. From version-01 to version-02 (current) . . . . . . . . . 15 73 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17 74 Intellectual Property and Copyright Statements . . . . . . . . . . 18 76 1. Introduction 78 The Host Identity Protocol (HIP) [1] is an experimental effort in the 79 IETF and IRTF to study a new public-key-based name space for use as 80 host identifiers in Internet protocols. Fully deployed, the HIP 81 architecture would permit applications to explicitly request the 82 system to send packets to another host by expressing a location- 83 independent name of the host when the system call to send packets is 84 performed. However, there will be a transition period during which 85 systems become HIP-enabled but applications are not. This 86 informational document does not propose normative specification or 87 even suggest that different HIP implementations use more uniform 88 methods for legacy application support, but is intended instead to 89 aid implementors and early adopters in thinking about and solving 90 systems issues regarding the incremental deployment of HIP. 92 When applications and systems are both HIP-aware, the coordination 93 between the application and the system can be straightforward. For 94 example, using the terminology of the widely used sockets Application 95 Programming Interface (API), the application can issue a system call 96 to send packets to another host by naming it explicitly, and the 97 system can perform the necessary name-to-address mapping to assign 98 appropriate routable addresses to the packets. To enable this, a new 99 address family for hosts could be defined, and additional API 100 extensions could be defined (such as allowing IP addresses to be 101 passed in the system call, along with the host name, as hints of 102 where to initially try to reach the host). 104 This document does not define a native HIP API such as described 105 above. Rather, this document is concerned with the scenario in which 106 the application is not HIP-aware and a traditional IP-address-based 107 API is used by the application. To use HIP in such a situation, 108 there are a few basic possibilities: i) allow applications to use IP 109 addresses as before, and provide a mapping from IP address to host 110 identifier (and back to IP address) within the system, ii) take 111 advantage of domain name resolution to provide the application with 112 either an alias for the host identifier or (in the case of IPv6) the 113 host identity tag (HIT) itself, and iii) support the use of HITs 114 directly (without prior DNS resolution) in place of IPv6 addresses. 115 This document describes several variations of the above strategies 116 and points out tradeoffs with each approach. 118 When HITs are used (rather than IP addresses) as peer names at the 119 system API level, they can provide a type of "channel binding" in 120 that the Encapsulating Security Payload (ESP) association formed by 121 HIP is cryptographically bound to the name (HIT) invoked by the 122 calling application. 124 2. Terminology 126 Host Identity: An abstract concept applied to a computing platform. 128 Host Identifier (HI): A public key of an asymmetric key pair used as 129 a name for a Host Identity. More details are available in [1]. 131 Host Identity Tag (HIT): A 128-bit quantity composed with the hash 132 of a Host Identity. More details are available in [2] and [1]. 134 Local Scope Identifier (LSI): A 32- or 128-bit quantity locally 135 representing the Host Identity at the IPv4 or IPv6 API. 137 Referral: An event when the application passes what it believes to 138 be an IP address to another application instance on another host, 139 within its application data stream. An example is the FTP PORT 140 command. 142 Resolver: The system function used by applications to resolve domain 143 names to IP addresses. 145 3. Approaches for supporting legacy applications 147 This section provides examples of how legacy applications, using 148 legacy APIs, can operate on a HIP-enabled system and use HIP. The 149 examples are organized by the name used by an application (or 150 application user) to name the peer system: an IP address, a domain 151 name, or a HIT. Finally, some local address management issues are 152 discussed. 154 Applications use IP addresses as short-lived local handles, long- 155 lived application associations, callbacks, referrals, and identity 156 comparisons. Each of the below mechanisms has implications on these 157 different uses of IP addresses by legacy applications. 159 3.1. Using IP addresses in applications 161 Consider the case in which an application issues a "connect(ip)" 162 system call to set the default destination to a system named by 163 address "ip", but for which we would like to enable HIP to protect 164 the communications. Since the application or user can not indicate a 165 desire to use HIP through the standard sockets API when IP addresses 166 are used, the decision to invoke HIP must be done on the basis of 167 host policy. For example, when an IPsec-based implementation of HIP 168 is being used, a policy may be entered into the security policy 169 database that mandates to use or try HIP based on a match on the 170 source or destination IP address, or other factors. The mapping of 171 IP address to host identifier may be implemented by modifying the 172 host operating system or by wrapping the existing sockets API, such 173 as in the TESLA approach [3]. 175 There are a number of ways that HIP could be used in such a scenario. 177 Manual configuration: 179 Pre-existing SAs may be available due to previous administrative 180 action, or a binding between an IP address and a HIT could be 181 stored in a configuration file or database. 183 Opportunistically: 185 The system could send an I1 to the Responder with an empty value 186 for Responder HIT. 188 Using DNS to map IP addresses to HIs: 190 If the responder has host identifiers registered in the forward 191 DNS zone and has a PTR record in the reverse zone, the Initiator 192 could perform a reverse+forward lookup to learn the HIT associated 193 with the address. Although the approach should work under normal 194 circumstances, it has not been tested to verify that there are no 195 recursion or bootstrapping issues, particularly if HIP is used to 196 secure the connection to the DNS servers. Unless secured with DNS 197 security extensions, the use of the reverse DNS map is subject to 198 well-known security limitations (an attacker may cause an 199 incorrect IP address to domain name binding to occur). 201 Using the opportunistic mode or using DNS in the above fashion can 202 cause additional setup delays compared to using plain IP. For 203 opportunistic mode, a host must wait to learn whether the peer is 204 HIP-capable, although the delays may be mitigated in some 205 implementations by sending initial packets (e.g., TCP SYN) in 206 parallel to the HIP I1 packet. For DNS lookups, there are resolution 207 latencies. 209 Solutions preserving the use of IP addresses in the applications have 210 the benefit of better support for applications that use IP addresses 211 for long-lived application associations, callbacks, and referrals, 212 although it should be noted that applications are discouraged from 213 using IP addresses in this manner due to the frequent presence of 214 NATs [4] and Section 3.3, because the binding between host identifier 215 and address is weak and not visible to the application or user. In 216 fact, the semantics of the application's "connect(ip)" call may be 217 interpreted as "connect me to the system reachable at IP address ip" 218 but perhaps no stronger semantics than that. HIP can be used in this 219 case to provide perfect forward secrecy and authentication, but not 220 to strongly authenticate the peer at the onset of communications. 221 DNS with security extensions (DNSSEC) [5] could be used to 222 authenticate the bindings between IP address and host identifier, if 223 the necessary DNSSEC records were available and trusted. 225 The legacy application is unaware of HIP and cannot therefore notify 226 the user when the application uses HIP. However, the operating 227 system can notify the user of the usage of HIP through a user agent. 228 Further, it is possible for the user agent to name the network 229 application that caused a HIP-related event. This way, the user is 230 aware when he or she is using HIP even though the legacy network 231 application is not. 233 Using IP addresses at the application layer may not provide the full 234 potential benefits of HIP mobility support. It allows for mobility 235 if the system is able to readdress long-lived, connected sockets upon 236 a HIP readdress event. However, as in current systems, mobility will 237 break in the connectionless case, when an application caches the IP 238 address and repeatedly calls sendto(), or in the case of TCP when the 239 system later opens additional sockets to the same destination. 241 Section 4.1.6 of the base HIP protocol specification [1] states that 242 implementations that learn of HIT-to-IP address bindings through the 243 use of HIP opportunistic mode must not enforce those bindings on 244 later communications sessions. This implies that when IP addresses 245 are used by the applications, systems that attempt to 246 opportunistically set up HIP must not assume that later sessions to 247 the same address will communicate with the same host. 249 3.2. Using DNS to map domain names to HIs 251 In the previous section, it was pointed out that a HIP-enabled system 252 might make use of DNS to transparently fetch host identifiers prior 253 to the onset of communication. For applications that make use of 254 DNS, the name resolution process is another opportunity to use HIP. 255 If host identifiers are bound to domain names (with a trusted DNS), 256 the following are possible: 258 Return HIP LSIs and HITs instead of IP addresses: 260 The system resolver could be configured to return a Local Scope 261 Identifier (LSI) or HIT rather than an IP address, if HIP 262 information is available in the DNS that binds a particular domain 263 name to a host identifier, and otherwise to return an IP address 264 as usual. The system can then maintain a mapping between LSI and 265 host identifier and perform the appropriate conversion at the 266 system call interface or below. The application uses the LSI or 267 HIT as it would an IP address. This technique has been used in 268 overlay networking experiments such as the Internet Indirection 269 Infrastructure (i3). 271 Locally use a HIP-specific domain name prefix: 273 One drawback to spoofing the DNS resolution is that some 274 applications actually may want to fetch IP addresses (e.g., 275 diagnostic applications such as ping, or processes that generate 276 system log files). One way to provide finer granularity on 277 whether the resolver returns an IP address or an LSI is to 278 distinguish by the presence of a domain name prefix. 279 Specifically, if the application requests to resolve "HIP- 280 www.example.com" (or some similar prefix string), then the system 281 returns an LSI, while if the application requests to resolve 282 "www.example.com", IP address(es) are returned as usual. The use 283 of a prefix rather than suffix is recommended, and the use of a 284 string delimiter that is not a dot (".") is also recommended, to 285 reduce the likelihood that such modified DNS names are mistakenly 286 treated as names rooted at a new top-level domain. 288 Fetch HIP records transparently: 290 A third option would be for the system to opportunistically query 291 for HIP records in parallel to other DNS resource records, and to 292 temporarily cache the HITs returned with a DNS lookup, indexed by 293 the IP addresses returned in the same entry, and pass the IP 294 addresses up to the application as usual. If an application 295 connects to one of those IP addresses within a short time after 296 the lookup, initiate a base exchange using the cached HITs. The 297 benefit is that this removes the uncertainty/delay associated with 298 opportunistic HIP, because the DNS record suggests that the peer 299 is HIP-capable. 301 Since the LSI or HIT is non-routable, a couple of potential hazards 302 arise, in the case of referrals, callbacks, and long-lived 303 application associations. First, applications that perform referrals 304 may pass the LSI to another system that has no system context to 305 resolve the LSI back to a host identifier or an IP address. Note 306 that these are the same type of applications that will likely break 307 if used over certain types of network address translators (NATs). 308 Second, applications may cache the results of DNS queries for a long 309 time, and it may be hard for a HIP system to determine when to 310 perform garbage collection on the LSI bindings. However, when using 311 HITs, the security of using the HITs for identity comparison may be 312 stronger than in the case of using IP addresses. 314 It may be possible for an LSI or HIT to be routable or resolvable, 315 either directly or through an overlay, in which case it would be 316 preferable for applications to handle such names instead of IP 317 addresses. However, such networks are out of scope of this document. 319 3.3. Connecting directly to a HIT 321 The previous two sections describe the use of IP addresses and LSIs 322 as local handles to host identifiers. A third approach, for IPv6 323 applications, is to configure the application to connect directly to 324 a HIT (e.g., "connect(HIT)" as a socket call). This scenario has 325 stronger security semantics, because the application is asking the 326 system to send packets specifically to the named peer system. HITs 327 have been defined as Overlay Routable Cryptographic Hash Identifiers 328 (ORCHIDs) such that they cannot be confused with routable IP 329 addresses; see [2]. 331 This approach also has a few challenges. Using HITs can be more 332 cumbersome for human users (due to the flat HIT name space) than 333 using either IPv6 addresses or domain names, Another challenge with 334 this approach is in actually finding the IP addresses to use, based 335 on the HIT. Some type of HIT resolution service would be needed in 336 this case. A third challenge of this approach is in supporting 337 callbacks and referrals to possibly non-HIP-aware hosts. However, 338 since most communications in this case would likely be to other HIP- 339 aware hosts (else the initial HIP associations would fail to 340 establish), the resulting referral problem may be that the peer host 341 supports HIP but is not able to perform HIT resolution for some 342 reason. 344 3.4. Local address management 346 The previous sections focused mainly on client behavior (HIP 347 initiator). We must also consider the behavior for servers. 348 Typically, a server binds to a wildcard IP address and well-known 349 port. In the case of HIP use with legacy server implementations, 350 there are again a few options. As in Section 3.1 above, the system 351 may be configured manually to always, optionally (depending on the 352 client behavior), or never use HIP with a particular service, as a 353 matter of policy, when the server specifies a wildcard (IP) address. 355 When a system API call such as getaddrinfo [6] is used for resolving 356 local addresses, it may also return HITs or LSIs, if the system has 357 assigned HITs or LSIs to internal virtual interfaces (common in many 358 HIP implementations). The application may use such identifiers as 359 addresses in subsequent socket calls. 361 In the case when resolvers can return multiple destination 362 identifiers for an application, it may be configured that some of the 363 identifiers can be HIP-based identifiers, and the rest can be IPv4 or 364 IPv6 addresses. The system resolver may return HIP-based identifiers 365 in front of the list of identifiers when the underlying system and 366 policies support HIP. An application processing the identifiers 367 sequentially will then first try a HIP-based connection and only then 368 other non-HIP based connections. However, certain applications may 369 launch the connections in parallel. In such a case, the non-HIP 370 connections may succeed before HIP connections. Based on local 371 system policies, a system may disallow such behaviour and return only 372 HIP-based identifiers when they are found from DNS. 374 Some applications may try to bind a socket to a specific local 375 address, or may implement server-side access control lists based on 376 socket calls such as getsockname() and getpeername() in the C-based 377 socket APIs. If the local address specified is an IP address, again, 378 the underlying system may be configured to still use HIP. If the 379 local address specified is a HIT (Section 3.3), the system should 380 enforce that connections to the local application can only arrive to 381 the specified HIT. If a system has many HITs, an application that 382 binds to a single HIT cannot accept connections to the other HITs in 383 the system. 385 When a host has multiple HIs and the socket behavior does not 386 prescribe the use of any particular HI as a local identifier, it is a 387 matter of local policy as to how to select a HI to serve as a local 388 identifier. However, systems that bind to a wildcard may face 389 problems when multiple HITs or LSIs are defined. These problems are 390 not specific to HIP per se, but are also encountered in non-HIP 391 multihoming scenarios with applications not designed for multihoming. 393 As an example, consider a client application that sends an UDP 394 datagram to a server that is bound to a wildcard. The server 395 application receives the packet using recvfrom() and sends a response 396 using sendto(). The problem here is that sendto() may actually use a 397 different server HIT than the client assumes. The client will drop 398 the response packet when the client implements access control on the 399 UDP socket (e.g. using connect()). 401 Reimplementing the server application using the sendmsg() and 402 recvmsg() to support multihoming (particularly considering the 403 anchillary data) would be the ultimate solution to this problem, but 404 with legacy applications is not an option. As a workaround, we make 405 suggestion for servers providing UDP-based services with non- 406 multihoming capable services. Such servers should announce only the 407 HIT that matches to the default outgoing HIT of the host to avoid 408 such problems. 410 Finally, some applications may create a connection to a local HIT. 411 In such a case, the local system may use NULL encryption to avoid 412 unnecessary encryption overhead, and may be otherwise more permissive 413 than usual such as excluding authentication, Diffie-Hellman exchange, 414 and puzzle. 416 4. Security Considerations 418 In this section we discuss the security of the system in general 419 terms, outlining some of the security properties. However, this 420 section is not intended to provide a complete risk analysis. Such an 421 analysis would, in any case, be dependent on the actual application 422 using HIP, and is therefore considered out of scope. 424 The three outlined scenarios differ considerably in their security 425 properties. There are further differences related to whether DNSSEC 426 is used or not, and whether the DNSSEC zones are considered 427 trustworthy enough. Here we mean that the delegation chain from the 428 reverse IP root should be trusted (typical trust anchor issues), and 429 the DNS zone administrators in charge of the netblock should be 430 trusted to put in the right information. 432 When IP addresses are used to represent the peer system, the security 433 properties depend on the the configuration method. With manual 434 configuration, the security of the system is comparable to a non-HIP 435 system with similar IPsec policies. The security semantics of an 436 initial opportunistic key exchange are roughly equal to non-secured 437 IP; the exchange is vulnerable to man-in-the-middle attacks. 438 However, the system is less vulnerable to connection hijacking 439 attacks. If the DNS is used, if both zones are secured (or the HITs 440 are stored in the reverse DNS record) and the client trusts the 441 DNSSEC signatures, the system may provide a fairly high security 442 level. However, much depends on the details of the implementation, 443 the security and administrative practices used when signing the DNS 444 zones, and other factors. 446 Using the forward DNS to map a domain name into an LSI is a case that 447 is closest to the most typical use scenarios today. If DNSSEC is 448 used, the result is fairly similar to the current use of certificates 449 with TLS. If DNSSEC is not used, the result is fairly similar to the 450 current use of plain IP, with the exception that HIP provides 451 protection against connection hijacking attacks. 453 If the application is basing its operations on HITs, the connections 454 become automatically secured due to the implicit channel bindings in 455 HIP. That is, when the application makes a connect(HIT) system call, 456 the resulting packets will either be sent to a node possessing the 457 corresponding private key or the security association will fail to be 458 established. 460 When the system provides (spoofs) LSIs or HITs instead of IP 461 addresses as the result of name resolution, the resultant fields may 462 inadvertently show up in user interfaces and system logs, which may 463 cause operational concerns for some network administrators. 465 5. IANA Considerations 467 This document has no actions for IANA. 469 6. Acknowledgments 471 Jeff Ahrenholz, Gonzalo Camarillo, Alberto Garcia, Teemu Koponen, 472 Julien Laganier, and Jukka Ylitalo have provided comments on 473 different versions of this draft. Erik Nordmark provided the 474 taxonomy of how applications use IP addresses in a previously expired 475 Internet Draft. The document received substantial and useful 476 comments during the review phase from David Black, Pekka Savola, Lars 477 Eggert, and the DNS directorate. 479 7. Informative References 481 [1] Moskowitz, R., Nikander, P., Jokela, P., and T. Henderson, "Host 482 Identity Protocol", draft-ietf-hip-base-10 (work in progress), 483 October 2007. 485 [2] Nikander, P., Laganier, J., and F. Dupont, "An IPv6 Prefix for 486 Overlay Routable Cryptographic Hash Identifiers (ORCHID)", 487 RFC 4843, April 2007. 489 [3] Salz, J., Balakrishnan, H., and A. Snoeren, "TESLA: A 490 Transparent, Extensible Session-Layer Architecture for End-to- 491 end Network Services", Proceedings of USENIX Symposium on 492 Internet Technologies and Systems (USITS), pages 211-224, 493 March 2003. 495 [4] Carpenter, B., "Architectural Principles of the Internet", 496 RFC 1958, June 1996. 498 [5] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, 499 "DNS Security Introduction and Requirements", RFC 4033, 500 March 2005. 502 [6] Gilligan, R., Thomson, S., Bound, J., McCann, J., and W. 503 Stevens, "Basic Socket Interface Extensions for IPv6", RFC 3493, 504 February 2003. 506 Appendix A. Changes from previous versions 508 This section is to be removed by the RFC Editor before publication. 509 It summarizes resolution of issues raised in the following reviews: 510 (1) IESG last call, (2) Gen-ART review, and (3) DNS directorate 511 review. Mobility and secdir reviews did not result in actionable 512 comments. 514 A.1. From version-01 to version-02 (current) 516 Better clarity in the abstract and introduction about the goal of the 517 draft; namely, that it is informational to help implementors and 518 early adopters think about and solve deployment issues (comment from 519 Pekka Savola). 521 Delete the second paragraph of 3 about the general applicability of 522 replacing IP addresses with LSIs and HITs at the socket layer. 523 (comment from Pekka Savola). 525 Delete comments in Section 3.2 on routable LSIs, as this is seen to 526 be out of scope and potentially controversial or incomplete (comment 527 from David Black). 529 Delete reference to Erik Nordmark's shim6 application referral draft, 530 since it is a dead draft (comment from David Black). Instead, Erik 531 is cited in the acknowledgments section for providing the taxonomy of 532 IP address usage scenarios. 534 Clarify (and reference the base spec) in Sec. 3.1 that use of the 535 opportunistic mode requires that systems not enforce that the 536 HIT-to-IP address bindings learned will pertain to subsequent 537 sessions to that IP address. 539 Section 3.2 drew comments from several reviewers. First, David Black 540 raised the issue that spoofing IP addresses with HITs or LSIs raises 541 risks that it may turn up in log records; this has been noted in the 542 text. The section on using a DNS suffix to signal the preferred use 543 of HIP was objected to by members of the DNS directorate and others 544 (including the co-author Pekka Nikander), due to concern that queries 545 to a new TLD might leak out. The current draft instead recommends a 546 DNS prefix instead of suffix, due to a suggestion by Thomas Narten. 548 In section 3.1, clarify recursion issues that may arise when doing 549 reverse+forward lookup of HIP records from DNS (comment from Pekka 550 Savola). 552 Clarify more specifically in security considerations section the 553 DNSSEC trust assumptions or security considerations (outline of text 554 provided by Pekka Savola, and similar comment raised by Peter Koch). 556 Clarified in security considerations section that IP address spoofing 557 could cause some operational difficulties if they unexpectedly show 558 up in log files or UIs (comment from David Black). 560 Clarified in Sec. 3.1 that opportunistic and DNS techniques can incur 561 additional latency when compared to plain IP (comment from Lars 562 Eggert) 564 Added third option to Section 3.2 for using DNS (transparently 565 fetching HIP resource records when doing other RR queries), suggested 566 by Lars Eggert and also by Olaf Kolkman. 568 Incorporated last-call comments from Miika Komu, which were all 569 handled in Section 3.4: i) clarify multihoming issue for servers with 570 multiple HITs, when receiving UDP, ii) clarify a problem that might 571 arise for applications that do parallel connect, and iii) suggest 572 that loopback HIP connections could use a NULL encryption. 574 Removed expired references and updated active references. 576 Incorporated additional review comments from Miika Komu, and some 577 suggested replacement text, and added him as a co-author. 579 Authors' Addresses 581 Thomas Henderson 582 The Boeing Company 583 P.O. Box 3707 584 Seattle, WA 585 USA 587 Email: thomas.r.henderson@boeing.com 589 Pekka Nikander 590 Ericsson Research NomadicLab 591 JORVAS FIN-02420 592 FINLAND 594 Phone: +358 9 299 1 595 Email: pekka.nikander@nomadiclab.com 597 Miika Komu 598 Helsinki Institute for Information Technology 599 Metsaenneidonkuja 4 600 Helsinki FIN-02420 601 FINLAND 603 Phone: +358503841531 604 Email: miika@iki.fi 606 Full Copyright Statement 608 Copyright (C) The IETF Trust (2007). 610 This document is subject to the rights, licenses and restrictions 611 contained in BCP 78, and except as set forth therein, the authors 612 retain all their rights. 614 This document and the information contained herein are provided on an 615 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 616 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 617 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 618 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 619 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 620 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 622 Intellectual Property 624 The IETF takes no position regarding the validity or scope of any 625 Intellectual Property Rights or other rights that might be claimed to 626 pertain to the implementation or use of the technology described in 627 this document or the extent to which any license under such rights 628 might or might not be available; nor does it represent that it has 629 made any independent effort to identify any such rights. Information 630 on the procedures with respect to rights in RFC documents can be 631 found in BCP 78 and BCP 79. 633 Copies of IPR disclosures made to the IETF Secretariat and any 634 assurances of licenses to be made available, or the result of an 635 attempt made to obtain a general license or permission for the use of 636 such proprietary rights by implementers or users of this 637 specification can be obtained from the IETF on-line IPR repository at 638 http://www.ietf.org/ipr. 640 The IETF invites any interested party to bring to its attention any 641 copyrights, patents or patent applications, or other proprietary 642 rights that may cover technology that may be required to implement 643 this standard. Please address the information to the IETF at 644 ietf-ipr@ietf.org. 646 Acknowledgment 648 Funding for the RFC Editor function is provided by the IETF 649 Administrative Support Activity (IASA).