Network Working Group T. Henderson Internet-Draft The Boeing Company Intended status: Informational P. Nikander Expires:
May 21,December 30, 2008 Ericsson Research NomadicLab M. Komu Helsinki Institute for Information Technology November 18, 2007June 28, 2008 Using the Host Identity Protocol with Legacy Applications draft-ietf-hip-applications-02draft-ietf-hip-applications-03 Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on May 21,December 30, 2008. Copyright Notice Copyright (C) The IETF Trust (2007).Abstract This document is an informative overview of how legacy applications can be made to work with the Host Identity Protocol (HIP). HIP proposes to add a cryptographic name space for network stack names. From an application viewpoint, HIP-enabled systems support a new address family of host identifiers, but it may be a long time until such HIP-aware applications are widely deployed even if host systems are upgraded. This informational document discusses implementation and Application Programming Interface (API) issues relating to using HIP in situations in which the system is HIP-aware but the applications are not, and is intended to aid implementors and early adopters in thinking about and locally solving systems issues regarding the incremental deployment of HIP. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 45 3. Approaches for supporting legacy applicationsEnabling HIP transparently within the system . . . . . . . . 5. 6 3.1. UsingApplying HIP to cases in which IP addresses are used . . . 6 3.2. Interposing a HIP-aware agent in applicationsthe DNS resolution . . . 7 3.3. Discussion . . . . . . . . . 5 3.2. Using DNS to map domain names to HIs. . . . . . . . . . . 7 3.3.. . . . 8 4. Users Invoking HIP with a Legacy Application . . . . . . . . . 10 4.1. Connecting directlyto a HIT or LSI . . . . . . . . . . . . . . . 8 3.4.. 10 4.2. Using a modified DNS name . . . . . . . . . . . . . . . . 10 4.3. Other techniques . . . . . . . . . . . . . . . . . . . . . 11 5. Local address management . . . . . . . . . . . . . . . . . 9 4.. . 12 6. Security Considerations . . . . . . . . . . . . . . . . . . . 11 5.14 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 6.16 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 13 7.17 9. Informative References . . . . . . . . . . . . . . . . . . . . 1418 Appendix A. Changes from previous versions . . . . . . . . . . . 1519 A.1. From version-01 to version-02 . . . . . . . . . . . . . . 19 A.2. From version-02 to version-03 (current) . . . . . . . . . 1520 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 1721 Intellectual Property and Copyright Statements . . . . . . . . . . 1822 1. Introduction The Host Identity Protocol (HIP) [RFC5201] is an experimental effort in the IETF and IRTF to study a new public-key-based name space for use as host identifiers in Internet protocols. Fully deployed, the HIP architecture would permit applications and users to explicitly request the system to send packets to another host by expressing a location- independentlocation-independent unique name of thea peer host when the system call to connect or send packets is performed. However, there will be a transition period during which systems become HIP-enabled but applications are not. This informational document does not propose normative specification or even suggest that different HIP implementations use more uniform methods for legacy application support, but is intended instead to aid implementors and early adopters in thinking about and solving systems issues regarding the incremental deployment of HIP. When applications and systems are both HIP-aware, the coordination between the application and the system can be straightforward. For example, using the terminology of the widely used sockets Application Programming Interface (API), the application can issue a system call to send packets to another host by naming it explicitly, and the system can perform the necessary name-to-address mapping to assign appropriate routable addresses to the packets. To enable this, a new address family for hosts could be defined, and additional API extensions could be defined (such as allowing IP addresses to be passed in the system call, along with the host name, as hints of where to initially try to reach the host). This document does not define a native HIP API such as described above. Rather, this document is concerned with the scenario in which the application is not HIP-aware and a traditional IP-address-based API is used by the application. To use HIP in such a situation, thereThe discussion so far assumes that applications are written directly to a few basic possibilities: i) allowsockets API. However, many applications to use IP addresses as before, and provideare built on top of middleware that exports a mapping from IP address to host identifier (and backhigher-level API to IP address) withinthe system, ii) take advantageapplication. In this case, for the purpose of domain name resolutionthis document, we refer to providethe combination of the middleware and the middleware- based application with eitheras an alias for the host identifieroverall application, or (in the caseclient of IPv6)the host identity tag (HIT) itself, and iii) supportsockets API. When HIP is enabled on a system, but the use of HITs directly (without prior DNS resolution) in place of IPv6 addresses. This document describes several variationsapplications are not HIP- aware, there are a few basic possibilities to use HIP, each of which may or may not be supported by a given HIP implementation. We report here on techniques that have been used or considered by experimental HIP implementations. We organize the above strategies and points out tradeoffs with each approach. When HITsdiscussion around the policy chosen to use or expose HIP to the applications. The first option is that users are used (rather than IP addresses) as peer names atcompletely unaware of HIP, or are unable to control whether or not HIP is invoked, but rather the system API level, they can provide a type of "channel binding" inchooses to enable HIP for some or all sessions based on policy. The second option is that the Encapsulating Security Payload (ESP) association formeduser makes a decision to try to use HIP by conveying this information somehow within the constraints of the unmodified application. We discuss both of these use cases in detail below. HIP was designed to work with unmodified applications, to ease incremental deployment. For instance, the HIT is cryptographically boundthe same size as the IPv6 address, and the design thinking was that, during initial experiments and transition periods, the HITs could substitute in data structures where IPv6 addresses were expected. However, to a varying degree depending on the name (HIT) invokedmechanism employed, such use of HIP can alter the semantics of what is considered to be an IP address by applications. Applications use IP addresses as short-lived local handles, long-lived application associations, callbacks, referrals, and identity comparisons. The transition techniques described below have implications on these different uses of IP addresses by legacy applications, and we will try to clarify these implications in the calling application.below discussions. 2. Terminology Callback: The application at one end retrieves the IP address of the peer and uses that to later communicate "back" to the peer. An example is the FTP PORT command. Host Identity: An abstract concept applied to a computing platform. Host Identifier (HI): A public key of an asymmetric key pair used as a name for a Host Identity. More details are available in .[RFC5201]. Host Identity Tag (HIT): A 128-bit quantity composed with the hash of a Host Identity. More details are available in [RFC4843] and .[RFC5201]. Local Scope Identifier (LSI): A 32- or 128-bit quantity locally representing the Host Identity at the IPv4 or IPv6 API. Referral: An event when theIn an application with more than two parties, party B takes the IP address of party A and passes what it believesthat to be anparty C. After this party C uses the IP address to another application instance on another host, within its application data stream. An example is the FTP PORT command.communicate with A. Resolver: The system function used by applications to resolve domain names to IP addresses. 3. Approaches for supporting legacy applications This section provides examples of how legacy applications, using legacy APIs, can operate on a HIP-enabled system and use HIP.Short-lived local handle: The examples are organizedIP addresses is never retained by the name used by an application (orapplication. The only usage is for the application user)to namepass it from the peer system: an IP address, a domain name,DNS APIs (e.g., getaddrinfo()) and the API to the protocol stack (e.g., connect() or a HIT. Finally, some localsendto()). Long-lived application associations: The IP address management issuesis retained by the application for several instances of communication. 3. Enabling HIP transparently within the system When both users and applications are discussed. Applicationsunaware of HIP, but the host administrator chooses to use HIP between hosts, a few options are possible. The first basic option is to perform a mapping of the application-provided IP addresses as short-livedaddress to a host identifier within the stack. The second option, if DNS is used, is to interpose a local handles, long- lived application associations, callbacks, referrals,agent in the DNS resolution process and identity comparisons. Each ofto return to the below mechanisms has implications on these different uses ofapplication a HIT or a locally scoped handle, formatted like an IP addresses by legacy applications.address. 3.1. UsingApplying HIP to cases in which IP addresses in applicationsare used Consider the case in which an application issues a "connect(ip)" system call to set the default destination to a system named by address "ip", but for which wethe host administrator would like to enable HIP to protect the communications. Since the application orThe user can not indicate a desireor application intends for the system to use HIP throughcommunicate with the standard sockets API whenhost reachable at that IP addresses are used, theaddress. The decision to invoke HIP must be done on the basis of host policy. For example, when an IPsec-based implementation of HIP is being used, a policy may be entered into the security policy database that mandates to use or to try HIP based on a match on the source or destination IP address, port numbers, or other factors. The mapping of IP address to host identifier may be implemented by modifying the host operating system or by wrapping the existing sockets API, such as in the TESLA approach .[paper.tesla]. There are a number of ways that HIP could be usedconfigured by the host administrator in such a scenario. Manual configuration: Pre-existing SAs may be available due to previous administrative action, or a binding between an IP address and a HIT could be stored in a configuration file or database. Opportunistically: The system could send an I1 to the Responder with an empty value for Responder HIT. Using DNS to map IP addresses to HIs: If the responder has host identifiers registered in the forward DNS zone and has a PTR record in the reverse zone, the Initiator could perform a reverse+forward lookup to learn the HIT associated with the address. Although the approach should work under normal circumstances, it has not been tested to verify that there are no recursion or bootstrapping issues, particularly if HIP is used to secure the connection to the DNS servers. Unless secured withthe DNS servers. Discussion of the security extensions,implications of the use or absence of the reverse DNS mapDNSSEC is subjectdeferred to well-knownthe security limitations (an attacker may cause an incorrect IP address to domain name binding to occur).considerations section. Using the opportunistic mode or using DNSHIP in the above fashion can cause additional setup delays compared to using plain IP. For opportunistic mode, a host must wait to learn whether the peer is HIP-capable, although the delays may be mitigated in some implementations by sending initial packets (e.g., TCP SYN) in parallel to the HIP I1 packet. For DNS lookups,packet and waiting some time to receive a HIP R1 before processing a TCP SYN/ACK. Note that there are resolution latencies. Solutions preservingpresently does not exist specification for how to invoke such connections in parallel. Resolution latencies may also be incurred when using DNS in the use of IP addressesabove fashion. A possible way to reduce latencies noted above, in the applications havecase that the benefit of better supportapplication uses DNS, would be for applications that use IP addressesthe system to opportunistically query for long-lived application associations, callbacks,HIP records in parallel to other DNS resource records, and referrals, although it should be noted that applications are discouraged from usingto temporarily cache the HITs returned with a DNS lookup, indexed by the IP addresses returned in this manner due tothe frequent presence of NATs same entry, and Section 3.3, becausepass the binding between host identifier and address is weak and not visibleIP addresses up to the application or user. In fact, the semantics of the application's "connect(ip)" call may be interpretedas "connect meusual. If an application connects to the system reachable atone of those IP address ip" but perhaps no stronger semantics than that. HIP can be used in this case to provide perfect forward secrecy and authentication, but not to strongly authenticateaddresses within a short time after the peer atlookup, the onset of communications. DNShost should initiate a base exchange using the cached HITs. The benefit is that this removes the uncertainty/delay associated with security extensions (DNSSEC)  could be used to authenticateopportunistic HIP, because the bindings between IP address and host identifier, ifDNS record suggests that the necessary DNSSEC records were available and trusted. The legacy applicationpeer is unaware of HIP and cannot therefore notifyHIP-capable. 3.2. Interposing a HIP-aware agent in the user whenDNS resolution In the previous section, it was noted that a HIP-unaware application uses HIP. However,might typically use the operatingDNS to fetch IP addresses prior to invoking socket calls. A HIP-enabled system can notify the usermight make use of DNS to transparently fetch host identifiers for such domain names prior to the usageonset of HIP throughcommunication. A system with a user agent. Further, it is possible for the userlocal DNS agent to name the network application that causedcould alternately return a HIP-related event. This way, the user is aware when heLocal Scope Identifier (LSI) or she is usingHIT rather than an IP address, if HIP even though the legacy network applicationinformation is not. Usingavailable in the DNS or other directory that binds a particular domain name to a host identifier, and otherwise to return an IP addressesaddress as usual. The system can then maintain a mapping between LSI and host identifier and perform the appropriate conversion at the system call interface or below. The application layer may not provide the full potential benefits of HIP mobility support. It allows for mobility ifuses the system is able to readdress long-lived, connected sockets upon a HIP readdress event. However,LSI or HIT as it would an IP address. This technique has been used in current systems, mobility will break inoverlay networking experiments such as the connectionless case,Internet Indirection Infrastructure (i3) and by at least one HIP implementation. In the case when resolvers can return multiple destination identifiers for an application cachesapplication, it may be configured that some of the IP addressidentifiers can be HIP-based identifiers, and repeatedly calls sendto(),the rest can be IPv4 or IPv6 addresses. The system resolver may return HIP-based identifiers in front of the caselist of TCPidentifiers when the underlying system later opens additional sockets toand policies support HIP. An application processing the same destination. Section 4.1.6 ofidentifiers sequentially will then first try a HIP-based connection and only then other non-HIP based connections. However, certain applications may launch the base HIP protocol specification  states that implementations that learn of HIT-to-IP address bindings throughconnections in parallel. In such a case, the use ofnon-HIP connections may succeed before HIP opportunistic mode must not enforce those bindingsconnections. Based on later communications sessions. This implies thatlocal system policies, a system may disallow such behaviour and return only HIP-based identifiers when IP addressesthey are used byfound from DNS. If the applications, systemsapplication obtains LSIs or HITs that attemptit treats as IP addresses, a few potential hazards arise. First, applications that perform referrals may pass the LSI to opportunistically set up HIP must not assumeanother system that later sessionshas no system context to resolve the same address will communicate withLSI back to a host identifier or an IP address. Note that these are the same host. 3.2. Using DNS to map domain names to HIs Intype of applications that will likely break if used over certain types of network address translators (NATs). Second, applications may cache the previous section,results of DNS queries for a long time, and it was pointed out thatmay be hard for a HIP-enabledHIP system might make use of DNSto transparently fetch host identifiers priordetermine when to perform garbage collection on the onsetLSI bindings. However, when using HITs, the security of communication. Forusing the HITs for identity comparison may be stronger than in the case of using IP addresses. Finally, applications that make usemay generate log files, and administrators or other consumers of DNS, the name resolution process is another opportunity to use HIP. If host identifiers are boundthese log files may become confused to domain names (with a trusted DNS), the following are possible: Return HIPfind LSIs andor HITs instead of IP addresses: The system resolver couldaddresses. Therefore, it is recommended that the HIP software logs the HITs, LSIs (if applicable), and FQDN- related information so that administrators can correlate other logs with HIP identifiers. It may be configured to return a Local Scope Identifier (LSI)possible for an LSI or HIT rather thanto be routable or resolvable, either directly or through an overlay, in which case it would be preferable for applications to handle such names instead of IP address, if HIP information is availableaddresses. However, such networks are out of scope of this document. 3.3. Discussion Solutions preserving the use of IP addresses in the DNSapplications have the benefit of better support for applications that binds a particular domain nameuse IP addresses for long-lived application associations, callbacks, and referrals, although it should be noted that applications are discouraged from using IP addresses in this manner due to a host identifier,the frequent presence of NATs [RFC1958]. However, they have weaker security properties than the approaches outlined in Section 3.2 and otherwise to return an IP address as usual. The system can then maintain a mappingSection 4, because the binding between LSI andhost identifier and perform the appropriate conversion ataddress is weak and not visible to the system call interface or below. Theapplication uses the LSIor HITuser. In fact, the semantics of the application's "connect(ip)" call may be interpreted as it would an"connect me to the system reachable at IP address. This technique has beenaddress ip" but perhaps no stronger semantics than that. HIP can be used in overlay networking experiments such as the Internet Indirection Infrastructure (i3). Locally use a HIP-specific domain name prefix: One drawbackthis case to spoofing the DNS resolution is that some applications actually may wantprovide perfect forward secrecy and authentication, but not to fetchstrongly authenticate the peer at the onset of communications. Using IP addresses (e.g., diagnostic applications such as ping, or processes that generateat the application layer may not provide the full potential benefits of HIP mobility support. It allows for mobility if the system log files). One wayis able to provide finer granularity on whetherreaddress long-lived, connected sockets upon a HIP readdress event. However, as in current systems, mobility will break in the resolver returnsconnectionless case, when an application caches the IP address and repeatedly calls sendto(), or an LSI is to distinguish byin the presencecase of a domain name prefix. Specifically, if the application requests to resolve "HIP- www.example.com" (or some similar prefix string), thenTCP when the system returns an LSI, while if the application requestslater opens additional sockets to resolve "www.example.com", IP address(es) are returned as usual. The usethe same destination. Section 4.1.6 of a prefix rather than suffix is recommended, andthe base HIP protocol specification [RFC5201] states that implementations that learn of HIT-to-IP address bindings through the use of a string delimiter that isHIP opportunistic mode must not a dot (".") is also recommended, to reduce the likelihoodenforce those bindings on later communications sessions. This implies that such modified DNS nameswhen IP addresses are mistakenly treated as names rooted at a new top-level domain. Fetch HIP records transparently: A third option would be forused by the systemapplications, systems that attempt to opportunistically query forset up HIP records in parallel to other DNS resource records, andmust not assume that later sessions to temporarily cachethe HITs returnedsame address will communicate with a DNS lookup, indexed by the IP addresses returned inthe same entry,host. The legacy application is unaware of HIP and passtherefore cannot notify the IP addresses up touser when the application as usual. If an application connects to oneuses HIP. However, the operating system can notify the user of those IP addresses within a short time afterthe lookup, initiateusage of HIP through a base exchange using the cached HITs. The benefituser agent. Further, it is that this removespossible for the uncertainty/delay associated with opportunistic HIP, becauseuser agent to name the DNS record suggestsnetwork application that caused a HIP-related event. This way, the peeruser is HIP-capable. Since the LSIaware when he or HITshe is non-routable, a couple of potential hazards arise,using HIP even though the legacy network application is not. Based on usability tests from initial deployments, displaying the HITs and LSIs should be avoided in user interfaces. Instead, traditional security measures (lock pictures, colored address bars) should be used where possible. One drawback to spoofing the case of referrals, callbacks, and long-lived application associations. First, applicationsDNS resolution is that perform referralssome applications, or selected instances of an application, actually may pass the LSIwant to another system that has no system contextfetch IP addresses (e.g., diagnostic applications such as ping). One way to resolveprovide finer granularity on whether the resolver returns an IP address or an LSI backis to have the user form a host identifiermodified domain name when he or an IP address. Note that these areshe wants to invoke HIP. This leads us to consider, in the same type ofnext section, use cases for which the end user explicitly and selectively chooses to enable HIP. 4. Users Invoking HIP with a Legacy Application The previous section described approaches for configuring HIP for legacy applications that will likely break if used over certain types of network address translators (NATs). Second, applications may cachedid not necessarily involve the results of DNS queries for a long time, and ituser. However, there may be hard forcases in which a HIP systemlegacy application user wants to determine whenuse HIP for a given application instance by signaling to perform garbage collection on the LSI bindings. However, when using HITs, the security of usingthe HITs for identity comparison may be stronger thanHIP- enabled system in some way. If the case of usingapplication user interface or configuration file accepts IP addresses. Itaddresses, there may be possible foran LSI or HITopportunity to be routable or resolvable, either directlyprovide a HIT or throughan overlay,LSI in which case it would be preferable for applicationsits place. Furthermore, if the application uses DNS, a user may provide a specially crafted domain name to signal to the resolver to fetch HIP records and to signal to the system to handle such names instead of IP addresses. However, such networks are out of scopeuse HIP. We describe both of this document. 3.3.these approaches below. 4.1. Connecting directlyto a HIT The previous two sections describeor LSI Section 3.2 above describes the use of IP addresses andHITs or LSIs as local handles to host identifiers.spoofed return values of the DNS resolution process. A third approach, for IPv6 applications,similar approach that is more explicit is to configure the application to connect directly to a HIT (e.g., "connect(HIT)" as a socket call). This scenario has stronger security semantics, because the application is asking the system to send packets specifically to the named peer system. HITs have been defined as Overlay Routable Cryptographic Hash Identifiers (ORCHIDs) such that they cannot be confused with routable IP addresses; see .[RFC4843]. This approach also has a few challenges. Using HITs can be more cumbersome for human users (due to the flat HIT name space) than using either IPv6 addresses or domain names, Another challengedomain names. Another challenge with this approach is in actually finding the IP addresses to use, based on the HIT. Some type of HIT resolution service would be needed in this case. A third challenge of this approach is in supporting callbacks and referrals to possibly non-HIP-aware hosts. However, since most communications in this case would likely be to other HIP- aware hosts (else the initial HIP associations would fail to establish), the resulting referral problem may be that the peer host supports HIP but is not able to perform HIT resolution for some reason. 4.2. Using a modified DNS name Specifically, if the application requests to resolve "HIP- www.example.com" (or some similar prefix string), then the system returns an LSI, while if the application requests to resolve "www.example.com", IP address(es) are returned as usual. The use of a prefix rather than suffix is recommended, and the use of a string delimiter that is not a dot (".") is also recommended, to reduce the likelihood that such modified DNS names are mistakenly treated as names rooted at a new top-level domain. Limits of domain name length or label length (255 or 63, respectively) should be considered when prepending any prefixes. 4.3. Other techniques Alternatives to using a modified DNS name that have been experimented with include the following. Command-line tools or tools with this approach is in actually findinga graphical user interface (GUI) can be provided by the IP addressessystem to use, based onallow a user to set the HIT. Some type of HIT resolution service would be needed in this case. A third challenge of this approachpolicy on which applications use HIP. Another common technique, for dynamically linked applications, is in supporting callbacks and referrals to possibly non-HIP-aware hosts. However, since most communications in this case would likely beto other HIP- aware hosts (elsedynamically link the initial HIP associations would failapplication to establish), the resulting referral problem may bea modified library that wraps the peer host supportssystem calls and interposes HIP but is not able to perform HIT resolutionlayer communications on them; this can be invoked by the user by running commands through a special shell, for some reason. 3.4.example. 5. Local address management The previous two sections focused mainly on controlling client behavior (HIP initiator). We must also consider the behavior for servers. Typically, a server binds to a wildcard IP address and well-known port. In the case of HIP use with legacy server implementations, there are again a few options. As in Section 3.1 above, theThe system may be configured manually to always, optionally (depending on the client behavior), or never use HIP with a particular service, as a matter of policy, when the server specifies a wildcard (IP) address. When a system API call such as getaddrinfo  is used for resolving local addresses, it may also return HITs or LSIs, if the system has assigned HITs or LSIs to internal virtual interfaces (common in many HIP implementations). The application may use such identifiers as addresses in subsequent socket calls. In the case when resolvers can return multiple destination identifiers for an application, it may be configured that some of the identifiers can be HIP-based identifiers, and the rest can be IPv4 or IPv6 addresses. The system resolver may return HIP-based identifiers in front of the list of identifiers when the underlying system and policies support HIP. An application processing the identifiers sequentially will then first try a HIP-based connection and only then other non-HIP based connections. However, certain applicationssystem API call such as getaddrinfo [RFC3493] is used for resolving local addresses, it may launchalso return HITs or LSIs, if the connectionssystem has assigned HITs or LSIs to internal virtual interfaces (common in parallel. In such a case, the non-HIP connections may succeed beforemany HIP connections. Based on local system policies, a systemimplementations). The application may disallowuse such behaviour and return only HIP-basedidentifiers when they are found from DNS.as addresses in subsequent socket calls. Some applications may try to bind a socket to a specific local address, or may implement server-side access control lists based on socket calls such as getsockname() and getpeername() in the C-based socket APIs. If the local address specified is an IP address, again, the underlying system may be configured to still use HIP. If the local address specified is a HIT (Section 3.3),4), the system should enforce that connections to the local application can only arrive to the specified HIT. If a system has many HITs, an application that binds to a single HIT cannot accept connections to the other HITs in the system. When a host has multiple HIs and the socket behavior does not prescribe the use of any particular HI as a local identifier, it is a matter of local policy as to how to select a HI to serve as a local identifier. However, systems that bind to a wildcard may face problems when multiple HITs or LSIs are defined. These problems are not specific to HIP per se, but are also encountered in non-HIP multihoming scenarios with applications not designed for multihoming. As an example, consider a client application that sends an UDP datagram to a server that is bound to a wildcard. The server application receives the packet using recvfrom() and sends a response using sendto(). The problem here is that sendto() may actually use a different server HIT than the client assumes. The client will drop the response packet when the client implements access control on the UDP socket (e.g. using connect()). Reimplementing the server application using the sendmsg() and recvmsg() to support multihoming (particularly considering the anchillaryancillary data) would be the ultimate solution to this problem, but with legacy applications is not an option. As a workaround, we make suggestion for servers providing UDP-based services with non- multihoming capable services. Such servers should announce only the HIT or public key that matches to the default outgoing HIT of the host to avoid such problems. Finally, some applications may create a connection to a local HIT. In such a case, the local system may use NULL encryption to avoid unnecessary encryption overhead, and may be otherwise more permissive than usual such as excluding authentication, Diffie-Hellman exchange, and puzzle. 4.6. Security Considerations In this section we discuss the security of the system in general terms, outlining some of the security properties. However, this section is not intended to provide a complete risk analysis. Such an analysis would, in any case, be dependent on the actual application using HIP, and is therefore considered out of scope. The three outlinedscenarios outlined above differ considerably in their security properties. ThereWhen the DNS is used, there are further differences related to whether DNSSEC [RFC4033] is used or not, and whether the DNSSECDNS zones are considered trustworthy enough. Here we mean that thethere should exist a delegation chain from the reverse IP root should be trusted (typicalto whatever trust anchor issues),anchors are available in the respective trees, and the DNS zone administrators in charge of the netblock should be trusted to put in the right information. When IP addresses are used by applications to representname the peer system, the security properties depend on the theconfiguration method. With manual configuration, the security of the system is comparable to a non-HIP system with similar IPsec policies. The security semantics of an initial opportunistic key exchange are roughly equal to non-securednon- secured IP; the exchange is vulnerable to man-in-the-middle attacks. However, the system is less vulnerable to connection hijacking attacks. If the DNS is used, if both zones are secured (or the HITs are stored in the reverse DNS record) and the client trusts the DNSSEC signatures, the system may provide a fairly high security level. However, much depends on the details of the implementation, the security and administrative practices used when signing the DNS zones, and other factors. Using the forward DNS to map a domain name into an LSI is a case that is closest to the most typical use scenarios today. If DNSSEC is used, the result is fairly similar to the current use of certificates with TLS. If DNSSEC is not used, the result is fairly similar to the current use of plain IP, with the exception that HIP providesadditional protection againstof data integrity, confidentiality, and prevention of connection hijacking attacks.that opportunistic HIP provides. If DNSSEC is used, data integrity and data origin authentication services are added to the normal DNS query protocol, thereby providing more certainty that the desired host is being contacted, if the DNS records themselves are trustworthy. If the application is basing its operations on HITs, the connections become automatically secured due to the implicit channel bindings in HIP. That is, when the application makes a connect(HIT) system call, the resulting packets will either be sent to a node possessing the corresponding private key or the security association will fail to be established. When the system provides (spoofs) LSIs or HITs instead of IP addresses as the result of name resolution, the resultant fields may inadvertently show up in user interfaces and system logs, which may cause operational concerns for some network administrators. 5.Therefore, it is recommended that the HIP software logs the HITs, LSIs (if applicable), and FQDN-related information so that administrators can correlate other logs with HIP identifiers. 7. IANA Considerations This document has no actions for IANA. 6.8. Acknowledgments Jeff Ahrenholz, Gonzalo Camarillo, Alberto Garcia, Teemu Koponen, Julien Laganier, and Jukka Ylitalo have provided comments on different versions of this draft. Erik Nordmark provided the taxonomy of how applications use IP addresses in a previously expired Internet Draft. The document received substantial and useful comments during the review phase from David Black, Pekka Savola, Lars Eggert, and the DNS directorate. 7.Peter Koch. 9. Informative References [RFC5201] Moskowitz, R., Nikander, P., Jokela, P., and T. Henderson, "Host Identity Protocol", draft-ietf-hip-base-10 (work in progress), October 2007. RFC 5201, April 2008. [RFC4843] Nikander, P., Laganier, J., and F. Dupont, "An IPv6 Prefix for Overlay Routable Cryptographic Hash Identifiers (ORCHID)", RFC 4843, April 2007. [paper.tesla] Salz, J., Balakrishnan, H., and A. Snoeren, "TESLA: A Transparent, Extensible Session-Layer Architecture for End-to- endEnd-to-end Network Services", Proceedings of USENIX Symposium on Internet Technologies and Systems (USITS), pages 211-224, March 2003. [RFC1958] Carpenter, B., "Architectural Principles of the Internet", RFC 1958, June 1996. [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "DNS Security Introduction and Requirements", RFC 4033, March 2005. [RFC3493] Gilligan, R., Thomson, S., Bound, J., McCann, J., and W. Stevens, "Basic Socket Interface Extensions for IPv6", RFC 3493, February 2003. Appendix A. Changes from previous versions This section is to be removed by the RFC Editor before publication. It summarizes resolution of issues raised in the following reviews: (1) IESG last call, (2) Gen-ART review, and (3) DNS directorate review. Mobility and secdir reviews did not result in actionable comments. A.1. From version-01 to version-02 (current)Better clarity in the abstract and introduction about the goal of the draft; namely, that it is informational to help implementors and early adopters think about and solve deployment issues (comment from Pekka Savola). Delete the second paragraph of 3 about the general applicability of replacing IP addresses with LSIs and HITs at the socket layer. (comment from Pekka Savola). Delete comments in Section 3.2 on routable LSIs, as this is seen to be out of scope and potentially controversial or incomplete (comment from David Black). Delete reference to Erik Nordmark's shim6 application referral draft, since it is a dead draft (comment from David Black). Instead, Erik is cited in the acknowledgments section for providing the taxonomy of IP address usage scenarios. Clarify (and reference the base spec) in Sec. 3.1 that use of the opportunistic mode requires that systems not enforce that the HIT-to-IP address bindings learned will pertain to subsequent sessions to that IP address. Section 3.2 drew comments from several reviewers. First, David Black raised the issue that spoofing IP addresses with HITs or LSIs raises risks that it may turn up in log records; this has been noted in the text. The section on using a DNS suffix to signal the preferred use of HIP was objected to by members of the DNS directorate and others (including the co-author Pekka Nikander), due to concern that queries to a new TLD might leak out. The current draft instead recommends a DNS prefix instead of suffix, due to a suggestion by Thomas Narten. In section 3.1, clarify recursion issues that may arise when doing reverse+forward lookup of HIP records from DNS (comment from Pekka Savola). Clarify more specifically in security considerations section the DNSSEC trust assumptions or security considerations (outline of text provided by Pekka Savola, and similar comment raised by Peter Koch). Clarified in security considerations section that IP address spoofing could cause some operational difficulties if they unexpectedly show up in log files or UIs (comment from David Black). Clarified in Sec. 3.1 that opportunistic and DNS techniques can incur additional latency when compared to plain IP (comment from Lars Eggert) Added third option to Section 3.2 for using DNS (transparently fetching HIP resource records when doing other RR queries), suggested by Lars Eggert and also by Olaf Kolkman. Incorporated last-call comments from Miika Komu, which were all handled in Section 3.4: i) clarify multihoming issue for servers with multiple HITs, when receiving UDP, ii) clarify a problem that might arise for applications that do parallel connect, and iii) suggest that loopback HIP connections could use a NULL encryption. Removed expired references and updated active references. Incorporated additional review comments from Miika Komu, and some suggested replacement text, and added him as a co-author. A.2. From version-02 to version-03 (current) DNSSEC clarifications added based on dns-dir review from Peter Koch Editing pass through document. Organizationally, everything except security considerations was in one section. The existing text of Sections 3.1 through 3.3 was moved to new Sections 3 and 4, the previous text of section 3.4 has been moved to section 5, and the previous Section 4 (security considerations) is now Section 6. Performed further wordsmithing and cleanup. Authors' Addresses Thomas Henderson The Boeing Company P.O. Box 3707 Seattle, WA USA Email: firstname.lastname@example.org Pekka Nikander Ericsson Research NomadicLab JORVAS FIN-02420 FINLAND Phone: +358 9 299 1 Email: email@example.com Miika Komu Helsinki Institute for Information Technology Metsaenneidonkuja 4 Helsinki FIN-02420 FINLAND Phone: +358503841531 Email: firstname.lastname@example.org Full Copyright Statement Copyright (C) The IETF Trust (2007).(2008). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at email@example.com. Acknowledgment Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA).