idnits 2.17.1 draft-ietf-hip-applications-04.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 716. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 727. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 734. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 740. 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 (July 7, 2008) is 5770 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Obsolete informational reference (is this intentional?): RFC 5201 (Obsoleted by RFC 7401) -- Obsolete informational reference (is this intentional?): RFC 4843 (Obsoleted by RFC 7343) Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 9 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: January 8, 2009 Ericsson Research NomadicLab 6 M. Komu 7 Helsinki Institute for Information 8 Technology 9 July 7, 2008 11 Using the Host Identity Protocol with Legacy Applications 12 draft-ietf-hip-applications-04 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 January 8, 2009. 39 Abstract 41 This document is an informative overview of how legacy applications 42 can be made to work with the Host Identity Protocol (HIP). HIP 43 proposes to add a cryptographic name space for network stack names. 44 From an application viewpoint, HIP-enabled systems support a new 45 address family of host identifiers, but it may be a long time until 46 such HIP-aware applications are widely deployed even if host systems 47 are upgraded. This informational document discusses implementation 48 and Application Programming Interface (API) issues relating to using 49 HIP in situations in which the system is HIP-aware but the 50 applications are not, and is intended to aid implementors and early 51 adopters in thinking about and locally solving systems issues 52 regarding the incremental deployment of HIP. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 58 3. Enabling HIP transparently within the system . . . . . . . . . 6 59 3.1. Applying HIP to cases in which IP addresses are used . . . 6 60 3.2. Interposing a HIP-aware agent in the DNS resolution . . . 7 61 3.3. Discussion . . . . . . . . . . . . . . . . . . . . . . . . 8 62 4. Users Invoking HIP with a Legacy Application . . . . . . . . . 10 63 4.1. Connecting to a HIT or LSI . . . . . . . . . . . . . . . . 10 64 4.2. Using a modified DNS name . . . . . . . . . . . . . . . . 10 65 4.3. Other techniques . . . . . . . . . . . . . . . . . . . . . 11 66 5. Local address management . . . . . . . . . . . . . . . . . . . 12 67 6. Security Considerations . . . . . . . . . . . . . . . . . . . 14 68 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 69 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 17 70 9. Informative References . . . . . . . . . . . . . . . . . . . . 18 71 Appendix A. Changes from previous versions . . . . . . . . . . . 19 72 A.1. From version-01 to version-02 . . . . . . . . . . . . . . 19 73 A.2. From version-02 to version-03 . . . . . . . . . . . . . . 20 74 A.3. From version-03 to version-04 (current) . . . . . . . . . 20 75 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 21 76 Intellectual Property and Copyright Statements . . . . . . . . . . 22 78 1. Introduction 80 The Host Identity Protocol (HIP) [RFC5201] is an experimental effort 81 in the IETF and IRTF to study a new public-key-based name space for 82 use as host identifiers in Internet protocols. Fully deployed, the 83 HIP architecture would permit applications and users to explicitly 84 request the system to send packets to another host by expressing a 85 location-independent unique name of a peer host when the system call 86 to connect or send packets is performed. However, there will be a 87 transition period during which systems become HIP-enabled but 88 applications are not. This informational document does not propose 89 normative specification or even suggest that different HIP 90 implementations use more uniform methods for legacy application 91 support, but is intended instead to aid implementors and early 92 adopters in thinking about and solving systems issues regarding the 93 incremental deployment of HIP. 95 When applications and systems are both HIP-aware, the coordination 96 between the application and the system can be straightforward. For 97 example, using the terminology of the widely used sockets Application 98 Programming Interface (API), the application can issue a system call 99 to send packets to another host by naming it explicitly, and the 100 system can perform the necessary name-to-address mapping to assign 101 appropriate routable addresses to the packets. To enable this, a new 102 address family for hosts could be defined, and additional API 103 extensions could be defined (such as allowing IP addresses to be 104 passed in the system call, along with the host name, as hints of 105 where to initially try to reach the host). 107 This document does not define a native HIP API such as described 108 above. Rather, this document is concerned with the scenario in which 109 the application is not HIP-aware and a traditional IP-address-based 110 API is used by the application. 112 The discussion so far assumes that applications are written directly 113 to a sockets API. However, many applications are built on top of 114 middleware that exports a higher-level API to the application. In 115 this case, for the purpose of this document, we refer to the 116 combination of the middleware and the middleware- based application 117 as an overall application, or client of the sockets API. 119 When HIP is enabled on a system, but the applications are not HIP- 120 aware, there are a few basic possibilities to use HIP, each of which 121 may or may not be supported by a given HIP implementation. We report 122 here on techniques that have been used or considered by experimental 123 HIP implementations. We organize the discussion around the policy 124 chosen to use or expose HIP to the applications. The first option is 125 that users are completely unaware of HIP, or are unable to control 126 whether or not HIP is invoked, but rather the system chooses to 127 enable HIP for some or all sessions based on policy. The second 128 option is that the user makes a decision to try to use HIP by 129 conveying this information somehow within the constraints of the 130 unmodified application. We discuss both of these use cases in detail 131 below. 133 HIP was designed to work with unmodified applications, to ease 134 incremental deployment. For instance, the HIT is the same size as 135 the IPv6 address, and the design thinking was that, during initial 136 experiments and transition periods, the HITs could substitute in data 137 structures where IPv6 addresses were expected. However, to a varying 138 degree depending on the mechanism employed, such use of HIP can alter 139 the semantics of what is considered to be an IP address by 140 applications. Applications use IP addresses as short-lived local 141 handles, long-lived application associations, callbacks, referrals, 142 and identity comparisons. The transition techniques described below 143 have implications on these different uses of IP addresses by legacy 144 applications, and we will try to clarify these implications in the 145 below discussions. 147 2. Terminology 149 Callback: The application at one end retrieves the IP address of 150 the peer and uses that to later communicate "back" to the peer. 151 An example is the FTP PORT command. 153 Host Identity: An abstract concept applied to a computing platform. 155 Host Identifier (HI): A public key of an asymmetric key pair used as 156 a name for a Host Identity. More details are available in 157 [RFC5201]. 159 Host Identity Tag (HIT): A 128-bit quantity composed with the hash 160 of a Host Identity. More details are available in [RFC4843] and 161 [RFC5201]. 163 Local Scope Identifier (LSI): A 32- or 128-bit quantity locally 164 representing the Host Identity at the IPv4 or IPv6 API. 166 Referral: In an application with more than two parties, party B 167 takes the IP address of party A and passes that to party C. After 168 this party C uses the IP address to communicate with A. 170 Resolver: The system function used by applications to resolve domain 171 names to IP addresses. 173 Short-lived local handle: The IP addresses is never retained by the 174 application. The only usage is for the application to pass it 175 from the DNS APIs (e.g., getaddrinfo()) and the API to the 176 protocol stack (e.g., connect() or sendto()). 178 Long-lived application associations: The IP address is retained by 179 the application for several instances of communication. 181 3. Enabling HIP transparently within the system 183 When both users and applications are unaware of HIP, but the host 184 administrator chooses to use HIP between hosts, a few options are 185 possible. The first basic option is to perform a mapping of the 186 application-provided IP address to a host identifier within the 187 stack. The second option, if DNS is used, is to interpose a local 188 agent in the DNS resolution process and to return to the application 189 a HIT or a locally scoped handle, formatted like an IP address. 191 3.1. Applying HIP to cases in which IP addresses are used 193 Consider the case in which an application issues a "connect(ip)" 194 system call to set the default destination to a system named by 195 address "ip", but for which the host administrator would like to 196 enable HIP to protect the communications. The user or application 197 intends for the system to communicate with the host reachable at that 198 IP address. The decision to invoke HIP must be done on the basis of 199 host policy. For example, when an IPsec-based implementation of HIP 200 is being used, a policy may be entered into the security policy 201 database that mandates to use or to try HIP based on a match on the 202 source or destination IP address, port numbers, or other factors. 203 The mapping of IP address to host identifier may be implemented by 204 modifying the host operating system or by wrapping the existing 205 sockets API, such as in the TESLA approach [paper.tesla]. 207 There are a number of ways that HIP could be configured by the host 208 administrator in such a scenario. 210 Manual configuration: 212 Pre-existing SAs may be available due to previous administrative 213 action, or a binding between an IP address and a HIT could be 214 stored in a configuration file or database. 216 Opportunistically: 218 The system could send an I1 to the Responder with an empty value 219 for Responder HIT. 221 Using DNS to map IP addresses to HIs: 223 If the responder has host identifiers registered in the forward 224 DNS zone and has a PTR record in the reverse zone, the Initiator 225 could perform a reverse+forward lookup to learn the HIT associated 226 with the address. Although the approach should work under normal 227 circumstances, it has not been tested to verify that there are no 228 recursion or bootstrapping issues, particularly if HIP is used to 229 secure the connection to the DNS servers. Discussion of the 230 security implications of the use or absence of DNSSEC is deferred 231 to the security considerations section. 233 Using HIP in the above fashion can cause additional setup delays 234 compared to using plain IP. For opportunistic mode, a host must wait 235 to learn whether the peer is HIP-capable, although the delays may be 236 mitigated in some implementations by sending initial packets (e.g., 237 TCP SYN) in parallel to the HIP I1 packet and waiting some time to 238 receive a HIP R1 before processing a TCP SYN/ACK. Note that there 239 presently does not exist specification for how to invoke such 240 connections in parallel. Resolution latencies may also be incurred 241 when using DNS in the above fashion. 243 A possible way to reduce latencies noted above, in the case that the 244 application uses DNS, would be for the system to opportunistically 245 query for HIP records in parallel to other DNS resource records, and 246 to temporarily cache the HITs returned with a DNS lookup, indexed by 247 the IP addresses returned in the same entry, and pass the IP 248 addresses up to the application as usual. If an application connects 249 to one of those IP addresses within a short time after the lookup, 250 the host should initiate a base exchange using the cached HITs. The 251 benefit is that this removes the uncertainty/delay associated with 252 opportunistic HIP, because the DNS record suggests that the peer is 253 HIP-capable. 255 3.2. Interposing a HIP-aware agent in the DNS resolution 257 In the previous section, it was noted that a HIP-unaware application 258 might typically use the DNS to fetch IP addresses prior to invoking 259 socket calls. A HIP-enabled system might make use of DNS to 260 transparently fetch host identifiers for such domain names prior to 261 the onset of communication. 263 A system with a local DNS agent could alternately return a Local 264 Scope Identifier (LSI) or HIT rather than an IP address, if HIP 265 information is available in the DNS or other directory that binds a 266 particular domain name to a host identifier, and otherwise to return 267 an IP address as usual. The system can then maintain a mapping 268 between LSI and host identifier and perform the appropriate 269 conversion at the system call interface or below. The application 270 uses the LSI or HIT as it would an IP address. This technique has 271 been used in overlay networking experiments such as the Internet 272 Indirection Infrastructure (i3) and by at least one HIP 273 implementation. 275 In the case when resolvers can return multiple destination 276 identifiers for an application, it may be configured that some of the 277 identifiers can be HIP-based identifiers, and the rest can be IPv4 or 278 IPv6 addresses. The system resolver may return HIP-based identifiers 279 in front of the list of identifiers when the underlying system and 280 policies support HIP. An application processing the identifiers 281 sequentially will then first try a HIP-based connection and only then 282 other non-HIP based connections. However, certain applications may 283 launch the connections in parallel. In such a case, the non-HIP 284 connections may succeed before HIP connections. Based on local 285 system policies, a system may disallow such behaviour and return only 286 HIP-based identifiers when they are found from DNS. 288 If the application obtains LSIs or HITs that it treats as IP 289 addresses, a few potential hazards arise. First, applications that 290 perform referrals may pass the LSI to another system that has no 291 system context to resolve the LSI back to a host identifier or an IP 292 address. Note that these are the same type of applications that will 293 likely break if used over certain types of network address 294 translators (NATs). Second, applications may cache the results of 295 DNS queries for a long time, and it may be hard for a HIP system to 296 determine when to perform garbage collection on the LSI bindings. 297 However, when using HITs, the security of using the HITs for identity 298 comparison may be stronger than in the case of using IP addresses. 299 Finally, applications may generate log files, and administrators or 300 other consumers of these log files may become confused to find LSIs 301 or HITs instead of IP addresses. Therefore, it is recommended that 302 the HIP software logs the HITs, LSIs (if applicable), corresponding 303 IP addresses, and FQDN-related information so that administrators can 304 correlate other logs with HIP identifiers. 306 It may be possible for an LSI or HIT to be routable or resolvable, 307 either directly or through an overlay, in which case it would be 308 preferable for applications to handle such names instead of IP 309 addresses. However, such networks are out of scope of this document. 311 3.3. Discussion 313 Solutions preserving the use of IP addresses in the applications have 314 the benefit of better support for applications that use IP addresses 315 for long-lived application associations, callbacks, and referrals, 316 although it should be noted that applications are discouraged from 317 using IP addresses in this manner due to the frequent presence of 318 NATs [RFC1958]. However, they have weaker security properties than 319 the approaches outlined in Section 3.2 and Section 4, because the 320 binding between host identifier and address is weak and not visible 321 to the application or user. In fact, the semantics of the 322 application's "connect(ip)" call may be interpreted as "connect me to 323 the system reachable at IP address ip" but perhaps no stronger 324 semantics than that. HIP can be used in this case to provide perfect 325 forward secrecy and authentication, but not to strongly authenticate 326 the peer at the onset of communications. 328 Using IP addresses at the application layer may not provide the full 329 potential benefits of HIP mobility support. It allows for mobility 330 if the system is able to readdress long-lived, connected sockets upon 331 a HIP readdress event. However, as in current systems, mobility will 332 break in the connectionless case, when an application caches the IP 333 address and repeatedly calls sendto(), or in the case of TCP when the 334 system later opens additional sockets to the same destination. 336 Section 4.1.6 of the base HIP protocol specification [RFC5201] states 337 that implementations that learn of HIT-to-IP address bindings through 338 the use of HIP opportunistic mode must not enforce those bindings on 339 later communications sessions. This implies that when IP addresses 340 are used by the applications, systems that attempt to 341 opportunistically set up HIP must not assume that later sessions to 342 the same address will communicate with the same host. 344 The legacy application is unaware of HIP and therefore cannot notify 345 the user when the application uses HIP. However, the operating 346 system can notify the user of the usage of HIP through a user agent. 347 Further, it is possible for the user agent to name the network 348 application that caused a HIP-related event. This way, the user is 349 aware when he or she is using HIP even though the legacy network 350 application is not. Based on usability tests from initial 351 deployments, displaying the HITs and LSIs should be avoided in user 352 interfaces. Instead, traditional security measures (lock pictures, 353 colored address bars) should be used where possible. 355 One drawback to spoofing the DNS resolution is that some 356 applications, or selected instances of an application, actually may 357 want to fetch IP addresses (e.g., diagnostic applications such as 358 ping). One way to provide finer granularity on whether the resolver 359 returns an IP address or an LSI is to have the user form a modified 360 domain name when he or she wants to invoke HIP. This leads us to 361 consider, in the next section, use cases for which the end user 362 explicitly and selectively chooses to enable HIP. 364 4. Users Invoking HIP with a Legacy Application 366 The previous section described approaches for configuring HIP for 367 legacy applications that did not necessarily involve the user. 368 However, there may be cases in which a legacy application user wants 369 to use HIP for a given application instance by signaling to the HIP- 370 enabled system in some way. If the application user interface or 371 configuration file accepts IP addresses, there may be an opportunity 372 to provide a HIT or an LSI in its place. Furthermore, if the 373 application uses DNS, a user may provide a specially crafted domain 374 name to signal to the resolver to fetch HIP records and to signal to 375 the system to use HIP. We describe both of these approaches below. 377 4.1. Connecting to a HIT or LSI 379 Section 3.2 above describes the use of HITs or LSIs as spoofed return 380 values of the DNS resolution process. A similar approach that is 381 more explicit is to configure the application to connect directly to 382 a HIT (e.g., "connect(HIT)" as a socket call). This scenario has 383 stronger security semantics, because the application is asking the 384 system to send packets specifically to the named peer system. HITs 385 have been defined as Overlay Routable Cryptographic Hash Identifiers 386 (ORCHIDs) such that they cannot be confused with routable IP 387 addresses; see [RFC4843]. 389 This approach also has a few challenges. Using HITs can be more 390 cumbersome for human users (due to the flat HIT name space) than 391 using either IPv6 addresses or domain names. Another challenge with 392 this approach is in actually finding the IP addresses to use, based 393 on the HIT. Some type of HIT resolution service would be needed in 394 this case. A third challenge of this approach is in supporting 395 callbacks and referrals to possibly non-HIP-aware hosts. However, 396 since most communications in this case would likely be to other HIP- 397 aware hosts (else the initial HIP associations would fail to 398 establish), the resulting referral problem may be that the peer host 399 supports HIP but is not able to perform HIT resolution for some 400 reason. 402 4.2. Using a modified DNS name 404 Specifically, if the application requests to resolve "HIP- 405 www.example.com" (or some similar prefix string), then the system 406 returns an LSI, while if the application requests to resolve 407 "www.example.com", IP address(es) are returned as usual. The use of 408 a prefix rather than suffix is recommended, and the use of a string 409 delimiter that is not a dot (".") is also recommended, to reduce the 410 likelihood that such modified DNS names are mistakenly treated as 411 names rooted at a new top-level domain. Limits of domain name length 412 or label length (255 or 63, respectively) should be considered when 413 prepending any prefixes. 415 4.3. Other techniques 417 Alternatives to using a modified DNS name that have been experimented 418 with include the following. Command-line tools or tools with a 419 graphical user interface (GUI) can be provided by the system to allow 420 a user to set the policy on which applications use HIP. Another 421 common technique, for dynamically linked applications, is to 422 dynamically link the application to a modified library that wraps the 423 system calls and interposes HIP layer communications on them; this 424 can be invoked by the user by running commands through a special 425 shell, for example. 427 5. Local address management 429 The previous two sections focused mainly on controlling client 430 behavior (HIP initiator). We must also consider the behavior for 431 servers. Typically, a server binds to a wildcard IP address and 432 well-known port. In the case of HIP use with legacy server 433 implementations, there are again a few options. The system may be 434 configured manually to always, optionally (depending on the client 435 behavior), or never use HIP with a particular service, as a matter of 436 policy, when the server specifies a wildcard (IP) address. 438 When a system API call such as getaddrinfo [RFC3493] is used for 439 resolving local addresses, it may also return HITs or LSIs, if the 440 system has assigned HITs or LSIs to internal virtual interfaces 441 (common in many HIP implementations). The application may use such 442 identifiers as addresses in subsequent socket calls. 444 Some applications may try to bind a socket to a specific local 445 address, or may implement server-side access control lists based on 446 socket calls such as getsockname() and getpeername() in the C-based 447 socket APIs. If the local address specified is an IP address, again, 448 the underlying system may be configured to still use HIP. If the 449 local address specified is a HIT (Section 4), the system should 450 enforce that connections to the local application can only arrive to 451 the specified HIT. If a system has many HITs, an application that 452 binds to a single HIT cannot accept connections to the other HITs in 453 the system. 455 When a host has multiple HIs and the socket behavior does not 456 prescribe the use of any particular HI as a local identifier, it is a 457 matter of local policy as to how to select a HI to serve as a local 458 identifier. However, systems that bind to a wildcard may face 459 problems when multiple HITs or LSIs are defined. These problems are 460 not specific to HIP per se, but are also encountered in non-HIP 461 multihoming scenarios with applications not designed for multihoming. 463 As an example, consider a client application that sends an UDP 464 datagram to a server that is bound to a wildcard. The server 465 application receives the packet using recvfrom() and sends a response 466 using sendto(). The problem here is that sendto() may actually use a 467 different server HIT than the client assumes. The client will drop 468 the response packet when the client implements access control on the 469 UDP socket (e.g. using connect()). 471 Reimplementing the server application using the sendmsg() and 472 recvmsg() to support multihoming (particularly considering the 473 ancillary data) would be the ultimate solution to this problem, but 474 with legacy applications is not an option. As a workaround, we make 475 suggestion for servers providing UDP-based services with non- 476 multihoming capable services. Such servers should announce only the 477 HIT or public key that matches to the default outgoing HIT of the 478 host to avoid such problems. 480 Finally, some applications may create a connection to a local HIT. 481 In such a case, the local system may use NULL encryption to avoid 482 unnecessary encryption overhead, and may be otherwise more permissive 483 than usual such as excluding authentication, Diffie-Hellman exchange, 484 and puzzle. 486 6. Security Considerations 488 In this section we discuss the security of the system in general 489 terms, outlining some of the security properties. However, this 490 section is not intended to provide a complete risk analysis. Such an 491 analysis would, in any case, be dependent on the actual application 492 using HIP, and is therefore considered out of scope. 494 The scenarios outlined above differ considerably in their security 495 properties. When the DNS is used, there are further differences 496 related to whether DNSSEC [RFC4033] is used or not, and whether the 497 DNS zones are considered trustworthy enough. Here we mean that there 498 should exist a delegation chain to whatever trust anchors are 499 available in the respective trees, and the DNS zone administrators in 500 charge of the netblock should be trusted to put in the right 501 information. 503 When IP addresses are used by applications to name the peer system, 504 the security properties depend on the configuration method. With 505 manual configuration, the security of the system is comparable to a 506 non-HIP system with similar IPsec policies. The security semantics 507 of an initial opportunistic key exchange are roughly equal to non- 508 secured IP; the exchange is vulnerable to man-in-the-middle attacks. 509 However, the system is less vulnerable to connection hijacking 510 attacks. If the DNS is used, if both zones are secured (or the HITs 511 are stored in the reverse DNS record) and the client trusts the 512 DNSSEC signatures, the system may provide a fairly high security 513 level. However, much depends on the details of the implementation, 514 the security and administrative practices used when signing the DNS 515 zones, and other factors. 517 Using the forward DNS to map a domain name into an LSI is a case that 518 is closest to the most typical use scenarios today. If DNSSEC is 519 used, the result is fairly similar to the current use of certificates 520 with TLS. If DNSSEC is not used, the result is fairly similar to the 521 current use of plain IP, with the additional protection of data 522 integrity, confidentiality, and prevention of connection hijacking 523 that opportunistic HIP provides. If DNSSEC is used, data integrity 524 and data origin authentication services are added to the normal DNS 525 query protocol, thereby providing more certainty that the desired 526 host is being contacted, if the DNS records themselves are 527 trustworthy. 529 If the application is basing its operations on HITs, the connections 530 become automatically secured due to the implicit channel bindings in 531 HIP. That is, when the application makes a connect(HIT) system call, 532 the resulting packets will either be sent to a node possessing the 533 corresponding private key or the security association will fail to be 534 established. 536 When the system provides (spoofs) LSIs or HITs instead of IP 537 addresses as the result of name resolution, the resultant fields may 538 inadvertently show up in user interfaces and system logs, which may 539 cause operational concerns for some network administrators. 540 Therefore, it is recommended that the HIP software logs the HITs, 541 LSIs (if applicable), corresponding IP addresses, and FQDN-related 542 information so that administrators can correlate other logs with HIP 543 identifiers. 545 7. IANA Considerations 547 This document has no actions for IANA. 549 8. Acknowledgments 551 Jeff Ahrenholz, Gonzalo Camarillo, Alberto Garcia, Teemu Koponen, 552 Julien Laganier, and Jukka Ylitalo have provided comments on 553 different versions of this draft. Erik Nordmark provided the 554 taxonomy of how applications use IP addresses in a previously expired 555 Internet Draft. The document received substantial and useful 556 comments during the review phase from David Black, Pekka Savola, Lars 557 Eggert, and Peter Koch. 559 9. Informative References 561 [RFC5201] Moskowitz, R., Nikander, P., Jokela, P., and T. Henderson, 562 "Host Identity Protocol", RFC 5201, April 2008. 564 [RFC4843] Nikander, P., Laganier, J., and F. Dupont, "An IPv6 Prefix 565 for Overlay Routable Cryptographic Hash Identifiers 566 (ORCHID)", RFC 4843, April 2007. 568 [paper.tesla] 569 Salz, J., Balakrishnan, H., and A. Snoeren, "TESLA: A 570 Transparent, Extensible Session-Layer Architecture for 571 End-to-end Network Services", Proceedings of USENIX 572 Symposium on Internet Technologies and Systems (USITS), 573 pages 211-224, March 2003. 575 [RFC1958] Carpenter, B., "Architectural Principles of the Internet", 576 RFC 1958, June 1996. 578 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. 579 Rose, "DNS Security Introduction and Requirements", 580 RFC 4033, March 2005. 582 [RFC3493] Gilligan, R., Thomson, S., Bound, J., McCann, J., and W. 583 Stevens, "Basic Socket Interface Extensions for IPv6", 584 RFC 3493, February 2003. 586 Appendix A. Changes from previous versions 588 This section is to be removed by the RFC Editor before publication. 589 It summarizes resolution of issues raised in the following reviews: 590 (1) IESG last call, (2) Gen-ART review, and (3) DNS directorate 591 review. Mobility and secdir reviews did not result in actionable 592 comments. 594 A.1. From version-01 to version-02 596 Better clarity in the abstract and introduction about the goal of the 597 draft; namely, that it is informational to help implementors and 598 early adopters think about and solve deployment issues (comment from 599 Pekka Savola). 601 Delete the second paragraph of 3 about the general applicability of 602 replacing IP addresses with LSIs and HITs at the socket layer. 603 (comment from Pekka Savola). 605 Delete comments in Section 3.2 on routable LSIs, as this is seen to 606 be out of scope and potentially controversial or incomplete (comment 607 from David Black). 609 Delete reference to Erik Nordmark's shim6 application referral draft, 610 since it is a dead draft (comment from David Black). Instead, Erik 611 is cited in the acknowledgments section for providing the taxonomy of 612 IP address usage scenarios. 614 Clarify (and reference the base spec) in Sec. 3.1 that use of the 615 opportunistic mode requires that systems not enforce that the 616 HIT-to-IP address bindings learned will pertain to subsequent 617 sessions to that IP address. 619 Section 3.2 drew comments from several reviewers. First, David Black 620 raised the issue that spoofing IP addresses with HITs or LSIs raises 621 risks that it may turn up in log records; this has been noted in the 622 text. The section on using a DNS suffix to signal the preferred use 623 of HIP was objected to by members of the DNS directorate and others 624 (including the co-author Pekka Nikander), due to concern that queries 625 to a new TLD might leak out. The current draft instead recommends a 626 DNS prefix instead of suffix, due to a suggestion by Thomas Narten. 628 In section 3.1, clarify recursion issues that may arise when doing 629 reverse+forward lookup of HIP records from DNS (comment from Pekka 630 Savola). 632 Clarify more specifically in security considerations section the 633 DNSSEC trust assumptions or security considerations (outline of text 634 provided by Pekka Savola, and similar comment raised by Peter Koch). 636 Clarified in security considerations section that IP address spoofing 637 could cause some operational difficulties if they unexpectedly show 638 up in log files or UIs (comment from David Black). 640 Clarified in Sec. 3.1 that opportunistic and DNS techniques can incur 641 additional latency when compared to plain IP (comment from Lars 642 Eggert) 644 Added third option to Section 3.2 for using DNS (transparently 645 fetching HIP resource records when doing other RR queries), suggested 646 by Lars Eggert and also by Olaf Kolkman. 648 Incorporated last-call comments from Miika Komu, which were all 649 handled in Section 3.4: i) clarify multihoming issue for servers with 650 multiple HITs, when receiving UDP, ii) clarify a problem that might 651 arise for applications that do parallel connect, and iii) suggest 652 that loopback HIP connections could use a NULL encryption. 654 Removed expired references and updated active references. 656 Incorporated additional review comments from Miika Komu, and some 657 suggested replacement text, and added him as a co-author. 659 A.2. From version-02 to version-03 661 DNSSEC clarifications added based on dns-dir review from Peter Koch 663 Editing pass through document. Organizationally, everything except 664 security considerations was in one section. The existing text of 665 Sections 3.1 through 3.3 was moved to new Sections 3 and 4, the 666 previous text of section 3.4 has been moved to section 5, and the 667 previous Section 4 (security considerations) is now Section 6. 668 Performed further wordsmithing and cleanup. 670 A.3. From version-03 to version-04 (current) 672 Add suggestion by David Black to also log IP addresses used in HIP 673 conversations (Sections 3.2 and 7). 675 Authors' Addresses 677 Thomas Henderson 678 The Boeing Company 679 P.O. Box 3707 680 Seattle, WA 681 USA 683 Email: thomas.r.henderson@boeing.com 685 Pekka Nikander 686 Ericsson Research NomadicLab 687 JORVAS FIN-02420 688 FINLAND 690 Phone: +358 9 299 1 691 Email: pekka.nikander@nomadiclab.com 693 Miika Komu 694 Helsinki Institute for Information Technology 695 Metsaenneidonkuja 4 696 Helsinki FIN-02420 697 FINLAND 699 Phone: +358503841531 700 Email: miika@iki.fi 702 Full Copyright Statement 704 Copyright (C) The IETF Trust (2008). 706 This document is subject to the rights, licenses and restrictions 707 contained in BCP 78, and except as set forth therein, the authors 708 retain all their rights. 710 This document and the information contained herein are provided on an 711 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 712 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 713 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 714 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 715 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 716 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 718 Intellectual Property 720 The IETF takes no position regarding the validity or scope of any 721 Intellectual Property Rights or other rights that might be claimed to 722 pertain to the implementation or use of the technology described in 723 this document or the extent to which any license under such rights 724 might or might not be available; nor does it represent that it has 725 made any independent effort to identify any such rights. Information 726 on the procedures with respect to rights in RFC documents can be 727 found in BCP 78 and BCP 79. 729 Copies of IPR disclosures made to the IETF Secretariat and any 730 assurances of licenses to be made available, or the result of an 731 attempt made to obtain a general license or permission for the use of 732 such proprietary rights by implementers or users of this 733 specification can be obtained from the IETF on-line IPR repository at 734 http://www.ietf.org/ipr. 736 The IETF invites any interested party to bring to its attention any 737 copyrights, patents or patent applications, or other proprietary 738 rights that may cover technology that may be required to implement 739 this standard. Please address the information to the IETF at 740 ietf-ipr@ietf.org.