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, 2007
                                                           June 28, 2008

       Using the Host Identity Protocol with Legacy Applications
                     draft-ietf-hip-applications-02
                     draft-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  . . . . . . . . . . . . . . . . . . . . . . . . .  4  5
   3.  Approaches for supporting legacy applications  Enabling HIP transparently within the system . . . . . . . .  5 .  6
     3.1.  Using  Applying HIP to cases in which IP addresses are used . . .  6
     3.2.  Interposing a HIP-aware agent in applications the 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 directly to 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 . . . . . . . . . . . . . . . . . . . . 14 18
   Appendix A.  Changes from previous versions  . . . . . . . . . . . 15 19
     A.1.  From version-01 to version-02  . . . . . . . . . . . . . . 19
     A.2.  From version-02 to version-03 (current)  . . . . . . . . . 15 20
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17 21
   Intellectual Property and Copyright Statements . . . . . . . . . . 18 22

1.  Introduction

   The Host Identity Protocol (HIP) [1] [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-
   independent
   location-independent unique name of the a 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,
   there

   The discussion so far assumes that applications are written directly
   to a few basic possibilities: i) allow sockets API.  However, many applications to use IP
   addresses as before, and provide are built on top of
   middleware that exports a mapping from IP address to host
   identifier (and back higher-level API to IP address) within the system, ii) take
   advantage application.  In
   this case, for the purpose of domain name resolution this document, we refer to provide the
   combination of the middleware and the middleware- based application with
   either
   as an alias for the host identifier overall application, or (in the case client of IPv6) the
   host identity tag (HIT) itself, and iii) support sockets 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 variations applications 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 HITs discussion 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 at completely 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" in chooses to
   enable HIP for some or all sessions based on policy.  The second
   option is that the Encapsulating Security Payload (ESP) association formed user 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 bound the 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) invoked mechanism 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 [1].
      [RFC5201].

   Host Identity Tag (HIT):  A 128-bit quantity composed with the hash
      of a Host Identity.  More details are available in [2] [RFC4843] and [1].
      [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 the   In an application with more than two parties, party B
      takes the IP address of party A and passes what it believes that to
      be an party 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 organized IP addresses is never retained by the name used by an application (or
      application.  The only usage is for the application user) to name pass 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 local sendto()).

   Long-lived application associations:  The IP address management issues is retained by
      the application for several instances of communication.

3.  Enabling HIP transparently within the system

   When both users and applications are
   discussed.

   Applications unaware 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-lived address 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 of to return to the below mechanisms has implications on these
   different uses of application
   a HIT or a locally scoped handle, formatted like an IP addresses by legacy applications. address.

3.1.  Using  Applying HIP to cases in which IP addresses in applications are 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 we the host administrator would like to
   enable HIP to protect the communications.  Since the application or  The user can not indicate a
   desire or application
   intends for the system to use HIP through communicate with the standard sockets API when host reachable at that
   IP addresses
   are used, the address.  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 [3]. [paper.tesla].

   There are a number of ways that HIP could be used configured 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 with the DNS servers.  Discussion of the
      security extensions, implications of the use or absence of the reverse DNS map DNSSEC is subject deferred
      to
      well-known the security limitations (an attacker may cause an
      incorrect IP address to domain name binding to occur). considerations section.

   Using the opportunistic mode or using DNS HIP 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 preserving
   presently 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 addresses above fashion.

   A possible way to reduce latencies noted above, in the applications have case that the benefit of better support
   application uses DNS, would be for applications that use IP addresses the 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
   using
   to temporarily cache the HITs returned with a DNS lookup, indexed by
   the IP addresses returned in this manner due to the frequent presence of
   NATs [4] same entry, and Section 3.3, because pass the binding between host identifier
   and address is weak and not visible IP
   addresses up to the application or user.  In
   fact, the semantics of the application's "connect(ip)" call may be
   interpreted as "connect me usual.  If an application connects
   to the system reachable at one 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 authenticate addresses within a short time after the peer at lookup,
   the onset of communications.
   DNS host should initiate a base exchange using the cached HITs.  The
   benefit is that this removes the uncertainty/delay associated with security extensions (DNSSEC) [5] could be used to
   authenticate
   opportunistic HIP, because the bindings between IP address and host identifier, if DNS record suggests that the necessary DNSSEC records were available and trusted.

   The legacy application peer is unaware of HIP and cannot therefore notify
   HIP-capable.

3.2.  Interposing a HIP-aware agent in the user when DNS resolution

   In the previous section, it was noted that a HIP-unaware application uses HIP.  However,
   might typically use the operating DNS to fetch IP addresses prior to invoking
   socket calls.  A HIP-enabled system can notify the user might make use of DNS to
   transparently fetch host identifiers for such domain names prior to
   the usage onset of HIP through communication.

   A system with a user agent.
   Further, it is possible for the user local DNS agent to name the network
   application that caused could alternately return a HIP-related event.  This way, the user is
   aware when he Local
   Scope Identifier (LSI) or she is using HIT rather than an IP address, if HIP even though the legacy network
   application
   information is not.

   Using available in the DNS or other directory that binds a
   particular domain name to a host identifier, and otherwise to return
   an IP addresses address 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
   if
   uses 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 in overlay 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 caches application, it may be configured that some of the IP
   address
   identifiers 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 case list of TCP identifiers when the underlying system later opens additional sockets to and
   policies support HIP.  An application processing the same destination.

   Section 4.1.6 of identifiers
   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 [1] states that
   implementations that learn of HIT-to-IP address bindings through connections in parallel.  In such a case, the
   use of non-HIP
   connections may succeed before HIP opportunistic mode must not enforce those bindings connections.  Based on
   later communications sessions.  This implies that local
   system policies, a system may disallow such behaviour and return only
   HIP-based identifiers when IP addresses they are used by found from DNS.

   If the applications, systems application obtains LSIs or HITs that attempt it 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 assume another system that later sessions has no
   system context to resolve the same address will communicate with LSI 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

   In type 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 that may be hard for a HIP-enabled HIP system
   might make use of DNS to transparently fetch host identifiers prior
   determine when to perform garbage collection on the onset LSI bindings.
   However, when using HITs, the security of communication.  For using the HITs for identity
   comparison may be stronger than in the case of using IP addresses.
   Finally, applications that make use may generate log files, and administrators or
   other consumers of
   DNS, the name resolution process is another opportunity to use HIP.
   If host identifiers are bound these log files may become confused to domain names (with a trusted DNS),
   the following are possible:

   Return HIP find LSIs and
   or HITs instead of IP addresses:

      The system resolver could addresses.  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 than to 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 available
   addresses.  However, such networks are out of scope of this document.

3.3.  Discussion

   Solutions preserving the use of IP addresses in the DNS applications have
   the benefit of better support for applications that binds a particular domain
      name use 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 mapping Section 4, because the
   binding between LSI and host identifier and perform the appropriate conversion at address is weak and not visible
   to the
      system call interface or below.  The application uses the LSI or
      HIT user.  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 been address 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 drawback this case to spoofing the DNS resolution is that some
      applications actually may want provide perfect
   forward secrecy and authentication, but not to fetch strongly authenticate
   the peer at the onset of communications.

   Using IP addresses (e.g.,
      diagnostic applications such as ping, or processes that generate at the application layer may not provide the full
   potential benefits of HIP mobility support.  It allows for mobility
   if the system log files).  One way is able to provide finer granularity on
      whether readdress long-lived, connected sockets upon
   a HIP readdress event.  However, as in current systems, mobility will
   break in the resolver returns connectionless case, when an application caches the IP
   address and repeatedly calls sendto(), or an LSI is to
      distinguish by in the presence case of a domain name prefix.
      Specifically, if the application requests to resolve "HIP-
      www.example.com" (or some similar prefix string), then TCP when the
   system
      returns an LSI, while if the application requests later opens additional sockets to resolve
      "www.example.com", IP address(es) are returned as usual.  The use the same destination.

   Section 4.1.6 of a prefix rather than suffix is recommended, and the base HIP protocol specification [RFC5201] states
   that implementations that learn of HIT-to-IP address bindings through
   the use of a
      string delimiter that is HIP opportunistic mode must not a dot (".") is also recommended, to
      reduce the likelihood enforce those bindings on
   later communications sessions.  This implies that such modified DNS names when IP addresses
   are mistakenly
      treated as names rooted at a new top-level domain.

   Fetch HIP records transparently:

      A third option would be for used by the system applications, systems that attempt to
   opportunistically query
      for set up HIP records in parallel to other DNS resource records, and must not assume that later sessions to
      temporarily cache
   the HITs returned same address will communicate with a DNS lookup, indexed by
      the IP addresses returned in the same entry, host.

   The legacy application is unaware of HIP and pass therefore cannot notify
   the IP
      addresses up to user when the application as usual.  If an application
      connects to one uses HIP.  However, the operating
   system can notify the user of those IP addresses within a short time after the lookup, initiate usage of HIP through a base exchange using the cached HITs.  The
      benefit user agent.
   Further, it is that this removes possible for the uncertainty/delay associated with
      opportunistic HIP, because user agent to name the DNS record suggests network
   application that caused a HIP-related event.  This way, the peer user is HIP-capable.

   Since the LSI
   aware when he or HIT she 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, applications DNS resolution is that perform referrals some
   applications, or selected instances of an application, actually may pass the LSI
   want to another system that has no system context fetch IP addresses (e.g., diagnostic applications such as
   ping).  One way to
   resolve provide finer granularity on whether the resolver
   returns an IP address or an LSI back is to have the user form a host identifier modified
   domain name when he or an IP address.  Note
   that these are she wants to invoke HIP.  This leads us to
   consider, in the same type of next 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 cache did not necessarily involve the results of DNS queries for a long
   time, and it user.
   However, there may be hard for cases in which a HIP system legacy application user wants
   to determine when use HIP for a given application instance by signaling to
   perform garbage collection on the LSI bindings.  However, when using
   HITs, the security of using the HITs for identity comparison may be
   stronger than HIP-
   enabled system in some way.  If the case of using application user interface or
   configuration file accepts IP addresses.

   It addresses, there may be possible for an LSI or HIT opportunity
   to be routable or resolvable,
   either directly provide a HIT or through an overlay, LSI in which case it would be
   preferable for applications its 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 scope use HIP.  We describe both of this document.

3.3. these approaches below.

4.1.  Connecting directly to a HIT

   The previous two sections describe or LSI

   Section 3.2 above describes the use of IP addresses and HITs 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 [2]. [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 challenge domain 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 finding a
   graphical user interface (GUI) can be provided by the IP addresses system to use, based
   on allow
   a user to set the HIT.  Some type of HIT resolution service would be needed in
   this case.  A third challenge of this approach policy 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 be to other HIP-
   aware hosts (else
   dynamically link the initial HIP associations would fail application to
   establish), the resulting referral problem may be a modified library that wraps the peer host
   supports
   system calls and interposes HIP but is not able to perform HIT resolution layer 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, the  The 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 [6] 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 applications system API call such as getaddrinfo [RFC3493] is used for
   resolving local addresses, it may
   launch also return HITs or LSIs, if the connections
   system has assigned HITs or LSIs to internal virtual interfaces
   (common in parallel.  In such a case, the non-HIP
   connections may succeed before many HIP connections.  Based on local
   system policies, a system implementations).  The application may disallow use such behaviour and return only
   HIP-based
   identifiers 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
   anchillary
   ancillary 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 outlined scenarios outlined above differ considerably in their security
   properties.  There  When the DNS is used, there are further differences
   related to whether DNSSEC [RFC4033] is used or not, and whether the DNSSEC
   DNS zones are considered trustworthy enough.  Here we mean that the there
   should exist a delegation chain from the
   reverse IP root should be trusted (typical to 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 represent name the peer system,
   the security properties depend on the the configuration 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-secured non-
   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 provides additional protection against of 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

   [1]

   [RFC5201]  Moskowitz, R., Nikander, P., Jokela, P., and T. Henderson,
              "Host Identity Protocol", draft-ietf-hip-base-10 (work in progress),
        October 2007.

   [2] 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.

   [3]

   [paper.tesla]
              Salz, J., Balakrishnan, H., and A. Snoeren, "TESLA:  A
              Transparent, Extensible Session-Layer Architecture for End-to-
        end
              End-to-end Network Services",  Proceedings of USENIX
              Symposium on Internet Technologies and Systems (USITS),
              pages 211-224, March 2003.

   [4]

   [RFC1958]  Carpenter, B., "Architectural Principles of the Internet",
              RFC 1958, June 1996.

   [5]

   [RFC4033]  Arends, R., Austein, R., Larson, M., Massey, D., and S.
              Rose, "DNS Security Introduction and Requirements",
              RFC 4033, March 2005.

   [6]

   [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: thomas.r.henderson@boeing.com

   Pekka Nikander
   Ericsson Research NomadicLab
   JORVAS  FIN-02420
   FINLAND

   Phone: +358 9 299 1
   Email: pekka.nikander@nomadiclab.com

   Miika Komu
   Helsinki Institute for Information Technology
   Metsaenneidonkuja 4
   Helsinki  FIN-02420
   FINLAND

   Phone: +358503841531
   Email: miika@iki.fi

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
   ietf-ipr@ietf.org.

Acknowledgment

   Funding for the RFC Editor function is provided by the IETF
   Administrative Support Activity (IASA).