<?xml version="1.0" encoding="iso-8859-1" ?> encoding="UTF-8"?>

<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY RFC2136 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2136.xml" >
<!ENTITY RFC2535 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2535.xml" >
<!ENTITY RFC2766 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2766.xml" >
<!ENTITY RFC3022 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3022.xml" >
<!ENTITY RFC3102 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3102.xml" >
<!ENTITY RFC3748 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3748.xml" >
<!-- <!ENTITY RFC4025 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4025.xml" > -->
<!ENTITY RFC4225 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4225.xml" >
<!ENTITY RFC4306 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4306.xml" >
<!ENTITY RFC4423 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4423.xml" >
<!ENTITY RFC7343 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.7343.xml" >
<!ENTITY RFC7401 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.7401.xml" >
<!ENTITY RFC7402 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.7402.xml" >
<!-- <!ENTITY RFC5201-bis SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-hip-rfc5201-bis.xml" > -->
<!-- <!ENTITY RFC5202-bis SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-hip-rfc5202-bis.xml" > -->
<!-- <!ENTITY RFC5203-bis SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-hip-rfc5203-bis.xml" > -->
<!ENTITY RFC8003 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.8003.xml" >
<!-- <!ENTITY RFC5204-bis SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-hip-rfc5204-bis.xml" > -->
<!ENTITY RFC8004 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.8004.xml" >
<!-- <!ENTITY RFC5205-bis SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-hip-rfc5205-bis.xml" > -->
<!ENTITY RFC8005 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.8005.xml" >
<!-- <!ENTITY RFC5206-bis SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-hip-rfc5206-bis.xml" > -->
<!ENTITY RFC8046 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.8046.xml" >
<!ENTITY RFC8047 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.8047.xml" >
<!ENTITY RFC7435 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.7435.xml" >
<!ENTITY RFC4380 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4380.xml" >
<!ENTITY RFC3972 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3972.xml" >
<!ENTITY RFC5218 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5218.xml" >
<!ENTITY RFC8002 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.8002.xml" >
<!ENTITY RFC5338 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5338.xml" >
<!ENTITY RFC5482 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5482.xml" >
<!ENTITY RFC5887 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5887.xml" >
<!-- <!ENTITY hip-nat SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-hip-native-nat-traversal.xml" > -->
<!ENTITY RFC6078 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6078.xml" >
<!ENTITY RFC6079 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6079.xml" >
<!ENTITY RFC7086 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.7086.xml" >
<!ENTITY RFC6250 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6250.xml" >
<!ENTITY RFC6281 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6281.xml" >
<!ENTITY RFC6317 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6317.xml" >
<!ENTITY RFC6537 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6537.xml" >
<!ENTITY RFC6538 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6538.xml" >
<!-- <!ENTITY nsrg-report SYSTEM "http://medon.htt-consult.com/~rgm/hip/reference.I-D.irtf-nsrg-report.xml" > -->
<!-- <!ENTITY IEEE.802-15-4.2011 SYSTEM "http://medon.htt-consult.com/~rgm/hip/reference.IEEE.802-15-4.2011.xml" > -->

<!-- XX FIX: missing ORCHID reference -->
]>

<?rfc toc="yes"?>
<?rfc strict="yes"?>
<?rfc tocindent="no"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<?rfc symrefs="yes"?>     <!-- use anchors instead of numbers for references -->
<?rfc sortrefs="yes" ?>   <!-- alphabetize the references --> "rfc2629-xhtml.ent">

<rfc xmlns:xi="http://www.w3.org/2001/XInclude" docName="draft-ietf-hip-rfc4423-bis-20" category="info" number="9063" obsoletes="4423" ipr="pre5378Trust200902"> ipr="pre5378Trust200902" updates="" submissionType="IETF" category="info" consensus="true" xml:lang="en" tocInclude="true" symRefs="true" sortRefs="true" version="3">
  <!-- xml2rfc v2v3 conversion 2.47.0 -->
  <front>
    <title>Host Identity Protocol Architecture</title>
    <seriesInfo name="RFC" value="9063"/>
    <author initials="R." surname="Moskowitz" fullname="Robert Moskowitz" role="editor">
      <organization abbrev="HTT Consulting">HTT Consulting</organization>
      <address>
        <postal>
	  <street>Oak Park</street>
	  <!--
          <city>Oak Park</city> -->
	  <region>Michigan</region>
	  <country>USA</country>
          <country>United States of America</country>
        </postal>
        <email>rgm@labs.htt-consult.com</email>
      </address>
    </author>
    <author initials="M.K.T." initials="M." surname="Komu" fullname="Miika Komu">
      <organization abbrev="Ericsson">Ericsson
      </organization>
      <address>
        <postal>
          <street>Hirsalantie 11</street>
	  <city>02420 Jorvas</city>
	  <city>Jorvas</city>
          <code>02420</code>
          <country>Finland</country>
        </postal>
        <email>miika.komu@ericsson.com</email>
      </address>
    </author>
    <date month="Feb" year="2019" /> month="July" year="2021"/>
    <area>Internet</area>

    <keyword>Request for Comments</keyword>
    <keyword>RFC</keyword>
    <keyword>Internet Draft</keyword>
    <keyword>I-D</keyword>

<keyword>cryptographic identity</keyword>
<keyword>cryptographic namespace</keyword>
<keyword>identifier-locator split</keyword>
<keyword>mobility</keyword>
<keyword>multihoming</keyword>
<keyword>NAT traversal</keyword>
<keyword>IPsec</keyword>
<keyword>ESP</keyword>
<keyword>IPv6</keyword>
<keyword>end-to-end security</keyword>
<keyword>end-to-end connectivity</keyword>
<keyword>endpoint identity</keyword>
<keyword>leap of faith</keyword>
<keyword>rendezvous</keyword>

    <abstract>
      <t>This memo describes the Host Identity (HI) namespace, that which
      provides a cryptographic namespace to applications, and the
      associated protocol layer, the Host Identity Protocol, located
      between the internetworking and transport layers, that supports
      end-host mobility, multihoming multihoming, and NAT traversal. Herein are
      presented the basics of the current namespaces, their strengths
      and weaknesses, and how a HI namespace will add completeness to
      them. The roles of the HI namespace in the protocols are
      defined. </t>

      <t>
        This document obsoletes RFC 4423 and addresses the concerns raised by
        the IESG, particularly that of crypto agility. The Security Considerations section on security considerations
	describe
	also describes measures against flooding attacks, usage of identities in access control lists,
	weaker types of identifiers identifiers, and trust on first use.
	This document incorporates
        lessons learned from the implementations of RFC 5201 7401 and goes further
        to explain how HIP works as a secure signaling channel.
      </t>
    </abstract>
  </front>
  <middle>
    <section title="Introduction"> numbered="true" toc="default">
      <name>Introduction</name>
      <t>The Internet has two important global namespaces: Internet
      Protocol (IP) addresses and Domain Name Service (DNS) names.
      These two namespaces have a set of features and abstractions
      that have powered the Internet to what it is today.  They also
      have a number of weaknesses.  Basically, since they are all we
      have, we try to do too much with them.  Semantic overloading
      and functionality extensions have greatly complicated these
      namespaces.</t>
      <t>The proposed Host Identity namespace is also a global namespace, and it fills an important gap between
      the IP and DNS namespaces.  A Host Identity conceptually refers
      to a computing platform, and there may be multiple such Host
      Identities per computing platform (because the platform may wish
      to present a different identity to different communicating peers).
      The Host Identity namespace consists of Host Identifiers (HI).
      There is exactly one Host Identifier for each Host Identity
      (although there may be transient periods of time such as key
      replacement when more than one identifier may be active).
      While this text later talks about non-cryptographic Host Identifiers,
      the architecture focuses on the case in which Host Identifiers are
      cryptographic in nature.  Specifically, the Host Identifier is the
      public key of an asymmetric key-pair. key pair.  Each Host Identity uniquely
      identifies a single host, i.e., no two hosts have the same Host
      Identity.  If two or more computing platforms have the same Host
      Identifier, then they are instantiating a distributed host.  The Host
      Identifier can either be public (e.g., published in the DNS), DNS) or
      unpublished.  Client systems will tend to have both public and
      unpublished Host Identifiers.</t>
      <t>There is a subtle but important difference between Host
      Identities and Host Identifiers.  An Identity refers to the
      abstract entity that is identified.  An Identifier, on the other
      hand, refers to the concrete bit pattern that is used in the
      identification process.</t>

      <t>Although the Host Identifiers could be used in many
      authentication systems, such as <xref
      target="RFC4306">IKEv2</xref>, target="RFC7296" format="default">IKEv2</xref>, the presented
      architecture introduces a new protocol, called the Host Identity
      Protocol (HIP), and a cryptographic exchange, called the HIP
      base exchange; see also <xref target="control-plane"/>. target="control-plane" format="default"/>.
      HIP provides for limited forms of
      trust between systems, enhances mobility, multi-homing multihoming, and
      dynamic IP renumbering, aids in protocol translation / and transition,
      and reduces certain types of denial-of-service (DoS) attacks.
      </t>
      <t>When HIP is used, the actual payload traffic between two HIP
      hosts is typically, but not necessarily, protected with ESP Encapsulating Security Payload (ESP)
      <xref target="RFC7402" />. format="default"/>.
      The Host Identities are used to create the needed ESP Security
      Associations (SAs) and to authenticate the hosts.  When ESP is
      used, the actual payload IP packets do not differ in any way
      from standard ESP protected ESP-protected IP packets.</t>

      <t>
      Much has been learned about HIP <xref target="RFC6538" /> format="default"/> since <xref target="RFC4423" /> format="default"/>
      was published. This document expands Host Identities beyond their original use
      to enable IP connectivity and security to enable general interhost secure
      signalling
      signaling at any protocol layer.  The signal may establish a security
      association between the hosts, hosts or simply pass information within
      the channel.
      </t>
    </section>
    <section title="Terminology">

<?rfc compact="no"?> numbered="true" toc="default">
      <name>Terminology</name>

      <section title="Terms common to other documents">

	<texttable>
	  <ttcol width="20%" align="left">Term</ttcol>
	  <ttcol align="left">Explanation</ttcol>
	  <c>Public key</c><c>The numbered="true" toc="default">
        <name>Terms Common to Other Documents</name>
        <table align="center">
          <thead>
            <tr>
              <th align="left">Term</th>
              <th align="left">Explanation</th>
            </tr>
          </thead>
          <tbody>
            <tr>
              <td align="left">Public key</td>
              <td align="left">The public key of an asymmetric
	    cryptographic key pair.  Used as a publicly known identifier
	    for cryptographic identity authentication.
            Public is a relative term here, ranging from "known to
            peers only" to "known to the world."</c>

	  <c>Private key</c><c>The world".</td>
            </tr>
            <tr>
              <td align="left">Private key</td>
              <td align="left">The private or secret key of an
	    asymmetric cryptographic key pair.  Assumed to be known only
	    to the party identified by the corresponding public key.
	    Used by the identified party to authenticate its identity to
	    other parties.</c>

	  <c>Public parties.</td>
            </tr>
            <tr>
              <td align="left">Public key pair</c><c>An pair</td>
              <td align="left">An asymmetric cryptographic key
	     pair consisting of public and private keys.  For example,
	     Rivest-Shamir-Adleman (RSA), Digital Signature Algorithm
	     (DSA) and Elliptic Curve DSA (ECDSA) key pairs are such key pairs.</c>

	  <c>End-point</c><c>A pairs.</td>
            </tr>
            <tr>
              <td align="left">Endpoint</td>
              <td align="left">A communicating entity.  For
	    historical reasons, the term 'computing platform' is used in
	    this document as a (rough) synonym for end-point.</c>
	</texttable> endpoint.</td>
            </tr>
          </tbody>
        </table>

      </section>

<?rfc compact="yes"?>

<?rfc compact="no"?>
      <section title="Terms specific numbered="true" toc="default">
        <name>Terms Specific to this This and other Other HIP documents"> Documents</name>
        <t>It should be noted that many of the terms defined herein
	are tautologous, self-referential self-referential, or defined through circular
	reference to other terms.  This is due to the succinct nature
	of the definitions.  See the text elsewhere in this document
	and the base specification <xref target="RFC7401" /> format="default"/> for more elaborate
	explanations.</t>

	<texttable>
	  <ttcol width="20%" align="left">Term</ttcol>
	  <ttcol align="left">Explanation</ttcol>

	  <c>Computing platform</c><c>An
        <table align="center">
          <thead>
            <tr>
              <th align="left">Term</th>
              <th align="left">Explanation</th>
            </tr>
          </thead>
          <tbody>
            <tr>
              <td align="left">Computing platform</td>
              <td align="left">An entity capable of
	  communicating and computing, for example, a computer.  See
	  the definition of 'End-point', above.</c>

	  <c></c><c></c>

          <c>HIP 'Endpoint', above.</td>
            </tr>

            <tr>
              <td align="left">HIP base exchange</c><c>A exchange</td>
              <td align="left">A cryptographic protocol;
          see also <xref target="control-plane"/></c>

	  <c></c><c></c>

	  <c>HIP packet</c><c>An target="control-plane" format="default"/>.</td>
            </tr>

            <tr>
              <td align="left">HIP packet</td>
              <td align="left">An IP packet that carries a 'Host
	  Identity Protocol' message.</c>

	  <c></c><c></c>

	  <c>Host Identity</c><c>An message.</td>
            </tr>

            <tr>
              <td align="left">Host Identity</td>
              <td align="left">An abstract concept assigned to
	  a 'computing platform'.  See 'Host Identifier', below.</c>

	  <c></c><c></c>

	  <c>Host Identifier</c><c>A below.</td>
            </tr>

            <tr>
              <td align="left">Host Identifier</td>
              <td align="left">A public key used as a name
	  for a Host Identity.</c>

	  <c></c><c></c>

	  <c>Host Identity.</td>
            </tr>

            <tr>
              <td align="left">Host Identity namespace</c><c>A namespace</td>
              <td align="left">A name space
	  formed by all possible Host Identifiers.</c>

	  <c></c><c></c>

	  <c>Host Identifiers.</td>
            </tr>

            <tr>
              <td align="left">Host Identity Protocol</c><c>A Protocol</td>
              <td align="left">A protocol used to
	  carry and authenticate Host Identifiers and other
	  information. </c>

	  <c></c><c></c>

	  <c>Host </td>
            </tr>

            <tr>
              <td align="left">Host Identity Hash</c><c>The Hash</td>
              <td align="left">The cryptographic hash used
	  in creating the Host Identity Tag from the Host Identifier.</c>

	  <c></c><c></c>

	  <c>Host Identifier.</td>
            </tr>

            <tr>
              <td align="left">Host Identity Tag</c><c>A Tag</td>
              <td align="left">A 128-bit datum created by
	  taking a cryptographic hash over a Host Identifier plus
          bits to identify which hash used.</c>

	  <c></c><c></c>

	  <c>Local was used.</td>
            </tr>

            <tr>
              <td align="left">Local Scope Identifier</c><c>A Identifier</td>
              <td align="left">A 32-bit datum denoting
	  a Host Identity.</c>

	  <c></c><c></c>

	  <c>Public Identity.</td>
            </tr>

            <tr>
              <td align="left">Public Host Identifier and Identity</c><c>A Identity</td>
              <td align="left">A
	  published or publicly known Host Identifier used as a public
	  name for a Host Identity, and the corresponding
	  Identity.</c>

	  <c></c><c></c>

	  <c>Unpublished
	  Identity.</td>
            </tr>

            <tr>
              <td align="left">Unpublished Host Identifier and Identity</c><c>A Identity</td>
              <td align="left">A
	  Host Identifier that is not placed in any public directory,
	  and the corresponding Host Identity.  Unpublished Host
	  Identities are typically short lived in nature, being often
	  replaced and possibly used just once.</c>

	  <c></c><c></c>

	  <c>Rendezvous Mechanism</c><c>A once.</td>
            </tr>
            <tr>
              <td align="left">Rendezvous Mechanism</td>
              <td align="left">A mechanism used to
	  locate mobile hosts based on their HIT.</c>

	</texttable> HIT.</td>
            </tr>
          </tbody>
        </table>
      </section>

<?rfc compact="yes"?>
    </section>
    <section title="Background"> numbered="true" toc="default">
      <name>Background</name>
      <t>The Internet is built from three principal components:
      computing platforms (end-points), (endpoints), packet transport
      (i.e., internetworking) infrastructure, and services
      (applications).  The Internet exists to service two principal
      components: people and robotic services (silicon-based people,
      if you will).  All these components need to be named in order to
      interact in a scalable manner.  Here we concentrate on naming
      computing platforms and packet transport elements.</t>
      <t>There are two principal namespaces in use in the Internet for
      these components: IP addresses, and Domain Names.
      Domain Names provide hierarchically assigned names for some
      computing platforms and some services.  Each hierarchy is
      delegated from the level above; there is no anonymity in Domain
      Names.  Email, HTTP, and SIP addresses all reference Domain
      Names.</t>
      <t>The IP addressing namespace has been overloaded to name both
      interfaces (at layer-3) Layer 3) and endpoints (for the endpoint-specific
      part of layer-3, Layer 3 and for layer-4). Layer 4).  In their role as interface
      names, IP addresses are sometimes called "locators" and serve
      as an endpoint within a routing topology.</t>
      <t>IP addresses are numbers that name networking interfaces, and typically only
      when the interface is connected to the network.  Originally, IP
      addresses had long-term significance.  Today, the vast number of
      interfaces use ephemeral and/or non-unique IP addresses.  That is,
      every time an interface is connected to the network, it is
      assigned an IP address.</t>
      <t>In the current Internet, the transport layers are coupled to
      the IP addresses.  Neither can evolve separately from the other.
      IPng deliberations were strongly shaped by the decision that a
      corresponding TCPng would not be created.</t>
      <t>There are three critical deficiencies with the current
      namespaces.  Firstly,  First, the establishing of initial contact and the sustaining of data flows
      between two hosts can be challenging due to private address realms and the ephemeral nature of addresses.
      Secondly,
      Second, confidentiality is not provided in a consistent,
      trustable manner.  Finally, authentication for systems and
      datagrams is not provided.  All of these deficiencies arise
      because computing platforms are not well named with the current
      namespaces. </t>
      <section title="A desire numbered="true" toc="default">
        <name>A Desire for a namespace Namespace for computing platforms"> Computing Platforms</name>
        <t>An independent namespace for computing platforms could be
        used in end-to-end operations independent of the evolution of
        the internetworking layer and across the many internetworking
        layers.  This could support rapid readdressing of the
        internetworking layer because of mobility, rehoming, or
        renumbering.</t>
        <t>If the namespace for computing platforms is based on
	public-key cryptography, it can also provide authentication
        services.  If this namespace is locally created without
        requiring registration, it can provide anonymity. </t>
        <t>Such a namespace (for computing platforms) and the names in
        it should have the following characteristics:

          <list style="symbols">

	    <t>The
        </t>

        <ul spacing="normal">
          <li>The namespace should be applied to the IP 'kernel' or stack.
            The IP stack is the 'component' between applications and the
            packet transport infrastructure.</t>

	    <t>The infrastructure.</li>
          <li>The namespace should fully decouple the internetworking
	    layer from the higher layers.  The names should replace
	    all occurrences of IP addresses within applications (like
	    in the Transport Control Block, TCB). This replacement can
	    be handled transparently for legacy applications as the
	    LSIs
	    Local Scope Identifiers (LSIs) and HITs are compatible with IPv4 and IPv6 addresses
	    <xref target="RFC5338" />. format="default"/>. However, HIP-aware applications
	    require some modifications from the developers, who may
	    employ networking API extensions for HIP <xref target="RFC6317" />.</t>

	    <t>The format="default"/>.</li>
          <li>The introduction of the namespace should not mandate
            any administrative infrastructure.  Deployment must come
            from the bottom up, in a pairwise deployment.</t>

	    <t>The deployment.</li>
          <li>The names should have a fixed-length representation,
            for easy inclusion in datagram headers and existing
            programming interfaces (e.g (e.g., the TCB).</t>

	    <t>Using TCB).</li>
          <li>Using the namespace should be affordable when used in
            protocols.  This is primarily a packet size issue.  There
            is also a computational concern in affordability.</t>

      <t>Name affordability.</li>
          <li>Name collisions should be avoided as much as possible.  The
            mathematics of the birthday paradox can be used to estimate
            the chance of a collision in a given population and hash space.
            In general, for a random hash space of size n bits, we would
            expect to obtain a collision after approximately 1.2*sqrt(2**n) 1.2*sqrt(2<sup>n</sup>)
            hashes were obtained.  For 64 bits, this number is roughly
            4 billion.  A hash size of 64 bits may be too small to avoid
            collisions in a large population; for example, there is a 1%
            chance of collision in a population of 640M.  For 100 bits
            (or more), we would not expect a collision until approximately
            2**50
            2<sup>50</sup> (1 quadrillion) hashes were generated. With the currently used hash size of 96 bits
            <xref target="RFC7343" />, format="default"/>, the figure is 2**48 2<sup>48</sup> (281 trillions).
	    <!-- Besides accidental
	    collisions, it is also worth noting that intentional collisions
	    are difficult to accomplish because generating a valid, colliding hash
	    along with its private-public key is computationally challenging. -->
</t>

	    <t>The
</li>
          <li>The names should have a localized abstraction so that they can be
               used in existing protocols and APIs.</t>

	    <?rfc needLines="8"?>

	    <t>It APIs.</li>
          <li>It must be possible to create names locally.  When such names
            are not published, this can provide anonymity at the cost of
            making resolvability very difficult.

              <!--
              <list style="symbols">

		<t>Sometimes the names may contain a delegation
		component. This is the cost of resolvability.</t>

	      </list>
              -->

            </t>

	    <t>The
            </li>
          <li>The namespace should provide authentication services.</t>

	    <t>The services.</li>
          <li>The names should be long-lived, but replaceable at any
            time.  This impacts access control lists; short lifetimes
            will tend to result in tedious list maintenance or require
            a namespace infrastructure for central control of access
            lists.</t>

	  </list>
        </t>
            lists.</li>
        </ul>
        <t>In this document, the namespace approaching these ideas
        is called the Host Identity namespace.  Using Host Identities
        requires its own protocol layer, the Host Identity Protocol,
        between the internetworking and transport layers.  The names
        are based on public-key cryptography to supply authentication
        services.  Properly designed, it can deliver all of the above-stated
	requirements.</t>
      </section>
    </section>
    <section title="Host numbered="true" toc="default">
      <name>Host Identity namespace"> Namespace</name>

      <t>A name in the Host Identity namespace, a Host Identifier
      (HI), represents a statistically globally unique name for naming
      any system with an IP stack.  This identity is normally
      associated with, but not limited to, an IP stack.  A system can
      have multiple identities, some 'well known', some unpublished or
      'anonymous'.  A system may self-assert its own identity, or may
      use a third-party authenticator like DNSSEC <xref
      target="RFC2535" />, PGP, target="RFC4033" format="default"/>, Pretty Good Privacy (PGP), or X.509 to 'notarize' the identity
      assertion to another namespace.  <!-- It is expected that the Host Identifiers will
      initially be authenticated with DNSSEC and that all
      implementations will support DNSSEC as a minimal baseline. -->  </t>
      <t>In theory, any name that can claim to be 'statistically
      globally unique' may serve as a Host Identifier.  In the HIP
      architecture, the public key of a private-public key pair has
      been chosen as the Host Identifier because it can be self-managed
      and it is computationally difficult to forge. As
      specified in the Host Identity Protocol specification <xref target="RFC7401" /> specification, format="default"/>, a public-key-based HI can
      authenticate the HIP packets and protect them from man-in-the-middle (MitM)
      attacks. Since authenticated datagrams are
      mandatory to provide much of HIP's denial-of-service protection,
      the Diffie-Hellman exchange in HIP base exchange has to be authenticated.
      Thus, only public-key HI and authenticated HIP messages are
      supported in practice.</t>
      <t>
      <!--

      In this document, the some non-cryptographic forms of HI and HIP are presented to complete the theory of HI, referenced, but they
      cryptographic forms should not be implemented as preferred because they could produce worse denial-of-service
      attacks are more secure than the Internet has without Host Identity. -->
      In this document, some non-cryptographic forms of HI and HIP are referenced, but
      cryptographic forms SHOULD be preferred because they are more secure than their non-cryptographic counterparts.
      There their non-cryptographic counterparts.
      There has
      been past research in challenge puzzles to use using non-cryptographic
      HI,
      HI for Radio Frequency IDentification (RFID), in an HIP
      exchange tailored to the workings of such challenges (as
      described further in <xref target="urien-rfid" /> format="default"/> and <xref
      target="urien-rfid-draft" />).</t> target="I-D.irtf-hiprg-rfid" format="default"/>).</t>
      <section title="Host Identifiers"> numbered="true" toc="default">
        <name>Host Identifiers</name>
        <t>Host Identity adds two main features to Internet protocols.
        The first is a decoupling of the internetworking and transport
        layers; see <xref target="sec-architecture" />. format="default"/>.  This
        decoupling will allow for independent evolution of the two
        layers.  Additionally, it can provide end-to-end services over
        multiple internetworking realms.  The second feature is host
        authentication.  Because the Host Identifier is a public key,
        this key can be used for authentication in security protocols
        like ESP.</t>
        <t>An identity is based on public-private key cryptography in HIP.
        The Host Identity is referred to by its public component, the public
        key.  Thus, the name representing a Host Identity in the Host
        Identity namespace, i.e., the Host Identifier, is the public
        key.  In a way, the possession of the private key defines the
        Identity itself.  If the private key is possessed by more than
        one node, the Identity can be considered to be a distributed
        one.</t>
        <t>Architecturally, any other Internet naming convention might
	form a usable base for Host Identifiers.  However,
	non-cryptographic names should only be used in situations of
	high trust - and/or low risk.  That is any place where host
	authentication is not needed (no risk of host spoofing) and no
	use of ESP.  However, at least for interconnected networks
	spanning several operational domains, the set of environments
	where the risk of host spoofing allowed by non-cryptographic
	Host Identifiers is acceptable is the null set.  Hence, the
	current HIP documents do not specify how to use any other
	types of Host Identifiers but public keys. For instance,
	Back-to-My-Mac
	the Back to My Mac service <xref target="RFC6281" /> format="default"/> from Apple comes
	pretty close to the functionality of HIP, but unlike HIP, it
	is based on non-cryptographic identifiers.
        </t>
        <t>The actual Host Identifiers are never directly used at the
	transport or network layers.  The corresponding Host
	Identifiers (public keys) may be stored in various DNS or other
	directories as identified elsewhere in this document, and they
	are passed in the HIP base exchange.  A Host Identity Tag
	(HIT) is used in other protocols to represent the Host
	Identity.  Another representation of the Host Identities, the
	Local Scope Identifier (LSI), can also be used in protocols
	and APIs.</t>
      </section>
      <section title="Host numbered="true" toc="default">
        <name>Host Identity Hash (HIH)"> (HIH)</name>
        <t>The Host Identity Hash (HIH) is the cryptographic hash algorithm used in
        producing the HIT from the HI.  It is also the hash used
        throughout the HIP protocol for consistency and simplicity.  It
        is possible for the two hosts in the HIP exchange to use
        different hash algorithms.</t>
        <t>Multiple HIHs within HIP are needed to address the moving
        target of creation and eventual compromise of cryptographic
        hashes.  This significantly complicates HIP and offers an
        attacker an additional downgrade attack that is mitigated
        in the HIP protocol <xref target="RFC7401" />.</t> format="default"/>.</t>
      </section>
      <section title="Host numbered="true" toc="default">
        <name>Host Identity Tag (HIT)"> (HIT)</name>
        <t>A Host Identity Tag (HIT) is a 128-bit representation for a Host
	Identity. Due to its size, it is suitable to be used for use in the existing sockets API in
	the place of IPv6 addresses (e.g., in sockaddr_in6 structure, sin6_addr member) without modifying applications.
        It is created from an HIH, an IPv6 prefix <xref target="RFC7343"
	/> format="default"/>, and a hash identifier.  There are two advantages of using
	the HIT over using the Host Identifier in protocols.  Firstly,  First,
	its fixed length makes for easier protocol coding and also
	better manages the packet size cost of this technology.
	Secondly,
	Second, it presents the identity in a consistent format to
	the protocol independent of the cryptographic algorithms
	used.</t>
        <t>In essence, the HIT is a hash over the public key. As such,
        two algorithms affect the generation of a HIT: the public-key
        algorithm of the HI and the used HIH. The two algorithms are
        encoded in the bit presentation of the HIT. As the two
        communicating parties may support different algorithms, <xref target="RFC7401" /> format="default"/> defines the minimum set for
        interoperability. For further interoperability, the responder Responder
        may store its keys in DNS records, and thus the initiator Initiator may
        have to couple destination HITs with appropriate source HITs
        according to matching HIH.</t>
        <t>In the HIP packets, the HITs identify the sender and
        recipient of a packet.  Consequently, a HIT should be unique
        in the whole IP universe as long as it is being used.  In the
        extremely rare case of a single HIT mapping to more than one
        Host Identity, the Host Identifiers (public keys) will make
        the final difference.  If there is more than one public key
        for a given node, the HIT acts as a hint for the correct
        public key to use.</t>
        <t>Although it may be rare for an accidental collision to cause a single
	HIT mapping to more than one Host Identity, it may be the case that
	an attacker succeeds to find, by brute force or algorithmic weakness,
	a second Host Identity hashing to the same HIT.  This type of attack
	is known as a preimage attack, and the resistance to finding a second
	Host Identifier (public key) that hashes to the same HIT is called
	second preimage resistance.  Second preimage resistance in HIP is
	based on the hash algorithm strength and the length of the hash
	output used.  Through HIPv2 <xref target="RFC7401" />, format="default"/>, this resistance is 96 bits
	(less than the 128 bit 128-bit width of an IPv6 address field due to the
	presence of the ORCHID Overlay Routable Cryptographic Hash Identifiers (ORCHID) prefix <xref target="RFC7343" />). format="default"/>).  96 bits of resistance
	was considered acceptable strength during the design of HIP, HIP but may
	eventually be considered insufficient for the threat model of an
	envisioned deployment.  One possible mitigation would be to augment
	the use of HITs in the deployment with the HIs themselves (and
	mechanisms to securely bind the HIs to the HITs), so that the HI
	becomes the final authority.  It also may be possible to increase
	the difficulty of a brute force attack by making the generation of the
	HI more computationally difficult, such as the hash extension
	approach of SEND CGAs Secure Neighbor Discovery Cryptographically Generated Addresses (CGAs) <xref target="RFC3972" />, format="default"/>, although the HIP specifications
	through HIPv2 do not provide such a mechanism.  Finally, deployments
	that do not use ORCHIDs (such as certain types of overlay networks)
	might also use the full 128-bit width of an IPv6 address field for
	the HIT.</t>
      </section>
      <section title="Local anchor="lsi" numbered="true" toc="default">
        <name>Local Scope Identifier (LSI)" anchor="lsi"> (LSI)</name>
        <t>An LSI is a 32-bit localized representation for a Host
	Identity.
        Due to its size, it is suitable to be used for use in the existing sockets API in
	the place of IPv4 addresses (e.g., in sockaddr_in structure, sin_addr member) without modifying applications.
        The purpose of an LSI is to facilitate using Host
	Identities in existing APIs for IPv4-based
	applications.
        LSIs are never transmitted on the wire; when an application
        sends data using a pair of LSIs, the HIP layer (or sockets
        handler) translates the LSIs to the corresponding HITs, and
        vice versa for the receiving of data.
        Besides facilitating HIP-based connectivity for
	legacy IPv4 applications, the LSIs are beneficial in two other
	scenarios <xref target="RFC6538" />.</t> format="default"/>.</t>
        <t>In the first scenario, two IPv4-only applications are
        residing
        reside on two separate hosts connected by IPv6-only
        network. With HIP-based connectivity, the two applications are
        able to communicate despite of the mismatch in the protocol
        families of the applications and the underlying network. The
        reason is that the HIP layer translates the LSIs originating
        from the upper layers into routable IPv6 locators before
        delivering the packets on the wire.</t>
        <t>The second scenario is the same as the first one, but with
        the difference that one of the applications supports only
        IPv6. Now two obstacles hinder the communication between the
        application:
        applications: the addressing families of the two applications
        differ, and the application residing at the IPv4-only side is
        again unable to communicate because of the mismatch between
        addressing families of the application (IPv4) and network
        (IPv6). With HIP-based connectivity for applications, this
        scenario works; the HIP layer can choose whether to translate
        the locator of an incoming packet into an LSI or HIT.</t>
        <t>Effectively, LSIs improve IPv6 interoperability at the
        network layer as described in the first scenario and at the
        application layer as depicted in the second example. The
        interoperability mechanism should not be used to avoid
        transition to IPv6; the authors firmly believe in IPv6
        adoption and encourage developers to port existing IPv4-only
        applications to use IPv6. However, some proprietary,
        closed-source, IPv4-only applications may never see the
        daylight of IPv6, and the LSI mechanism is suitable for
        extending the lifetime of such applications even in IPv6-only
        networks.</t>
        <t>The main disadvantage of an LSI is its local
        scope. Applications may violate layering principles and pass
        LSIs to each other in application-layer protocols. As the LSIs
        are valid only in the context of the local host, they may
        represent an entirely different host when passed to another
        host. However, it should be emphasized here that the LSI
        concept is effectively a host-based NAT and does not introduce
        any more issues than the prevalent middlebox based middlebox-based NATs for
        IPv4. In other words, the applications violating layering
        principles are already broken by the NAT boxes that are
        ubiquitously deployed.</t>
      </section>
      <section title="Storing numbered="true" toc="default">
        <name>Storing Host Identifiers in directories"> Directories</name>
        <t>The public Host Identifiers should be stored in DNS; the
        unpublished Host Identifiers should not be stored anywhere
        (besides the communicating hosts themselves).  The (public) HI
        along with the supported HIHs are stored in a new RR Resource Record (RR) type.  This RR type
        is defined in the <xref target="RFC8005">HIP target="RFC8005" format="default">HIP DNS Extension</xref>.</t> extension</xref>.</t>
        <t>Alternatively, or in addition to storing Host Identifiers
        in the DNS, they may be stored in various other
        directories. For instance, a directory based on the
        Lightweight Directory Access Protocol (LDAP) or a Public Key
        Infrastructure (PKI) <xref target="RFC8002" /> format="default"/>  may be used.
        Alternatively, <xref target="RFC6537">Distributed target="RFC6537" format="default">Distributed Hash Tables (DHTs)</xref> have
        successfully been utilized <xref target="RFC6538" />. format="default"/>.  Such a
        practice may allow them to be used for purposes other than
        pure host identification.</t>
        <t>Some types of applications may cache and use Host
        Identifiers directly, while others may indirectly discover
        them through a symbolic host name (such as FQDN) a Fully Qualified Domain Name (FQDN)) look up from a
        directory. Even though Host Identities can have a
        substantially longer lifetime associated with them than
        routable IP addresses, directories may be a better approach to
        manage the lifespan of Host Identities. For example, an LDAP-based directory or DHT
        can be used for locally published identities whereas DNS
        can be more suitable for public advertisement.</t>
      </section>
    </section>
    <section anchor="sec-architecture" title="New stack architecture"> numbered="true" toc="default">
      <name>New Stack Architecture</name>
      <t>One way to characterize Host Identity is to compare the
      proposed HI-based architecture with the current one.
      <!-- As discussed above, the IP addresses can be seen to be a confounding of routing direction vectors and interface names. -->
      Using the
      terminology from the <xref target="nsrg-report">IRTF target="I-D.irtf-nsrg-report" format="default">IRTF
      Name Space Research Group Report</xref> and, e.g., the
      unpublished Internet-Draft
      document on <xref
      target="chiappa-endpoints">Endpoints target="chiappa-endpoints" format="default">"Endpoints and Endpoint Names </xref>, Names"</xref>,
      the IP addresses currently embody the dual role
      of locators and end-point endpoint identifiers.  That is, each IP address
      names a topological location in the Internet, thereby acting as
      a routing direction vector, or locator.  At the same time, the IP
      address names the physical network interface currently located
      at the point-of-attachment, thereby acting as a end-point an endpoint
      name.</t>
      <t>In the HIP architecture, the end-point endpoint names and locators are
      separated from each other.  IP addresses continue to act as
      locators.  The Host Identifiers take the role of end-point endpoint
      identifiers.  It is important to understand that the end-point endpoint
      names based on Host Identities are slightly different from
      interface names; a Host Identity can be simultaneously reachable
      through several interfaces.</t>
      <t>The difference between the bindings of the logical entities
      are illustrated in <xref target="figure-bindings"/>. target="fig-1"/>. The left side
      illustrates the current TCP/IP architecture and the right side the
      HIP-based architecture.</t>
      <figure anchor="figure-bindings">
	<artwork src="draft-ietf-hip-arch-1.gif" type="gif"> anchor="fig-1">

          <artwork><![CDATA[

Transport ---- Socket                Transport ------ Socket
association      |                   association        |
                 |                                      |
                 |                                      |
                 |                                      |
End-point
Endpoint         |                    End-point                     Endpoint --- Host Identity
         \       |                                      |
           \     |                                      |
             \   |                                      |
               \ |                                      |
Location --- IP address                Location --- IP address

        </artwork>

]]></artwork>
      </figure>
      <t>Architecturally, HIP provides for a different binding of
	transport-layer protocols.  That is, the transport-layer
	associations, i.e., TCP connections and UDP associations, are
	no longer bound to IP addresses but rather to Host
	Identities. In practice, the Host Identities are exposed as
	LSIs and HITs for legacy applications and the transport layer
	to facilitate backward compatibility with existing networking
	APIs and stacks.</t>
      <t>The HIP layer is logically located at layer Layer 3.5, between the
	transport and network layers, in the networking stack. It acts
	as shim layer for transport data utilizing LSIs or HITs, HITs but
	leaves other data intact. The HIP layer translates between the two
	forms of HIP identifiers originating from the transport layer
	into routable IPv4/IPv6 addresses for the network layer, layer and
	vice versa for the reverse direction.</t>
      <section title="On numbered="true" toc="default">
        <name>On the multiplicity Multiplicity of identities"> Identities</name>
        <t>A host may have multiple identities both at the client and
        server side. This raises some additional concerns that are
        addressed in this section.</t>

	<!-- Joel Harper:
    In section 5.1 paragraph 3, the text talks about a connecting client not
    specifying a responder identifier (HIP Opportunistic mode) in order to
    enable load balancing.  I think the text would be helped by an example of
    how an initiator might know to do this, rather than just not using HIP.
    Also, it would be good if the text was explicit as to whether or not there
    was a way to support load balancing / multi servers without either using a
    shared identity or sacrificing security by using Opportunistic HIP.
    -->

        <t>For security reasons, it may be a bad idea to duplicate the
        same Host Identity on multiple hosts because the compromise of
        a single host taints the identities of the other hosts.
        Management of machines with identical Host Identities may also
        present other challenges and, therefore, it is advisable to
        have a unique identity for each host.</t>
        <t>At the server side, utilizing DNS is a better alternative than a
	shared Host Identity to implement load balancing.  A single FQDN entry can be configured
	to refer to multiple Host Identities. Each of the FQDN entries
	can be associated with the related locators, locators or with a single
	shared locator in the case the servers are using the same HIP rendezvous server <xref
	target="sec:rvz" /> (<xref target="sec_rvz" format="default"/>) or HIP relay server <xref
	target="sec:relay" />.</t> (<xref target="sec_relay" format="default"/>).</t>
        <t>Instead of duplicating identities, HIP opportunistic mode
        can be employed, where the initiator Initiator leaves out the identifier
        of the responder Responder when initiating the key exchange and learns
        it upon the completion of the exchange. The tradeoffs trade-offs are
        related to lowered security guarantees, but a benefit of the
        approach is to avoid the publishing of Host Identifiers in any
        directories <xref target="komu-leap" />. format="default"/>. Since many public
        servers already employ DNS as their directory, opportunistic mode
        may be more suitable for, e.g, e.g., peer-to-peer connectivity.
	It is also worth noting that opportunistic mode is also required
        in practice when anycast IP addresses would be utilized as locators.</t>

        <t>HIP opportunistic mode could be utilized in association
	with HIP rendezvous servers or HIP relay servers <xref target="komu-diss" />. format="default"/>. In such a scenario, the Initiator sends
	an I1 message with a wildcard destination HIT to the locator of a HIP
	rendezvous/relay server. When the receiving rendezvous/relay server is
	serving multiple registered Responders, the server can choose
	the ultimate destination HIT, thus acting as a HIP based HIP-based load
	balancer. However, this approach is still experimental and
	requires further investigation.
        </t>
        <t>At the client side, a host may have multiple Host
        Identities, for instance, for privacy purposes. Another reason
        can be that the person utilizing the host employs different
        identities for different administrative domains as an extra
        security measure. If a HIP-aware middlebox, such as a
        HIP-based firewall, is on the path between the client and
        server, the user or the underlying system should carefully
        choose the correct identity to avoid the firewall to
        unnecessarily drop dropping HIP-based connectivity <xref target="komu-diss"
        />.</t> format="default"/>.</t>
        <t>Similarly, a server may have multiple Host Identities. For
        instance, a single web server may serve multiple different
        administrative domains. Typically, the distinction is
        accomplished based on the DNS name, but also the Host Identity
        could be used for this purpose. However, a more compelling
        reason to employ multiple identities are is the HIP-aware firewalls firewall
        that are is unable to see the HTTP traffic inside the encrypted
        IPsec tunnel. In such a case, each service could be configured
        with a separate identity, thus allowing the firewall to
        segregate the different services of the single web server from
        each other <xref target="lindqvist-enterprise" />.</t>

        <!--
	<t>It is possible that a single physical computer hosts
        several logical end-points.  With HIP, each of these
        end-points would have a distinct Host Identity.  Furthermore,
        since the transport associations are bound to Host Identities,
        HIP provides for process migration and clustered servers.
        That is, if a Host Identity is moved from one physical
        computer to another, it is also possible to simultaneously
        move all the transport associations without breaking them.
        Similarly, if it is possible to distribute the processing of a
        single Host Identity over several physical computers, HIP
        provides for cluster based services without any changes at the
        client end-point.</t> -->

      </section>
    </section>

    <?rfc needLines="8"?>

    <section anchor="control-plane" title="Control plane">

      <t>HIP decouples control and data plane from format="default"/>.</t>
      </section>
    </section>

    <section anchor="control-plane" numbered="true" toc="default">
      <name>Control Plane</name>
      <t>HIP decouples the control and data planes from each other. Two
      end-hosts initialize the control plane using a key
      exchange procedure called the base exchange. The procedure can
      be assisted by HIP specific HIP-specific infrastructural intermediaries called
      rendezvous or relay servers. In the event of IP address changes,
      the end-hosts sustain control plane connectivity with mobility
      and multihoming extensions. Eventually, the end-hosts terminate
      the control plane and remove the associated state.</t>
      <section title="Base exchange"> numbered="true" toc="default">
        <name>Base Exchange</name>
        <t>The base exchange is a key exchange procedure that
      authenticates the initiator Initiator and responder Responder to each other using
      their public keys. Typically, the initiator Initiator is the client-side
      host and the responder Responder is the server-side host. The roles are
      used by the state machine of a HIP implementation, implementation but then discarded
      upon successful completion.</t>
        <t>
      The exchange consists of four messages during which the hosts
      also create symmetric keys to protect the control plane with
      Hash-based message authentication codes Message Authentication Codes (HMACs). The
      keys can be also used to protect the data plane, and IPsec ESP
      <xref target="RFC7402" /> format="default"/> is typically used as the data-plane data plane protocol, albeit
      HIP can also accommodate others. Both the
      control and data plane planes are terminated using a closing procedure
      consisting of two messages.
        </t>
        <t>In addition, the base exchange also includes a computational puzzle <xref target="RFC7401" /> format="default"/> that the initiator Initiator must
      solve. The responder Responder chooses the difficulty of the puzzle puzzle, which
      permits the responder Responder to delay new incoming initiators Initiators according
      to local policies, for instance, when the responder Responder is under
      heavy load. The puzzle can offer some resiliency against DoS
      attacks because the design of the puzzle mechanism allows the
      responder
      Responder to remain stateless until the very end of the base
      exchange <xref target="aura-dos" />. format="default"/>. HIP puzzles have also been
      studied under steady-state DDoS attacks <xref target="beal-dos" />, format="default"/>, on multiple adversary models with varying
      puzzle difficulties <xref target="tritilanunt-dos" /> format="default"/>, and
      with ephemeral Host Identities <xref target="komu-mitigation" />. format="default"/>.
        </t>

      <!-- XX FIXME: MORE ON HICCUPS? -->

    </section>
      <section title="End-host mobility numbered="true" toc="default">
        <name>End-Host Mobility and multi-homing"> Multihoming</name>
        <t>HIP decouples the transport from the internetworking layer, layer
      and binds the transport associations to the Host Identities
      (actually through either the HIT or LSI). After the initial key
      exchange, the HIP layer maintains transport-layer connectivity
      and data flows using its extensions for <xref
      target="RFC8046">mobility</xref> target="RFC8046" format="default">mobility</xref> and <xref
      target="RFC8047">multihoming</xref> extensions. target="RFC8047" format="default">multihoming</xref>.
      Consequently, HIP can provide for a degree of internetworking
      mobility and multi-homing multihoming at a low infrastructure cost.  HIP
      mobility includes IP address changes (via any method) to either
      party.  Thus, a system is considered mobile if its IP address
      can change dynamically for any reason like PPP, DHCP, IPv6
      prefix reassignments, or a NAT device remapping its translation.
      Likewise, a system is considered multi-homed multihomed if it has more than
      one globally routable IP address at the same time.  HIP links IP
      addresses together, together when multiple IP addresses correspond to the
      same Host Identity. If one address becomes unusable, or a
      more preferred address becomes available, existing transport
      associations can easily be moved to another address.</t>
        <t>When a mobile node moves while communication is already on-going, ongoing,
      address changes are rather straightforward.
      The mobile node sends a HIP UPDATE packet to inform the
      peer of the new address(es), and the peer then verifies that the
      mobile node is reachable through these addresses. This way, the peer can
      avoid flooding attacks as further discussed in <xref target="ssec-flooding" />. format="default"/>.
        </t>
      </section>
      <section title="Rendezvous mechanism" anchor="sec:rvz"> anchor="sec_rvz" numbered="true" toc="default">
        <name>Rendezvous Mechanism</name>
        <t>Establishing a contact to a mobile, moving node is slightly
	more involved. In order to start the HIP exchange, the
	initiator
	Initiator node has to know how to reach the mobile node. For
	instance, the mobile node can employ Dynamic DNS <xref target="RFC2136" /> format="default"/> to update its reachability information in
	the DNS. To avoid the dependency to DNS, HIP provides its own
	HIP-specific alternative: the HIP rendezvous mechanism as
	defined in the <xref target="RFC8004">HIP Rendezvous
	specifications</xref>.</t> target="RFC8004" format="default">HIP rendezvous
	specification</xref>.</t>
        <t>Using the HIP rendezvous extensions, the mobile node keeps
        the rendezvous infrastructure continuously updated with its
        current IP address(es).  The mobile nodes trusts the
        rendezvous mechanism in order to properly maintain their HIT
        and IP address mappings.</t>
        <t>The rendezvous mechanism is especially useful in scenarios
	where both of the nodes are expected to change their address at the
	same time. In such a case, the HIP
	UPDATE packets will cross each other in the network and never
	reach the peer node.</t>
      </section>
      <section title="Relay mechanism" anchor="sec:relay"> anchor="sec_relay" numbered="true" toc="default">
        <name>Relay Mechanism</name>
        <t>The HIP relay mechanism <xref
        target="I-D.ietf-hip-native-nat-traversal" /> target="RFC9028" format="default"/> is an
        alternative to the HIP rendezvous mechanism. The HIP relay
        mechanism is more suitable for IPv4 networks with NATs because
        a HIP relay can forward all control and data plane
        communications in order to guarantee successful NAT
        traversal.</t>
      </section>
      <section title="Termination numbered="true" toc="default">
        <name>Termination of the control plane"> Control Plane</name>
        <t>The control plane between two hosts is terminated using
        a secure two-message exchange as specified in <xref
        target="RFC7401"> target="RFC7401" format="default"> base exchange
        specification</xref>. The
        related state (i.e. (i.e., host associations) should be removed upon
        successful termination.</t>
      </section>
    </section>
    <section anchor="esp" title="Data plane"> numbered="true" toc="default">
      <name>Data Plane</name>
      <t>The encapsulation format for the data
      plane used for carrying the application-layer traffic
      can be dynamically negotiated during the key
      exchange. For instance, <xref target="RFC6078">HICCUPS target="RFC6078" format="default">HICCUPS
      extensions</xref> define one way to transport application-layer
      datagrams directly over the HIP control plane, protected by
      asymmetric key cryptography. Also, SRTP Secure Real-time Transport Protocol (SRTP) has been considered as
      the data encapsulation protocol <xref target="hip-srtp"
      />. target="I-D.tschofenig-hiprg-hip-srtp" format="default"/>. However, the most widely implemented method is the
      Encapsulated Security Payload (ESP) <xref target="RFC7402" /> format="default"/> that is protected by
      symmetric keys derived during the key exchange. ESP Security
      Associations (SAs) offer both confidentiality and integrity
      protection, of which the former can be disabled during the key
      exchange. In the future, other ways of transporting
      application-layer data may be defined.</t>
      <t>The ESP SAs are established and terminated between the
      initiator
      Initiator and the responder Responder hosts. Usually, the hosts create at
      least two SAs, one in each direction (initiator-to-responder (Initiator-to-Responder SA
      and responder-to-initiator Responder-to-Initiator SA).  If the IP addresses of either
      host changes, the HIP mobility extensions can be used to
      re-negotiate
      renegotiate the corresponding SAs.</t>
      <t>On the wire, the difference in the use of identifiers between
      the HIP control and data plane planes is that the HITs are included in
      all control packets, but not in the data plane when ESP is
      employed. Instead, the ESP employs SPI Security Parameter Index (SPI) numbers that act as
      compressed HITs. Any HIP-aware middlebox (for instance, a
      HIP-aware firewall) interested in the ESP based ESP-based data plane
      should keep track between the control and data plane identifiers
      in order to associate them with each other.</t>

      <!--

      <t>HIP base exchange uses the cryptographic Host Identifiers

      <t>Since HIP does not negotiate any SA lifetimes, all lifetimes
      are subject to
      set up local policy.  The only lifetimes a pair of ESP Security Associations (SAs) to enable ESP
      in an end-to-end manner. While it would be possible, at least in
      theory, to use some existing cryptographic protocol, such as
      IKEv2 together with Host Identifiers, to establish the needed
      SAs, HIP defines a new protocol.  There implementation must
      support are a sequence number of
      historical reasons for this, rollover (for replay protection)
      and there are also a few
      architectural reasons.  First, IKE (and IKEv2) were not
      originally designed with middleboxes in mind.  As adding a new
      naming layer allows one to potentially add a new forwarding
      layer (see <xref target="nat" />, below), it is very important
      that the HIP provides mechanisms for middlebox
      authentication.</t>

      <t>Second, from a conceptual point of view, the IPsec Security
      Parameter Index (SPI) in ESP provides a simple compression of
      the HITs.  This does require per-HIT-pair SAs (and SPIs), and a
      decrease of policy granularity over other Key Management
      Protocols, such as IKE and IKEv2.  In other words, from an
      architectural point of view, HIP only supports host-to-host
      (or endpoint-to-endpoint) Security Associations.</t>

      <t>Originally, as HIP is designed for host usage, not for gateways or so
      called Bump-in-the-Wire (BITW) implementations, only ESP
      transport mode is supported.  An ESP SA pair is indexed by the
      SPIs and the two HITs (both HITs since a system can have more
      than one HIT).  The SAs need not to be bound to IP addresses;
      all internal control of the SA is by the HITs.  Thus, a host can
      easily change its address using Mobile IP, DHCP, PPP, or IPv6
      readdressing and still maintain the SAs.  Since the transports
      are bound to the SA (via an LSI or a HIT), any active transport
      is also maintained.  Thus, real-world conditions like loss of a
      PPP connection and its re-establishment or a mobile handover
      will not require a HIP negotiation or disruption of transport
      services <xref target="Bel1998" />.</t>

      <t>It should be noted that there are already BITW implementations
      of HIP providing virtual private network (VPN) services.
      This is still consistent to the SA bindings above.</t>
      -->

      <t>Since HIP does not negotiate any SA lifetimes, all lifetimes
      are subject to local policy.  The only lifetimes a HIP implementation must
      support are sequence number rollover (for replay protection),
      and SA timeout. An SA times out if no packets SA timeout. An SA times out if no packets are received using
      that SA. Implementations may support lifetimes for the various
      ESP transforms and other data-plane data plane protocols.</t>
    </section>
    <section anchor="nat" title="HIP numbered="true" toc="default">
      <name>HIP and NATs">

      <!-- * UDP encap vs. HIP-aware NAT --> NATs</name>

      <t>Passing packets between different IP addressing realms
      requires changing IP addresses in the packet header.  This may
      occur, for example, when a packet is passed between the public
      Internet and a private address space, or between IPv4 and IPv6
      networks.  The address translation is usually implemented as
      <xref target="RFC3022">Network target="RFC3022" format="default">Network Address Translation (NAT)</xref>
      or the historic <xref target="RFC2766"> NAT target="RFC2766" format="default">NAT Protocol translation Translation (NAT-PT)</xref>.</t>
      <t>In a network environment where identification is based on the
      IP addresses, identifying the communicating nodes is difficult
      when NATs are employed because private address spaces
      are overlapping. In other words, two hosts
      cannot be distinguished from each other solely based on their IP
      address.
      addresses. With HIP, the transport-layer end-points
      (i.e. endpoints
      (i.e., applications) are bound to unique Host Identities rather
      than overlapping private addresses. This allows
      two end-points endpoints to distinguish one other even when they are
      located in different private address realms. Thus, the IP addresses are used
      only for routing purposes and can be changed freely by NATs
      when a packet between two HIP capable HIP-capable hosts traverses through multiple
      private address realms.</t>
      <t><xref target="I-D.ietf-hip-native-nat-traversal">NAT target="RFC9028" format="default">NAT
      traversal extensions for HIP</xref> can be used to realize the
      actual end-to-end connectivity through NAT devices. To support
      basic backward compatibility with legacy NATs, the extensions
      encapsulate both HIP control and data plane planes in UDP. The
      extensions define mechanisms for forwarding the two planes
      through an intermediary host called HIP relay and procedures to
      establish direct end-to-end connectivity by penetrating
      NATs. Besides this "native" NAT traversal mode for HIP, other
      NAT traversal mechanisms have been successfully utilized, such
      as Teredo <xref target="RFC4380" /> format="default"/> (as described in further detail in <xref target="varjonen-split" />).</t> format="default"/>).</t>
      <t>Besides legacy NATs, a HIP-aware NAT has been designed and
      implemented <xref target="ylitalo-spinat" />. format="default"/>. For a HIP-based flow, a HIP-aware
      NAT or HIP-aware historic NAT-PT system tracks the mapping of HITs, and the
      corresponding ESP SPIs, to an IP address.  The NAT system has to
      learn mappings both from HITs and from SPIs to IP addresses.
      Many HITs (and SPIs) can map to a single IP address on a NAT,
      simplifying connections on address-poor NAT interfaces. The NAT
      can gain much of its knowledge from the HIP packets themselves;
      however, some NAT configuration may be necessary.</t>

      <!--
      <t>NAT systems cannot touch the datagrams within the ESP
      envelope, thus application-specific address translation must be
      done in the end systems. It should be noted that HIP provides
      for 'Distributed NAT', and uses the HIT or the LSI as a
      placeholder for embedded IP addresses.</t> -->

      <section title="HIP numbered="true" toc="default">
        <name>HIP and Upper-layer checksums"> Upper-Layer Checksums</name>
        <t>There is no way for a host to know if any of the IP
        addresses in an IP header are the addresses used to calculate
        the TCP checksum.  That is, it is not feasible to calculate
        the TCP checksum using the actual IP addresses in the pseudo
        header; the addresses received in the incoming packet are not
        necessarily the same as they were on the sending host.
        Furthermore, it is not possible to recompute the upper-layer
        checksums in the NAT/NAT-PT system, since the traffic is
        ESP protected.  Consequently, the TCP and UDP checksums are
        calculated using the HITs in the place of the IP addresses in
        the pseudo header.  Furthermore, only the IPv6 pseudo header
        format is used.  This provides for IPv4 / IPv6 protocol
        translation.</t>
      </section>
    </section>
    <section title="Multicast"> numbered="true" toc="default">
      <name>Multicast</name>
      <t>A number of studies investigating HIP-based multicast
      have been published (including <xref target="shields-hip" />, format="default"/>, <xref
      target="xueyong-hip" />, <xref target="xueyong-hip" />, target="zhu-hip" format="default"/>, <xref target="amir-hip" />, format="default"/>, <xref target="kovacshazi-host" /> format="default"/>, and
      <xref target="xueyong-secure" />). target="zhu-secure" format="default"/>). In particular, so-called Bloom filters,
      that
      which allow compressing the compression of multiple labels into small
      data structures, may be a promising way forward <xref target="sarela-bloom" />. format="default"/>. However, the different schemes have
      not been adopted by the HIP working group (nor the HIP research
      group in the IRTF), so the details are not further elaborated here.</t>
    </section>
    <section title="HIP policies"> numbered="true" toc="default">
      <name>HIP Policies</name>
      <t>There are a number of variables that influence the HIP
      exchange that each host must support.  All HIP implementations
      should support at least 2 two HIs, one to publish in DNS or a similar
      directory service and an unpublished one for anonymous usage
      (that should expect to be rotated frequently in order to disrupt
      linkability/trackability).
      linkability and/or trackability).  Although unpublished HIs will be
      rarely be used as responder Responder HIs, they are likely to be common for
      initiators.
      Initiators. As stated in <xref target="RFC7401" />, format="default"/>, "all HIP implementations MUST <bcp14>MUST</bcp14>
   support more than one simultaneous HI, at least one of which SHOULD <bcp14>SHOULD</bcp14>
   be reserved for anonymous usage", and "support for more than two HIs is RECOMMENDED". <bcp14>RECOMMENDED</bcp14>".
This
      provides new challenges for systems or users to decide which
      type of HI to expose when they start a new session.</t>
      <t>Opportunistic mode (where the initiator Initiator starts a HIP exchange
      without prior knowledge of the responder's Responder's HI) presents a
      security tradeoff. trade-off. At the expense of being subject to MITM MitM
      attacks, the opportunistic mode allows the initiator Initiator to learn
      the identity of the responder Responder during communication rather than
      from an external directory. Opportunistic mode can be used for
      registration to HIP-based services <xref target="RFC8003" /> (i.e. format="default"/> (i.e., utilized by HIP for
      its own internal purposes) or by the application layer <xref target="komu-leap" />. format="default"/>. For security reasons, especially the
      latter requires some involvement from the user to accept the
      identity of the responder Responder similar to how SSH the Secure Shell (SSH) protocol prompts the
      user when connecting to a server for the first time <xref target="pham-leap" />. format="default"/>. In practice, this can be realized
      in end-host based end-host-based firewalls in the case of legacy applications
      <xref target="karvonen-usable" /> format="default"/> or with <xref
      target="RFC6317">native target="RFC6317" format="default">native APIs for HIP APIs</xref> in the case of
      HIP-aware applications.</t>
      <t>As stated in <xref target="RFC7401" />, "Initiators MAY format="default"/>:
      </t>
<blockquote>Initiators <bcp14>MAY</bcp14> use a different HI for
      different Responders to provide basic privacy.  Whether such
      private HIs are used repeatedly with the same Responder, and how
      long these HIs are used, are decided by local policy and depend
      on the privacy requirements of the Initiator".
      </t> Initiator.</blockquote>
      <t>According to <xref target="RFC7401" />, "Responders format="default"/>:
      </t>
<blockquote>Responders that only
      respond to selected Initiators require an Access Control List
      (ACL), representing for which hosts they accept HIP base
      exchanges, and the preferred transport format and local
      lifetimes.  Wildcarding SHOULD <bcp14>SHOULD</bcp14> be supported for such ACLs, and
      also for Responders that offer public or anonymous services".
      </t> services.</blockquote>
    </section>
    <section title="Security considerations"> numbered="true" toc="default">
      <name>Security Considerations</name>
      <t>This section includes discussion on some issues and solutions
      related to security in the HIP architecture.</t>
      <section title="MiTM Attacks"> numbered="true" toc="default">
        <name>MitM Attacks</name>
        <t>HIP takes advantage of the Host Identity paradigm to
      provide secure authentication of hosts and to provide a fast key
      exchange for ESP.  HIP also attempts to limit the exposure of
      the host to various denial-of-service (DoS) and
      man-in-the-middle (MitM) attacks.  In so doing, HIP itself is
      subject to its own DoS and MitM attacks that potentially could
      be more damaging to a host's ability to conduct business as
      usual.</t>
        <t>Resource exhausting denial-of-service DoS attacks take advantage
      of the cost of setting up a state for a protocol on the
      responder
      Responder compared to the 'cheapness' on the initiator. Initiator.  HIP
      allows a responder Responder to increase the cost of the start of state on
      the initiator Initiator and makes an effort to reduce the cost to the
      responder.
      Responder.  This is done by having the responder Responder start the
      authenticated Diffie-Hellman exchange instead of the initiator, Initiator,
      making the HIP base exchange 4 four packets long. The first packet
      sent by the responder Responder can be prebuilt to further mitigate the
      costs. This packet also includes a computational puzzle that can
      optionally be used to further delay the initiator, Initiator, for instance,
      when the responder Responder is overloaded. The details are explained in
      the <xref target="RFC7401">base target="RFC7401" format="default">base exchange
      specification</xref>.</t>

      <!--
      <t>HIP optionally supports opportunistic negotiation. That is,
      if a host receives a start of transport without a HIP
      negotiation, it can attempt to force a HIP exchange before
      accepting the connection.  This has the potential for DoS
      attacks against both hosts.  If the method to force the start of
      HIP is expensive on either host, the attacker need only spoof a
      TCP SYN.  This would put both systems into the expensive
      operations.  HIP avoids this attack by having the responder send
      a simple R1 packet that it can pre-build.  Since this packet is
      fixed and easily replayed, the initiator only reacts to it if it
      has just started a connection to the responder.</t> -->

      <t>Man-in-the-middle (MitM)

      <t>MitM attacks are difficult to defend against, against
      without third-party authentication.  A skillful MitM could
      easily handle all parts of the HIP base exchange, but HIP
      indirectly provides the following protection from a MitM attack.
      If the responder's Responder's HI is retrieved from a signed DNS zone or
      securely obtained by some other means, the initiator Initiator can use this to
      authenticate the signed HIP packets.  Likewise, if the
      initiator's
      Initiator's HI is in a secure DNS zone, the responder Responder can
      retrieve it and validate the signed HIP packets.  However, since
      an initiator Initiator may choose to use an unpublished HI, it knowingly
      risks a MitM attack.  The responder Responder may choose not to accept a
      HIP exchange with an initiator Initiator using an unknown HI.</t>
        <t>Other types of MitM attacks against HIP can be mounted using
      ICMP messages that can be used to signal about problems. As an
      overall guideline, the ICMP messages should be considered as
      unreliable "hints" and should be acted upon only after
      timeouts. The exact attack scenarios and countermeasures are
      described in full detail in the <xref target="RFC7401">base target="RFC7401" format="default">base
      exchange specification</xref>.</t>
        <t>A MitM attacker could try to replay older I1 or R1 messages using weaker cryptographic algorithms as described in section 4.1.4 in <xref target="RFC7401" />. section="4.1.4" sectionFormat="of" format="default"/>.
      The base exchange has been augmented to deal with
      such an attack by restarting on detecting the detection of the attack.  At
      worst
      worst, this would only lead to a situation in which the
      base exchange would never finish (or would be aborted after
      some retries).  As a drawback, this leads to a 6-way six-way base
      exchange
      exchange, which may seem bad at first.  However, since this
      only occurs in an attack scenario and since the attack can
      be handled (so it is not interesting to mount anymore), we
      assume the subsequent messages do not represent a security threat. Since
      the MitM cannot be successful with a downgrade attack, these
      sorts of attacks will only occur as 'nuisance' attacks. So,
      the base exchange would still be usually just four packets
      even though implementations must be prepared to protect
      themselves against the downgrade attack.</t>
        <t>In HIP, the Security Association for ESP is indexed by the
      SPI; the source address is always ignored, and the destination
      address may be ignored as well.  Therefore, HIP-enabled
      Encapsulated Security Payload (ESP)  Therefore, HIP-enabled
      ESP is IP address independent.
      This might seem to make attacking easier, but ESP with
      replay protection is already as well protected as possible, and
      the removal of the IP address as a check should not increase the
      exposure of ESP to DoS attacks.</t>
      </section>
      <section anchor="ssec-flooding" title="Protection numbered="true" toc="default">
        <name>Protection against flooding attacks"> Flooding Attacks</name>
        <t>Although the idea of informing about address changes by
      simply sending packets with a new source address appears
      appealing, it is not secure enough.  That is, even if HIP does
      not rely on the source address for anything (once the base
      exchange has been completed), it appears to be necessary to
      check a mobile node's reachability at the new address before
      actually sending any larger amounts of traffic to the new
      address.</t>
        <t>Blindly accepting new addresses would potentially lead to
      flooding Denial-of-Service DoS attacks against third parties <xref target="RFC4225" />. format="default"/>.  In a distributed flooding attack attack, an
      attacker opens high volume high-volume HIP connections with a large number
      of hosts (using unpublished HIs), HIs) and then claims to all of
      these hosts that it has moved to a target node's IP address.
      If the peer hosts were to simply accept the move, the result
      would be a packet flood to the target node's address.  To
      prevent this type of attack, HIP mobility extensions include a return routability
      check procedure where the reachability of a node is separately
      checked at each address before using the address for larger
      amounts of traffic.</t>
        <t>A credit-based authorization approach <xref target="RFC8046"> for host mobility with the Host Identity Protocol</xref> "<xref target="RFC8046" format="title"/>" <xref target="RFC8046" format="default"/>
      can be used between hosts for sending data prior to completing the address
      tests. Otherwise, if HIP is used between two hosts that fully
      trust each other, the hosts may optionally decide to skip the
      address tests. However, such performance optimization must be
      restricted to peers that are known to be trustworthy and
      capable of protecting themselves from malicious software.</t>
      </section>
      <section title="HITs used numbered="true" toc="default">
        <name>HITs Used in ACLs"> ACLs</name>
        <t>At end-hosts, HITs can be used in IP-based access control
	lists at the application and network layers. At middleboxes,
	HIP-aware firewalls <xref target="lindqvist-enterprise" /> format="default"/> can use HITs or public
	keys to control both ingress and egress access to networks or
	individual hosts, even in the presence of mobile devices
	because the HITs and public keys are topology
	independent. As discussed earlier in <xref target="esp"
	/>, format="default"/>, once a HIP session has been established, the SPI value in
	an ESP packet may be used as an index, indicating the HITs.
	In practice, firewalls can inspect HIP packets to learn of the
	bindings between HITs, SPI values, and IP addresses.  They can
	even explicitly control ESP usage, dynamically opening ESP
	only for specific SPI values and IP addresses.  The signatures
	in HIP packets allow a capable firewall to ensure that the HIP
	exchange is indeed occurring between two known hosts.  This
	may increase firewall security.</t>
        <t>A potential drawback of HITs in ACLs is their 'flatness' 'flatness', which
	means they cannot be aggregated, and this could potentially
	result in larger table searches in HIP-aware firewalls. A
	way to optimize this could be to utilize Bloom filters for
	grouping of HITs <xref target="sarela-bloom" />. format="default"/>. However, it
	should be noted that it is also easier to exclude individual,
	misbehaving hosts out when the firewall rules concern
	individual HITs rather than groups.</t>

<!--   <t>[add here wildcarding]</t> -->

	<t>There has been considerable bad experience with distributed
	ACLs that contain public key material related material, to public keys, for example,
	with SSH.  If the owner of a key needs to revoke it for any
	reason, the task of finding all locations where the key is
	held in an ACL may be impossible.  If the reason for the
	revocation is due to private key theft, this could be a
	serious issue.</t>
        <t>A host can keep track of all of its partners that might use
	its HIT in an ACL by logging all remote HITs.  It should only
	be necessary to log responder Responder hosts.  With this information,
	the host can notify the various hosts about the change to the
	HIT.  There have been attempts to develop a secure method to
	issue the HIT revocation notice <xref target="zhang-revocation" />.</t> target="I-D.irtf-hiprg-revocation" format="default"/>.</t>
        <t>Some of the HIP-aware middleboxes, such as firewalls <xref target="lindqvist-enterprise" /> format="default"/> or NATs <xref target="ylitalo-spinat" />, format="default"/>, may observe the on-path traffic
        passively. Such middleboxes are transparent by their nature
        and may not get a notification when a host moves to a
        different network. Thus, such middleboxes should maintain soft
        state and timeout time out when the control and data plane planes between two
        HIP end-hosts has have been idle too long. Correspondingly, the two
        end-hosts may send periodically keepalives, such as UPDATE
        packets or ICMP messages inside the ESP tunnel, to sustain
        state at the on-path middleboxes.</t>
        <t>One general limitation related to end-to-end encryption is
        that middleboxes may not be able to participate to in the
        protection of data flows. While the issue may affect also affect
        other protocols, Heer at al et al. <xref target="heer-end-host"
        /> format="default"/> have analyzed the problem in the context of HIP. More
        specifically, when ESP is used as the data-plane data plane protocol for HIP, the
        association between the control and data plane planes is weak and can
        be exploited under certain assumptions. In the
        scenario, the attacker has already gained access to the target
        network protected by a HIP-aware firewall, but wants to
        circumvent the HIP-based firewall. To achieve this, the
        attacker passively observes a base exchange between two HIP
        hosts and later replays it. This way, the attacker manages to
        penetrate the firewall and can use a fake ESP tunnel to
        transport its own data. This is possible because the firewall
        cannot distinguish when the ESP tunnel is valid. As a
        solution, HIP-aware middleboxes may participate to in the control
        plane interaction by adding random nonce parameters to the
        control traffic, which the end-hosts have to sign to
        guarantee the freshness of the control traffic <xref
        target="heer-midauth" />. target="I-D.heer-hip-middle-auth" format="default"/>. As an alternative, extensions for
        transporting the data plane directly over the control plane can be
        used <xref target="RFC6078" />. format="default"/>.
        </t>

        <!--
	<t>HIP-aware NATs, however, are transparent to the HIP aware
	systems by design.  Thus, the host may find it difficult to
	notify any NAT that is using a HIT in an ACL.  Since most
	systems will know of the NATs for their network, there should
	be a process by which they can notify these NATs of the change
	of the HIT.  This is mandatory for systems that function as
	responders behind a NAT.  In a similar vein, if a host is
	notified of a change in a HIT of an initiator, it should
	notify its NAT of the change.  In this manner, NATs will be
	updated with the HIT change.</t> -->

    </section>
      <section title="Alternative numbered="true" toc="default">
        <name>Alternative HI considerations"> Considerations</name>
        <t>The definition of the Host Identifier states that the HI
	need not be a public key.  It implies that the HI could be any
	value;
	value, for example example, a FQDN.  This document does not describe
	how to support such a non-cryptographic HI, but examples of
	such protocol variants do exist (<xref target="urien-rfid" />, format="default"/>,
	<xref target="urien-rfid-draft" />). target="I-D.irtf-hiprg-rfid" format="default"/>).  A non-cryptographic HI
	would still offer the services of the HIT or LSI for NAT
	traversal.  It would be possible to carry HITs in HIP packets
	that had neither privacy nor authentication. Such schemes may
	be employed for resource constrained resource-constrained devices, such as small
	sensors operating on battery power, but are not further
	analyzed here.</t>
        <t>If it is desirable to use HIP in a low security low-security situation
	where public key computations are considered expensive, HIP
	can be used with very short Diffie-Hellman and Host Identity
	keys.  Such use makes the participating hosts vulnerable to
	MitM and connection hijacking attacks.  However, it does not
	cause flooding dangers, since the address check mechanism
	relies on the routing system and not on cryptographic
	strength.</t>
      </section>
      <section title="Trust On numbered="true" toc="default">
        <name>Trust on First Use"> Use</name>
        <t><xref target="RFC7435" /> format="default"/> highlights four design principles for
      Leap of Faith, or Trust On First Use (TOFU), protocols that apply also to opportunistic HIP:

      <list style="numbers">
	<t>Coexist

        </t>
        <ol spacing="normal" type="1">
          <li>Coexist with explicit policy</t>
	<t>Prioritize communication</t>
	<t>Maximize policy</li>
          <li>Prioritize communication</li>
          <li>Maximize security peer by peer</t>
	<t>No peer</li>
          <li>No misrepresentation of security</t>
      </list></t> security</li>
        </ol>
        <t>
	<!-- Coexist with explicit policy. Explicit security policies preempt OS. -->
	According to the first TOFU design principle, "opportunistic "Opportunistic
	security never displaces or preempts explicit policy". Some
	application data may be too sensitive, so the related policy
	could require authentication (i.e, (i.e., the
	public key or certificate) in such a case instead of the unauthenticated
	opportunistic mode. In practice, this has been realized in
      HIP implementations as follows <xref target="RFC6538" />.</t> format="default"/>.</t>
        <t>The OpenHIP implementation allowed an Initiator to use
      opportunistic mode
      only with an explicitly configured Responder IP address, when the
      Responder's HIT is unknown.
      At the Responder, OpenHIP had an option to allow
      opportunistic mode with any Initiator -- trust any Initiator.</t>
        <t>HIP for Linux (HIPL) developers experimented with more
      fine-grained policies operating at the application level. The HIPL
      implementation utilized so called so-called "LD_PRELOAD" hooking at the
      application layer that allowed a dynamically linked library to intercept socket-related calls
      without rebuilding the related application
      binaries. The library acted as a shim layer between
      the application and transport layers. The shim layer translated
      the non-HIP based non-HIP-based socket calls from the application into
      HIP-based socket calls. While the shim library involved some
      level of complexity as described in more detail in <xref target="komu-leap" />, format="default"/>, it achieved the goal of applying
      opportunistic mode at the granularity of
      individual applications.</t>

      <!-- <t>In addition to this, the implementations
      had also some simpler ways to enforce authentication with
      specific peers: if the HI of the peer was discovered in the DNS
      or locally the /etc/hosts file in Linux (as described in more
      detail in <xref target="RFC6538" />).
      </t> -->
      <!-- xx no cert experiments -->
      <t>
	<!-- Prioritize communication -->
	The second TOFU principle essentially states that communication
	should be first class citizen instead of prioritized over security. So
	opportunistic mode should be, in general, allowed even if no
	authentication is present, and even possibly a fallback to
	non-encrypted
	unencrypted communications could be allowed (if policy permits) instead of blocking communications.
	In practice, this can be realized in three
	steps. In the first step, a HIP Initiator can look up the HI of a
	Responder from a directory such as DNS. When the Initiator discovers a HI,
	it can use the HI for authentication and skip the rest of the
	following steps. In the second step, the Initiator can, upon failing to find a HI, try opportunistic mode
	with the Responder. In the third step, the
	Initiator can fall back to non-HIP based non-HIP-based communications upon
	failing with opportunistic mode if
	the policy allows it. This three step three-step model has been implemented successfully
        and described in more detail in <xref target="komu-leap" />. format="default"/>.
        </t>
        <t>
	<!-- Maximize security peer by peer -->
	The third TOFU principle suggests that security should be
	maximized, so that at least opportunistic security would be
	employed. The three step three-step model described earlier
	prefers authentication when it is available, e.g., via
	DNS records (and possibly even via DNSSEC when available) and falls
	back to opportunistic mode when no out-of-band credentials are
	available. As the last resort, fallback to non-HIP based non-HIP-based
	communications can be used if the policy allows it. Also,
	since perfect forward security secrecy (PFS) is explicitly mentioned
	in the third design principle, it is worth mentioning that
	HIP supports it.
        </t>
        <t>
	<!-- No misrepresentation of security -->
	The fourth TOFU principle states that users and non-interactive noninteractive
	applications should be properly informed about the level
	of security being applied. In practice, non-HIP aware non-HIP-aware
	applications would assume that no extra security is being applied,
	so misleading at least a non-interactive noninteractive application
	should not be possible. In the case of interactive desktop
	applications, system-level prompts have been utilized in
	earlier HIP experiments <xref target="karvonen-usable" />, format="default"/>
	<xref target="RFC6538" /> format="default"/> to guide the user about the
	underlying HIP-based security. In general, users in those experiments perceived when HIP-based security was being used versus not used.
	However, the users failed to
	notice the difference between opportunistic opportunistic, non-authenticated HIP and
	non-opportunistic
	non-opportunistic, authenticated HIP. The reason for this was that the
	opportunistic HIP (i.e. (i.e., lowered level of security)
	was not clearly indicated in the prompt. This provided a
	valuable lesson to further improve the user interface.</t>
        <t>
	In the case of HIP-aware applications, native sockets APIs for
	HIP as specified in <xref target="RFC6317" /> format="default"/> can be used
	to develop application-specific logic instead of using generic
	system-level prompting. In such a case, the application itself
	can directly prompt the user or otherwise manage the situation
	in other ways. In this case, also non-interactive noninteractive
	applications also can properly log the level of security being
	employed because the developer can now explicitly program the
	use of authenticated HIP, opportunistic HIP HIP, and plain-text
	communication.
        </t>
        <t>
	It is worth mentioning a few additional items discussed in <xref target="RFC7435" />. format="default"/>. Related to active attacks,
	HIP has built-in protection against cipher-suite down-grade ciphersuite downgrade
	attacks as described in detail in <xref target="RFC7401"
	/>. format="default"/>. In addition, pre-deployed certificates could be used to
	mitigate against active attacks in the case of opportunistic
	mode as mentioned in <xref target="RFC6538"/>. target="RFC6538" format="default"/>.
        </t>
        <t>Detection of peer capabilities is also mentioned in the TOFU
      context. As discussed in this section, the three-step model can
      be used to detect peer capabilities. A host can achieve the
      first step of authentication, i.e., discovery of a public key,
      via DNS, for instance. If the host found finds no keys, the host can then try
      opportunistic mode as the second step. Upon a timeout, the host
      can then proceed to the third step by falling back to non-HIP based non-HIP-based
      communications if the policy permits. This last step is based on
      an implicit timeout rather an explicit (negative) acknowledgment
      like in the case of DNS, so the user may conclude prematurely
      that the connectivity has failed. To speed up the detection
      phase by explicitly detecting if the peer supports opportunistic
      HIP, researchers have proposed TCP specific TCP-specific extensions
      <xref target="RFC6538"/>, target="RFC6538" format="default"/> <xref target="komu-leap" />. format="default"/>. In a
      nutshell, an Initiator sends simultaneously both an opportunistic I1 packet and
      the related TCP SYN datagram equipped with a special TCP option
      to a peer. If the peer supports HIP, it drops the
      SYN packet and responds with an R1. If the peer is HIP
      incapable, it drops the HIP packet (and the unknown TCP option)
      and responds with a TCP SYN-ACK. The benefit of the proposed
      scheme is faster, one round-trip fallback to non-HIP based
      communications. The drawback is that the approach is tied to TCP
      (IP-options were also considered, but do not work well with firewalls
      and NATs). Naturally, the approach does not work against active
      attacker, but opportunistic mode is not anyway supposed to protect
      against such an adversary.
      </t>

      <t>It is worth noting that while the use of opportunistic mode has some benefits related
      to incremental deployment, it does not achieve all the benefits
      of authenticated HIP <xref target="komu-diss" />. Namely,
      authenticated HIP supports persistent identifiers in the sense
      that hosts are identified with the same HI independently of
      their movement. Opportunistic HIP meets this goal only
      partially: after the first contact between two hosts, HIP can
      successfully sustain connectivity with its mobility management extensions,
      but problems emerge when the hosts close the HIP association and try to re-establish connectivity. As hosts
      can change their location, it is no longer guaranteed that the same IP
      address belongs to the same host. The same address
      can be temporally assigned to different hosts, e.g., due to the
      reuse of IP addresses (e.g., by a DHCP service), overlapping
      private address realms (see also the discussion on Internet
      transparency in <xref target="sec:benefits" />) or due to an
      attempted attack.
      <!--
      So when a user of a host establishes a
      new flow to the same IP address, the host should prompt the user
      if the HI corresponding to the IP has changed.-->
      </t>

      <!--
	  X detection The benefit of peer capability?
	    X the proposed
      scheme is a faster, one round-trip fallback (timeout)
	      X downgrade attacks
	      X consider active vs passive attacks
	    X to non-HIP-based
      communications. The drawback is that the approach is tied to TCP optimization
      (IP options were also considered, but do not pass firewalls) - IMPORTANT TOFU CAPABILITY DETECTION
	  * non-persistent identifiers (mobility)
	  * looses Internet transparency (NATs)
	  * even normal HIP work well with firewalls
      and NATs). Naturally, the approach does not work against an active
      attacker, but opportunistic mode is susceptible not supposed to active MaN attacks without DNSSEC

	    X HIP has protection against downgrade attacks protect
      against ciphersuites
	    X leap of faith security (hip exp report)
	       X mitigate using certificates
	       X or prompting

	  X tofu
	    X different models
	      X 1. Authenticated and encrypted communication
	      X 2. Unauthenticated and encrypted communication
	      X 3. Plaintext
	  x infrastructure communication (rvs)

	    X prompting to make such an adversary anyway.
        </t>
        <t>It is worth noting that while the user aware of security tradeoffs
	    X native api: opp mode: explicit, programmable
	  X legacy api:
	    X boeing LSI-opp
            X Ericsson?
	    X HIPL:
	      * system-level
	      X shim library: complex wrapping use of sockets API calls
      -->

    </section>

    </section>

    <section title="IANA considerations">
    <t> This document opportunistic mode has no actions for IANA.</t>
    </section>

    <section title="Acknowledgments">

      <t>For the people historically involved in some benefits related
      to incremental deployment, it does not achieve all the early stages benefits
      of
      HIP, see the Acknowledgments section authenticated HIP <xref target="komu-diss" format="default"/>. Namely,
      authenticated HIP supports persistent identifiers in the
      Host Identity Protocol specification.</t>

      <t>During sense
      that hosts are identified with the later stages same HI independent of this document, when the editing
      baton was transferred to Pekka Nikander, the comments from the
      early implementers and others, including Jari Arkko, Jeff AhrenHolz, Tom
      Henderson, Petri Jokela, Miika Komu, Mika Kousa, Andrew
      McGregor, Jan Melen, Tim Shepard, Jukka Ylitalo, Sasu Tarkoma,
      and Jorma Wall, were invaluable. Also, the comments from Lars Eggert,
      Spencer Dawkins, Dave Crocker and Erik Giesa were also useful.</t>

      <t>The authors want to express
      their special thanks to
      Tom Henderson, who took the burden of editing the document
      in response to IESG comments at movement. Opportunistic HIP meets this goal only
      partially: after the time first contact between two hosts, HIP can
      successfully sustain connectivity with its mobility management extensions,
      but problems emerge when both of the
      authors were busy doing other things.  Without his perseverance
      original document might have never made it as RFC4423.</t>

      <t>This main effort to update and move hosts close the HIP forward within association and try to reestablish connectivity. As hosts
      can change their location, it is no longer guaranteed that the
      IETF process owes its impetuous same IP
      address belongs to a number of HIP development
      teams. the same host. The authors are grateful for Boeing, Helsinki Institute
      for Information Technology (HIIT), NomadicLab of Ericsson, and same address
      can be temporally assigned to different hosts, e.g., due to the three universities: RWTH Aachen, Aalto and University
      reuse of
      Helsinki, for their efforts.  Without their collective efforts
      HIP would have withered as on the IETF vine as IP addresses (e.g., by a nice
      concept.</t>

      <t>Thanks DHCP service), the overlapping of
      private address realms (see also for Suvi Koskinen for her help with proofreading
      and with the reference jungle.</t> discussion on Internet
      transparency in <xref target="sec_benefits" format="default"/>), or due to an
      attempted attack.
        </t>

    </section>
    </section>
    <section numbered="true" toc="default">
      <name>IANA Considerations</name>
      <t> This document has no IANA actions.</t>
    </section>

    <section title="Changes numbered="true" toc="default">
      <name>Changes from RFC 4423"> 4423</name>
      <t>In a nutshell, the changes from <xref target="RFC4423"> target="RFC4423" format="default"> RFC
      4423</xref> are mostly editorial, including clarifications on
      topics described in a difficult way and omitting some of the
      non-architectural (implementation) details that are already
      described in other documents. A number of missing references to
      the literature were also added. New topics include the drawbacks
      of HIP, a discussion on 802.15.4 and MAC security, HIP for IoT scenarios, deployment
      considerations
      considerations, and a description of the base exchange.</t>
    </section>
  </middle>
  <back>
    <references title="Normative References">

      &RFC7343;
      &RFC7401;
      &RFC7402;
<!--      &RFC5203-bis; -->
     &RFC8003;
     &RFC8004;
      &RFC8005;
      <!-- &RFC5206-bis; -->
      &RFC8046;
      &RFC8002;
      &RFC5482;
<!--      &hip-nat; -->
      <!-- <?rfc include="reference.I-D.ietf-hip-multihoming.xml"?> -->
      &RFC8047;
      &RFC6079;
      &RFC7086;
      <?rfc include="reference.I-D.ietf-hip-native-nat-traversal.xml"?>
      <?rfc include="reference.I-D.ietf-hip-dex.xml"?>

<displayreference target="I-D.irtf-nsrg-report" to="nsrg-report"/>
<displayreference target="I-D.irtf-hiprg-revocation" to="zhang-revocation"/>
<displayreference target="I-D.irtf-hiprg-rfid" to="urien-rfid-draft"/>
<displayreference target="I-D.tschofenig-hiprg-hip-srtp" to="hip-srtp"/>
<displayreference target="I-D.henderson-hip-vpls" to="henderson-vpls"/>
<displayreference target="I-D.heer-hip-middle-auth" to="heer-midauth"/>

    <references>
      <name>References</name>
      <references>
        <name>Normative References</name>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7343.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7401.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7402.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8003.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8004.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8005.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8046.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8002.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5482.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8047.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6079.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7086.xml"/>

<reference anchor='RFC9028' target="https://www.rfc-editor.org/info/rfc9028">
<front>
<title>Native NAT Traversal Mode for the Host Identity Protocol</title>

<author initials='A' surname='Keränen' fullname='Ari Keränen'>
    <organization />
</author>

<author initials='J' surname='Melén' fullname='Jan Melén'>
    <organization />
</author>

<author initials='M' surname='Komu' fullname='Miika Komu' role='editor'>
    <organization />
</author>

<date month='July' year='2021' />

</front>
<seriesInfo name="RFC" value="9028"/>
<seriesInfo name="DOI" value="10.17487/RFC9028"/>
</reference>
      </references>

    <references title="Informative references">
      &RFC2136;
      &RFC2535;
      &RFC2766;
      &RFC3022;
      &RFC3102;
      &RFC3748;
<!--      &RFC4025; -->
      &RFC4225;
      &RFC4306;
      &RFC4423;
      &RFC5218;
      &RFC5338;
      &RFC5887;
      &RFC6078;
      &RFC6250;
      &RFC6281;
      &RFC6317;
      &RFC6537;
      &RFC6538;
      &RFC7435;
      &RFC4380;
      &RFC3972;

      <!-- &nsrg-report; -->
      <!-- &IEEE.802-15-4.2011; -->
<!-- Removed per Russ Housley IESG comment
      &I-D.ietf-hip-mm;
-->
      <references>
        <name>Informative References</name>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2136.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2766.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3022.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3102.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3748.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4033.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4225.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4423.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5218.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5338.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5887.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6078.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6250.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6281.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6317.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6537.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6538.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7296.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7435.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4380.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3972.xml"/>

<reference anchor="nsrg-report"> anchor="I-D.irtf-nsrg-report">
<front>
<title>What's In A Name:Thoughts Name: Thoughts from the NSRG</title>
<author initials="E" initials="E." surname="Lear" fullname="Eliot Lear"><organization/></author> Lear">
<organization>Cisco Systems</organization>
</author>
<author initials="R" initials="R." surname="Droms" fullname="Ralph Droms"><organization/></author> Droms">
<organization>Cisco Systems</organization>
</author>
<date month="September" day="22" year="2003"/>
        </front><seriesInfo
</front>
<seriesInfo name="Internet-Draft" value="draft-irtf-nsrg-report-10"/>
<format type="TXT" target="http://tools.ietf.org/id/draft-irtf-nsrg-report-10.txt"/> target="https://www.ietf.org/archive/id/draft-irtf-nsrg-report-10.txt"/>
</reference>

<reference anchor="IEEE.802-15-4.2011" target="http://standards.ieee.org/getieee802/download/802.15.4-2011.pdf"> anchor='hip-dex'>
<front>
         <title>Information technology - Telecommunications and information exchange between systems - Local and metropolitan area networks - Specific requirements - Part 15.4: Wireless Medium Access Control (MAC) and Physical Layer (PHY) Specifications
<title>HIP Diet EXchange (DEX)</title>

<author initials='R' surname='Moskowitz' fullname='Robert Moskowitz' role='editor'>
    <organization />
</author>

<author initials='R' surname='Hummen' fullname='Rene Hummen'>
    <organization />
</author>

<author initials='M' surname='Komu' fullname='Miika Komu'>
    <organization />
</author>

<date month='January' day='19' year='2021' />

</front>
  <seriesInfo name="Internet-Draft" value="draft-ietf-hip-dex-24" />
   <format type="TXT" target="https://www.ietf.org/archive/id/draft-ietf-hip-dex-24.txt" />

</reference>

        <reference anchor="IEEE.802.15.4" target="https://ieeexplore.ieee.org/document/9144691">
          <front>
            <title>IEEE Standard for Low-Rate Wireless Personal Area Networks (WPANs)</title>
         <author fullname="Institute of Electric and Electronic Engineers"><organization/></author> Networks</title>
            <author>
              <organization>IEEE</organization>
            </author>
            <date month="September" year="2011"/>
        </front><seriesInfo month="July" year="2020"/>
          </front>
            <seriesInfo name="IEEE" value="Standard 802.15.4"/>
            <seriesInfo name="DOI" value="10.1109/IEEESTD.2020.9144691"/>
        </reference>

        <reference anchor="chiappa-endpoints"> anchor="chiappa-endpoints" target="http://mercury.lcs.mit.edu/~jnc/tech/endpoints.txt">
          <front>
            <title>Endpoints and Endpoint Names: A Proposed Enhancement
          to the Internet Architecture</title>
            <author initials="J. N." initials="J." surname="Chiappa">
	    <organization />
              <organization/>
            </author>
            <date year="1999" /> year="1999"/>
          </front>
	<seriesInfo name="URL"
	  value="http://www.chiappa.net/~jnc/tech/endpoints.txt" />
	<format type="txt"
	  target="http://www.chiappa.net/~jnc/tech/endpoints.txt" />
        </reference>

        <reference anchor="Nik2001">
          <front>
            <title>Denial-of-Service, Address Ownership, and Early
	  Authentication in the IPv6 World</title>
            <author initials="P." surname="Nikander">
	    <organization />
              <organization/>
            </author>
            <date year="2002" /> year="2002"/>
          </front>
	<seriesInfo name="in Proceesings of"
	  value="Security Protocols, 9th
          <refcontent>9th International Workshop" />
	<seriesInfo name=""
	  value="Cambridge, UK, April 25-27 2001" />
	<seriesInfo name="LNCS" value="2467" />
	<seriesInfo name="pp." value="12-26" /> Workshop on Security Protocols, Security Protocols 2001, Lecture Notes in Computer Science, Vol. 2467, pp. 12-21, Springer</refcontent>
          <seriesInfo name="" value="Springer" />
	<format type="pdf"
	  target="http://www.tml.hut.fi/~pnr/publications/cam2001.pdf"
	  /> name="DOI" value="10.1007/3-540-45807-7_3"/>
        </reference>

        <reference anchor="IEEE.802-15-9"> anchor="IEEE.802.15.9">
          <front>
            <title>IEEE Draft Recommended Practice for Transort Transport of Key Management Protocol (KMP) Datagrams</title>
         <author fullname="Institute of Electric and Electronic Engineers"><organization/></author>
            <author>
              <organization>IEEE</organization>
            </author>
            <date month="May" year="2015"/>
        </front><seriesInfo name="IEEE" value="P802.15.9/D04"/>
      </reference>

      <!--
      <reference anchor="Bel1998">
	<front>
	  <title>EIDs, IPsec, and HostNAT</title>
	  <author initials="S." surname="Bellovin">
	    <organization />
	  </author>
	  <date year="1998" month="March" />
          </front>
            <seriesInfo name="in Proceedings of"
	  value="41th IETF, Los Angeles, CA" />
	<seriesInfo name="URL"
	  value="http://www1.cs.columbia.edu/~smb/talks/hostnat.pdf" />
	<format type="pdf"
	  target="http://www1.cs.columbia.edu/~smb/talks/hostnat.pdf"
	  /> name="IEEE" value="P802.15.9/D04"/>
        </reference>
      -->

      <reference anchor="urien-rfid">
          <front>
            <title>HIP-based RFID Networking Architecture</title>
            <author initials="P." surname="Urien"></author> surname="Urien">
              <organization/>
            </author>
            <author initials="H." surname="Chabanne"></author> surname="Chabanne">
              <organization/>
            </author>
            <author initials="C." surname="Pepin">
              <organization/>
            </author>
            <author initials="S." surname="Orga">
              <organization/>
            </author>
            <author initials="M." surname="Bouet"></author> surname="Bouet">
              <organization/>
            </author>
            <author initials="D.O." surname="de Cunha"></author> Cunha">
              <organization/>
            </author>
            <author initials="V." surname="Guyot"></author> surname="Guyot">
              <organization/>
            </author>
            <author initials="G." surname="Pujolle"></author> surname="Pujolle">
              <organization/>
            </author>
            <author initials="P." surname="Paradinas"></author> surname="Paradinas">
              <organization/>
            </author>
            <author initials="E." surname="Gressier"></author> surname="Gressier">
              <organization/>
            </author>
            <author initials="J.-F." surname="Susini"></author> surname="Susini">
              <organization/>
            </author>
            <date year="2007" month="July" /> year="2007"/>
          </front>
	<seriesInfo name="IFIP
          <refcontent>2007 IFIP International Conference on Wireless and Optical Communications Networks," value="DOI: 10.1109/WOCN.2007.4284140" /> Networks, pp. 1-5</refcontent>
            <seriesInfo name="DOI" value="10.1109/WOCN.2007.4284140"/>
        </reference>

        <reference anchor="komu-leap">
          <front>
            <title>Leap-of-Faith Security is Enough for IP Mobility</title>
            <author initials="M." surname="Komu"></author> surname="Komu">
              <organization/>
            </author>
            <author initials="J." surname="Lindqvist"></author> surname="Lindqvist">
              <organization/>
            </author>
            <date year="2009" month="January" /> month="January"/>
          </front>
        <seriesInfo name="6th Annual
            <refcontent>2009 6th IEEE Consumer Communications and Networking Conference IEEE CCNC 2009, Conference, Las Vegas, Nevada," value="" /> NV, USA, pp. 1-5</refcontent>
            <seriesInfo name="DOI" value="10.1109/CCNC.2009.4784729"/>
        </reference>

        <reference anchor="komu-diss">
          <front>
            <title>A Consolidated Namespace for Network Applications, Developers, Administrators and Users</title>
            <author initials="M." surname="Komu"></author> surname="Komu">
              <organization/>
            </author>
            <date year="2012" month="December" /> month="December"/>
          </front>
        <seriesInfo name="Dissertation,
          <refcontent>Dissertation, Aalto University, Espoo, Finland" value="ISBN: 978-952-60-4904-5 (printed), ISBN: 978-952-60-4905-2 (electronic). " /> Finland</refcontent>
            <seriesInfo name="ISBN" value="978-952-60-4904-5 (printed)"/>
            <seriesInfo name="ISBN" value="978-952-60-4905-2 (electronic)"/>
        </reference>

        <reference anchor="lindqvist-enterprise">
          <front>
            <title>Enterprise Network Packet Filtering for Mobile Cryptographic Identities</title>
            <author initials="J." surname="Lindqvist"></author> surname="Lindqvist">
              <organization/>
            </author>
            <author initials="E." surname="Vehmersalo"></author>
          <author initials="J." surname="Manner"></author> surname="Vehmersalo">
              <organization/>
            </author>
            <author initials="M." surname="Komu"></author> surname="Komu">
              <organization/>
            </author>
            <author initials="J." surname="Manner">
              <organization/>
            </author>
            <date year="2010" month="January-March" /> year="2010"/>
          </front>
        <seriesInfo name="International
          <refcontent>International Journal of Handheld Computing Research, 1 (1), 79-94," value="" /> Research (IJHCR), Vol. 1, Issue 1, pp. 79-94</refcontent>
          <seriesInfo name="DOI" value="10.4018/jhcr.2010090905"/>
        </reference>

        <reference anchor="aura-dos">
          <front>
          <title>DOS-resistant
            <title>DOS-Resistant Authentication with Client Puzzles</title>
            <author initials="T." surname="Aura"></author> surname="Aura">
              <organization/>
            </author>
            <author initials="P." surname="Nikander"></author> surname="Nikander">
              <organization/>
            </author>
            <author initials="J." surname="Leiwo"></author> surname="Leiwo">
              <organization/>
            </author>
            <date year="2001" month="April" /> month="September"/>
          </front>
        <seriesInfo name="8th
          <refcontent>8th International Workshop on Security Protocols, pages 170-177. Springer," value="" /> Security Protocols 2000, Lecture Notes in Computer Science, Vol. 2133, pp. 170-177, Springer</refcontent>
          <seriesInfo name="DOI" value="10.1007/3-540-44810-1_22"/>
        </reference>

        <reference anchor="beal-dos">
          <front>
            <title>Deamplification of DoS Attacks via Puzzles</title>
            <author initials="J." surname="Beal"></author> surname="Beal">
              <organization/>
            </author>
            <author initials="T." surname="Shephard"></author> surname="Shepard">
              <organization/>
            </author>
            <date year="2004" month="October" /> month="October"/>
          </front>
        <seriesInfo name="" value="" />
        </reference>

        <reference anchor="tritilanunt-dos">
          <front>
            <title>Examining the DoS Resistance of HIP</title>
            <author initials="S." surname="Tritilanunt"></author> surname="Tritilanunt">
              <organization/>
            </author>
            <author initials="C." surname="Boyd"></author> surname="Boyd">
              <organization/>
            </author>
            <author initials="E." surname="Foo"></author> surname="Foo">
              <organization/>
            </author>
            <author initials="J. M. G." surname="Nieto"></author> initials="J.M.G." surname="Nieto">
              <organization/>
            </author>
            <date year="2006" month="" /> year="2006"/>
          </front>
        <seriesInfo name="OTM Workshops (1), volume 4277 of
            <refcontent>On the Move to Meaningful Internet Systems 2006: OTM 2006 Workshops, Lecture Notes in Computer Science, pages 616-625,Springer" value="" /> Vol. 4277, pp. 616-625, Springer</refcontent>
            <seriesInfo name="DOI" value="10.1007/11915034_85"/>
        </reference>

        <reference anchor="komu-mitigation">
          <front>
            <title>Mitigation of Unsolicited Traffic Across Domains with Host Identities and Puzzles</title>
            <author initials="M." surname="Komu"></author> surname="Komu">
              <organization/>
            </author>
            <author initials="S." surname="Tarkoma"></author> surname="Tarkoma">
              <organization/>
            </author>
            <author initials="A." surname="Lukyanenko"></author> surname="Lukyanenko">
              <organization/>
            </author>
            <date year="2010" month="October" /> month="October"/>
          </front>
        <seriesInfo name="15th
          <refcontent>15th Nordic Conference on Secure IT Systems (NordSec 2010), Springer Systems, NordSec 2010, Lecture Notes in Computer Science, Volume Vol. 7127, pp. 33-48,"
                    value="ISBN: 978-3-642-27936-2" /> 33-48, Springer</refcontent>
            <seriesInfo name="ISBN" value="978-3-642-27936-2"/>
            <seriesInfo name="DOI" value="10.1007/978-3-642-27937-9_3"/>
        </reference>

        <reference anchor="varjonen-split">
          <front>
            <title>Secure and Efficient IPv4/IPv6 Handovers Using Host-Based Identifier-Location Split</title>
            <author initials="S." surname="Varjonen"></author> surname="Varjonen">
              <organization/>
            </author>
            <author initials="M." surname="Komu"></author> surname="Komu">
              <organization/>
            </author>
            <author initials="A." surname="Gurtov"></author> surname="Gurtov">
              <organization/>
            </author>
            <date year="2010" month="" /> year="2010"/>
          </front>
        <seriesInfo name="Journal
          <refcontent>Journal of Communications Software and Systems, 6(1), 2010," value="ISSN: 18456421" /> Vol. 6, Issue 1</refcontent>
          <seriesInfo name="ISSN" value="18456421"/>
          <seriesInfo name="DOI" value="10.24138/jcomss.v6i1.193"/>
        </reference>

        <reference anchor="ylitalo-spinat">
          <front>
            <title>SPINAT: Integrating IPsec into overlay routing</title> Overlay Routing</title>
            <author initials="J." surname="Ylitalo"></author> surname="Ylitalo">
              <organization/>
            </author>
            <author initials="P." surname="Salmela"></author> surname="Salmela">
              <organization/>
            </author>
            <author initials="H." surname="Tschofenig"></author> surname="Tschofenig">
              <organization/>
            </author>
            <date year="2005" month="September" /> year="2005"/>
          </front>
        <seriesInfo name="Proceedings of the First
          <refcontent>First International Conference on Security and Privacy for Emerging Areas in Communication Networks (SecureComm 2005). Networks, SECURECOMM'05, Athens, Greece. IEEE Computer Society, pages 315-326,"
                    value="ISBN: 0-7695-2369-2" /> Greece, pp. 315-326</refcontent>
          <seriesInfo name="ISBN" value="0-7695-2369-2"/>
          <seriesInfo name="DOI" value="10.1109/SECURECOMM.2005.53"/>
        </reference>

        <reference anchor="shields-hip">
          <front>
            <title>The HIP protocol for hierarchical multicast routing</title>
            <author initials="C." surname="Shields"></author> surname="Shields">
              <organization/>
            </author>
            <author initials="J. J." surname="Garcia-Luna-Aceves"></author> surname="Garcia-Luna-Aceves">
              <organization/>
            </author>
            <date year="1998" month="" /> year="1998"/>
          </front>
        <seriesInfo name="Proceedings
          <refcontent>Proceedings of the seventeenth annual ACM symposium on Principles of distributed computing, pages 257-266. ACM, New York, NY, USA," value="ISBN: 0-89791-977-7, DOI: 10.1145/277697.277744" /> pp. 257-266</refcontent>
          <seriesInfo name="ISBN" value="0-89791-977-7"/>
          <seriesInfo name="DOI" value="10.1145/277697.277744"/>
        </reference>

        <reference anchor="xueyong-hip"> anchor="zhu-hip">
          <front>
            <title>A Multicast Routing Algorithm Applied to HIP-Multicast Model</title>
            <author initials="Z." surname="Xueyong"></author> initials="X." surname="Zhu">
              <organization/>
            </author>
            <author initials="D." surname="Zhiguo"></author> initials="Z." surname="Ding">
              <organization/>
            </author>
            <author initials="W." surname="Xinling"></author> initials="X." surname="Wang">
              <organization/>
            </author>
            <date year="2011" month="" /> year="2011"/>
          </front>
        <seriesInfo name="Proceedings of the 2011
          <refcontent>2011 International Conference on Network Computing and Information Security - Volume 01 (NCIS '11), Vol. 1. IEEE Computer Society, Washington, DC, USA, pages 169-174,"
                    value ="DOI: 10.1109/NCIS.2011.42" /> Conference on Network Computing and Information Security, Guilin, China, pp. 169-174</refcontent>
          <seriesInfo name="DOI" value="10.1109/NCIS.2011.42"/>
        </reference>

        <reference anchor="amir-hip">
          <front>
            <title>Security and Trust of Public Key Cryptography for HIP and HIP Multicast</title>
            <author initials="K. C." surname="Amir"></author> initials="K." surname="Amir">
              <organization/>
            </author>
            <author initials="H." surname="Forsgren"></author> surname="Forsgren">
              <organization/>
            </author>
            <author initials="K." surname="Grahn"></author> surname="Grahn">
              <organization/>
            </author>
            <author initials="T." surname="Karvi"></author> surname="Karvi">
              <organization/>
            </author>
            <author initials="G." surname="Pulkkis"></author> surname="Pulkkis">
              <organization/>
            </author>
            <date year="2013" month="" /> year="2013"/>
          </front>
        <seriesInfo name="International
          <refcontent>International Journal of Dependable and Trustworthy Information Systems (IJDTIS), 2(3), 17-35,"
                    value="DOI: 10.4018/jdtis.2011070102" /> Vol. 2, Issue 3, pp. 17-35</refcontent>
          <seriesInfo name="DOI" value="10.4018/jdtis.2011070102"/>
        </reference>

        <reference anchor="kovacshazi-host">
          <front>
            <title>Host Identity Specific Multicast</title>
            <author initials="Z." surname="Kovacshazi"></author> surname="Kovacshazi">
              <organization/>
            </author>
            <author initials="R." surname="Vida"></author> surname="Vida">
              <organization/>
            </author>
            <date year="2007" month="" /> year="2007"/>
          </front>
        <seriesInfo name="International conference
          <refcontent>International Conference on Networking and Services (ICNS'06), IEEE Computer Society, Los Alamitos, CA, USA,"
                    value="http://doi.ieeecomputersociety.org/10.1109/ICNS.2007.66" /> (ICNS '07), Athens, Greece, pp. 1-1</refcontent>
          <seriesInfo name="DOI" value="10.1109/ICNS.2007.66"/>
        </reference>

        <reference anchor="xueyong-secure"> anchor="zhu-secure">
          <front>
            <title>A Secure Multicast Model for Peer-to-Peer and Access Networks Using the Host Identity Protocol</title>
            <author initials="Z." surname="Xueyong"></author> initials="X." surname="Zhu">
              <organization/>
            </author>
            <author initials="J. W." surname="Atwood"></author> surname="Atwood">
              <organization/>
            </author>
            <date year="2007" month="January" /> year="2007"/>
          </front>
        <seriesInfo name="Consumer
          <refcontent>2007 4th IEEE Consumer Communications and Networking Conference. CCNC 2007. 4th IEEE, Conference, Las Vegas, NV, USA, pages 1098,1102," value="DOI: 10.1109/CCNC.2007.221" /> 1098-1102</refcontent>
          <seriesInfo name="DOI" value="10.1109/CCNC.2007.221"/>
        </reference>

        <reference anchor="sarela-bloom">
          <front>
            <title>BloomCasting: Security in Bloom filter based multicast</title> Filter Based Multicast</title>
            <author initials="M." surname="Särelä"></author> surname="Särelä">
              <organization/>
            </author>
            <author initials="C." surname="Esteve Rothenberg"></author> Rothenberg">
              <organization/>
            </author>
            <author initials="A." surname="Zahemszky"></author> surname="Zahemszky">
              <organization/>
            </author>
            <author initials="P." surname="Nikander"></author> surname="Nikander">
              <organization/>
            </author>
            <author initials="J." surname="Ott"></author> surname="Ott">
              <organization/>
            </author>
            <date year="2012" /> year="2012"/>
          </front>
      <seriesInfo name=""
                  value="" />
      <seriesInfo name="Lecture
          <refcontent>Information Security Technology for Applications, NordSec 2010, Lecture Notes in Computer Science"
                  value="2012" />
      <seriesInfo name="" value="" />
      <seriesInfo name="pages" value="1-16" /> Science, Vol. 7127, pages 1-16, Springer</refcontent>
          <seriesInfo name="" value="Springer Berlin Heidelberg" />
      <format type=""
              target="http://dx.doi.org/10.1007/978-3-642-27937-9_1" /> name="DOI" value="10.1007/978-3-642-27937-9_1"/>
        </reference>

        <reference anchor="pham-leap">
          <front>
            <title>Security Analysis of Leap-of-Faith Protocols</title>
            <author initials="V." surname="Pham"></author> surname="Pham">
              <organization/>
            </author>
            <author initials="T." surname="Aura"></author> surname="Aura">
              <organization/>
            </author>
            <date year="2011" month="September" /> year="2012"/>
          </front>
        <seriesInfo name=" Seventh ICST
          <refcontent>7th International Conference on ICST Conference, Security and Privacy for Communication Networks," value="" /> Networks, SecureComm 2011, Lecture Notes of the Institute for Computer Sciences, Social Informatics and Telecommunications Engineering, Vol. 96</refcontent>
          <seriesInfo name="DOI" value="10.1007/978-3-642-31909-9_19"/>
        </reference>

        <reference anchor="karvonen-usable">
          <front>
            <title>Usable Security Management security management with Host Identity Protocol</title> host identity protocol</title>
            <author initials="K." surname="Karvonen"></author> surname="Karvonen">
              <organization/>
            </author>
            <author initials="M." surname="Komu"></author> surname="Komu">
              <organization/>
            </author>
            <author initials="A." surname="Gurtov"></author> surname="Gurtov">
              <organization/>
            </author>
            <date year="2009" month="" /> year="2009"/>
          </front>
        <seriesInfo name="7th ACS/IEEE
          <refcontent>2009 IEEE/ACS International Conference on Computer Systems and Applications," value="(AICCSA-2009)" /> Applications, pp. 279-286</refcontent>
          <seriesInfo name="DOI" value="10.1109/AICCSA.2009.5069337"/>
        </reference>

        <reference anchor="ylitalo-diss">
          <front>
            <title>Secure Mobility at Multiple Granularity Levels over Heterogeneous Datacom Networks</title>
            <author initials="J." surname="Ylitalo"></author> surname="Ylitalo">
              <organization/>
            </author>
            <date year="2008" month="" /> year="2008"/>
          </front>
        <seriesInfo name="Dissertation,
          <refcontent>Dissertation, Helsinki University of Technology, Espoo, Finland" value="ISBN 978-951-22-9531-9" /> Finland</refcontent>
          <seriesInfo name="ISBN" value="978-951-22-9531-9"/>
        </reference>

        <reference anchor="xin-hip-lib">
          <front>
            <title>Host Identity Protocol Version 2.5</title>
            <author initials="G." surname="Xin"></author> surname="Xin">
              <organization/>
            </author>
            <date year="2012" month="June" /> month="June"/>
          </front>
       <seriesInfo name="Master's
          <refcontent>Master's Thesis, Aalto University, Espoo, Finland," value="" /> Finland</refcontent>
        </reference>

        <reference anchor="schuetz-intermittent">
          <front>
            <title>Protocol enhancements for intermittently connected hosts</title>
            <author initials="S." surname="Schütz"></author> surname="Schütz">
              <organization/>
            </author>
            <author initials="L." surname="Eggert"></author> surname="Eggert">
              <organization/>
            </author>
            <author initials="S." surname="Schmid"></author> surname="Schmid">
              <organization/>
            </author>
            <author initials="M." surname="Brunner"></author> surname="Brunner">
              <organization/>
            </author>
            <date year="2005" month="July" /> month="July"/>
          </front>
          <refcontent>ACM SIGCOMM Computer Communication Review, Vol. 35, Issue 3, pp. 5-18</refcontent>
          <seriesInfo name="SIGCOMM Comput. Commun. Rev., 35(3):5-18," value="" /> name="DOI" value="10.1145/1070873.1070875"/>
        </reference>

        <reference anchor="paine-hip">
          <front>
            <title>Beyond HIP: The End to Hacking As We Know It</title>
            <author initials="R. H." surname="Paine"></author> surname="Paine">
              <organization/>
            </author>
            <date year="2009" month="" /> year="2009"/>
          </front>
          <refcontent>BookSurge Publishing</refcontent>
          <seriesInfo name="BookSurge Publishing," value="ISBN: 1439256047, 9781439256046" /> name="ISBN-10" value="1439256047"/>
          <seriesInfo name="ISBN-13" value="978-1439256046"/>
        </reference>

        <reference anchor="leva-barriers"> anchor="levae-barriers">
          <front>
            <title>Adoption Barriers barriers of Network-layer Protocols: network layer protocols: the Case case of Host Identity Protocol</title> host identity protocol</title>
            <author initials="A. K. T." surname="Levä"></author> initials="T." surname="Levä">
              <organization/>
            </author>
            <author initials="M." surname="Komu"></author> surname="Komu">
              <organization/>
            </author>
            <author initials="S." surname="Luukkainen"></author> surname="Luukkainen">
              <organization/>
            </author>
            <date year="2013" month="March" /> month="March"/>
          </front>
          <refcontent>Computer Networks, Vol. 57, Issue 10, pp. 2218-2232</refcontent>
          <seriesInfo name="The International Journal of Computer and Telecommunications Networking," value="ISSN: 1389-1286" /> name="ISSN" value="1389-1286"/>
	  <seriesInfo name="DOI" value="10.1016/j.comnet.2012.11.024"/>
        </reference>

        <reference anchor="heer-end-host">
          <front>
          <title>End-host
            <title>End-Host Authentication and Authorization for Middleboxes based Based on a Cryptographic Namespace</title>
            <author initials="T." surname="Heer"></author> surname="Heer">
              <organization/>
            </author>
            <author initials="R." surname="Hummen"></author> surname="Hummen">
              <organization/>
            </author>
            <author initials="M." surname="Komu"></author> surname="Komu">
              <organization/>
            </author>
            <author initials="S." surname="Götz"></author> surname="Gotz">
              <organization/>
            </author>
            <author initials="K." surname="Wehre"></author> surname="Wehrle">
              <organization/>
            </author>
            <date year="2009" month="" /> year="2009"/>
          </front>
          <refcontent>2009 IEEE International Conference on Communications</refcontent>
          <seriesInfo name="ICC2009 Communication and Information Systems Security Symposium," value="" /> name="DOI" value="10.1109/ICC.2009.5198984"/>
        </reference>

        <reference anchor="komu-cloud">
          <front>
            <title>Secure Networking for Virtual Machines in the Cloud</title>
            <author initials="M." surname="Komu"></author> surname="Komu">
              <organization/>
            </author>
            <author initials="M." surname="Sethi"></author> surname="Sethi">
              <organization/>
            </author>
            <author initials="R." surname="Mallavarapu"></author> surname="Mallavarapu">
              <organization/>
            </author>
            <author initials="H." surname="Oirola"></author> surname="Oirola">
              <organization/>
            </author>
            <author initials="R." surname="Khan"></author> surname="Khan">
              <organization/>
            </author>
            <author initials="S." surname="Tarkoma"></author> surname="Tarkoma">
              <organization/>
            </author>
            <date year="2012" month="September" />
          </front>
        <seriesInfo name="International Workshop
          <refcontent>2012 IEEE International Conference
              on Power and QoS Aware Cluster Computing (PQoSCom2012), IEEE," value="ISBN: 978-1-4244-8567-3" />
      </reference>

      <reference anchor="zhang-revocation">
	<front>
	  <title>Host Identifier Revocation in HIP</title>
	  <author initials="D." surname="Zhang"></author>
	  <author initials="D." surname="Kuptsov"></author>
	  <author initials="S." surname="Shen"></author>
	  <date year="2012" month="Mar" />
	</front>
	<seriesInfo name="IRTF Working draft" value="draft-irtf-hiprg-revocation-05"/>
      </reference>

      <reference anchor="urien-rfid-draft">
	<front>
	  <title>HIP support for RFIDs</title>
	  <author initials="P." surname="Urien"></author>
	  <author initials="G." surname="Lee"></author>
	  <author initials="G." surname="Pujolle"></author>
	  <date year="2013" month="April" />
	</front>
	<seriesInfo name="IRTF Working draft" value="draft-irtf-hiprg-rfid-07"/>
      </reference>

      <reference anchor="hip-srtp">
	<front>
	  <title>Using SRTP transport format with HIP</title>
	  <author initials="H." surname="Tschofenig"></author>
	  <author initials="F." surname="Muenz"></author>
	  <author initials="M." surname="Shanmugam"></author>
	  <date year="2005" month="October" />
	</front> Workshops, pp. 88-96</refcontent>
          <seriesInfo name="Working draft" value="draft-tschofenig-hiprg-hip-srtp-01"/> name="DOI" value="10.1109/ClusterW.2012.29"/>
        </reference>

<xi:include href="https://datatracker.ietf.org/doc/bibxml3/reference.I-D.irtf-hiprg-revocation-05.xml"/>

<xi:include href="https://datatracker.ietf.org/doc/bibxml3/reference.I-D.irtf-hiprg-rfid-07.xml"/>

<reference anchor="henderson-vpls"> anchor="I-D.tschofenig-hiprg-hip-srtp">
<front>
	  <title>HIP-based Virtual Private LAN Service (HIPLS)</title>
<title>Using SRTP transport format with HIP</title>
<author initials="T." surname="Henderson"></author> initials="H." surname="Tschofenig" fullname="Hannes Tschofenig">
   <organization />
</author>
<author initials="D." surname="Mattes"></author>
	  <date year="2013" month="Dec" initials="M." surname="Shanmugam" fullname="Murugaraj Shanmugam">
   <organization />
</author>
<author initials="F." surname="Muenz" fullname="Franz Muenz">
   <organization/>
</author>
<date month="October" day="25" year="2006"/>
</front>
<seriesInfo name="Working draft" value="draft-henderson-hip-vpls-07"/> name="Internet-Draft" value="draft-tschofenig-hiprg-hip-srtp-02"/>
<format type="TXT" target="https://www.ietf.org/internet-drafts/draft-tschofenig-hiprg-hip-srtp-02.txt"/>
</reference>

<xi:include href="https://datatracker.ietf.org/doc/bibxml3/reference.I-D.henderson-hip-vpls.xml"/>

<reference anchor="heer-midauth"> anchor="I-D.heer-hip-middle-auth">
<front>
<title>End-Host Authentication for HIP Middleboxes</title>
<author initials="T." surname="Heer"></author> fullname="Tobias Heer" role="editor">
   <organization />
</author>
<author initials="M." surname="Komu"></author>
	  <date year="2009" month="September" fullname="Rene Hummen">
   <organization />
</author>
<author fullname="Klaus Wehrle">
   <organization />
</author>
<author fullname="Miika Komu">
   <organization />
</author>
<date month="October" day="31" year="2011"/>
</front>
<seriesInfo name="Working draft" value="draft-heer-hip-middle-auth-02"/> name="Internet-Draft" value="draft-heer-hip-middle-auth-04"/>
<format type="TXT" target="https://www.ietf.org/internet-drafts/draft-heer-hip-middle-auth-04.txt"/>
</reference>

        <reference anchor="hummen">
          <front>
            <title>Slimfit - A HIP DEX Compression Layer compression layer for the IP-based Internet of Things</title>
            <author initials="R." surname="Hummen"></author> surname="Hummen">
              <organization/>
            </author>
            <author initials="J." surname="Hiller"></author> surname="Hiller">
              <organization/>
            </author>
            <author initials="M." surname="Henze"></author> surname="Henze">
              <organization/>
            </author>
            <author initials="K." surname="Wehrle"></author> surname="Wehrle">
              <organization/>
            </author>
            <date year="2013" month="October" /> month="October"/>
          </front>
       <seriesInfo name="Wireless
          <refcontent>2013 IEEE 9th International Conference on Wireless and Mobile Computing, Networking and Communications (WiMob), 2013 IEEE 9th International Conference on , page 259-266." value="DOI: 10.1109/WiMOB.2013.6673370" /> pp. 259-266</refcontent>
          <seriesInfo name="DOI" value="10.1109/WiMOB.2013.6673370"/>
        </reference>

        <reference anchor="camarillo-p2psip">
          <front>
            <title>Reducing delays related to NAT traversal in P2PSIP session establishments</title>
            <author initials="G." surname="Camarillo"></author> surname="Camarillo">
              <organization/>
            </author>
            <author initials="J." surname="Mäenpää"></author> surname="Mäenpää">
              <organization/>
            </author>
            <author initials="A." surname="Keränen"></author> surname="Keränen">
              <organization/>
            </author>
            <author initials="V." surname="Anderson"></author> surname="Anderson">
              <organization/>
            </author>
            <date year="2011" month="" /> year="2011"/>
          </front>
        <seriesInfo name="IEEE
          <refcontent>IEEE Consumer Communications and Networking Conference (CCNC), pp. 549-553" value="DOI: 10.1109/CCNC.2011.5766540" /> 549-553</refcontent>
          <seriesInfo name="DOI" value="10.1109/CCNC.2011.5766540"/>
        </reference>

        <reference anchor="ranjbar-synaptic">
          <front>
            <title>SynAPTIC: Secure and Persistent Connectivity for Containers</title>
            <author initials="A." surname="Ranjbar"></author> surname="Ranjbar">
              <organization/>
            </author>
            <author initials="M." surname="Komu"></author> surname="Komu">
              <organization/>
            </author>
            <author initials="P." surname="Salmela"></author> surname="Salmela">
              <organization/>
            </author>
            <author initials="T." surname="Aura"></author> surname="Aura">
              <organization/>
            </author>
            <date year="2017" month="" /> year="2017"/>
          </front>
        <seriesInfo name="2017
          <refcontent>2017 17th IEEE/ACM International Symposium on Cluster, Cloud and Grid Computing (CCGRID), Madrid, 2017, pp. 262-267" value="doi: 10.1109/CCGRID.2017.62" /> 262-267</refcontent>
          <seriesInfo name="DOI" value="10.1109/CCGRID.2017.62"/>
        </reference>

        <reference anchor="tempered-networks">
          <front>
            <title>Identity-Defined Network (IDN) Architecture: Unified, Secure Networking Made Simple</title>
          <author fullname="Tempered Networks"></author>
            <author>
              <organization>Tempered Networks</organization>
            </author>
            <date year="2016" month="" /> year="2016"/>
          </front>
        <seriesInfo name="White Paper" value="" />
          <refcontent>White Paper</refcontent>
        </reference>

        <reference anchor="hip-lte">
          <front>
            <title>Novel secure VPN architectures for LTE backhaul networks</title>
            <author initials="M." surname="Liyanage"></author>
          <author initials="P." surname="Kumar"></author>
          <author initials="M." surname="Ylianttila"></author>
          <author initials="A." surname="Gurtov"></author>
          <date year="2015" month="November" />
        </front>
        <seriesInfo name="Security and Communication Networks" value="DOI 10.1002/sec.1411" />
      </reference>

<!--
      <reference anchor="xx">
        <front>
          <title>xx</title>
          <author initials="." surname=""></author>
          <author initials="." surname=""></author>
          <author initials="." surname=""></author>
          <author initials="." surname=""></author>
          <date year="" month="" />
        </front>
        <seriesInfo name="" value="" />
      </reference>
-->

<!--

     <reference anchor="herborn-secure">
       <front>
         <title>"Secure Host Identity Delegation for Mobility," Communication Systems Software and Middleware</title>
         <author initials="S." surname="Herborn"></author>
         <author initials="A." surname="Huber"></author>
         <author initials="R." surname="Boreli"></author>
         <author initials="A." surname="Seneviratne"></author>
          <date year="2007" month="January" />
       </front>
       <seriesInfo name="Communication Systems Software and Middleware. COMSWARE 2007. pages 1, 9," value="DOI: 10.1109/COMSWA.2007.382596" />
     </reference>

     <reference anchor="nikander-hip">
       <front>
         <title> Integrating security, mobility, and multi-homing in a HIP way</title> surname="Liyanage">
              <organization/>
            </author>
            <author initials="P." surname="Nikander"></author>
         <author initials="J." surname="Ylitalo"></author>
         <author initials="J." surname="Wall"></author>
          <date year="2003" month="February" />
       </front>
       <seriesInfo name="Proceedings of the 10th Annual Network and Distributed System Security Symposium (NDSS 2003). San Diego, CA, USA. Internet Society, pages 87-99,"
                   value="ISBN 1-891562-16-9" />
     </reference>

     <reference anchor="caesar-routing">
       <front>
         <title>Rofl: routing on flat labels</title>
         <author initials="M." surname="Caesar"></author>
          <author initials="T." surname="Condie"></author>
          <author initials="J." surname="Kannan"></author>
          <author initials="K." surname="Lakshminarayanan"></author>
          <author initials="I." surname="Stoica"></author>
          <date year="2006" month="" />
       </front>
       <seriesInfo name="Proceedings of the 2006 conference on Appli-
                         cations, technologies, architectures, and protocols for computer communi-
                         cations, SIGCOMM '06, pages 363-374, ACM, New York, NY, USA, 2006," value="" />
     </reference>

      <reference anchor="saltzer-notes">
        <front>
          <title>Naming and Binding of Objects In Operating Systems</title>
          <author initials="J." surname="Saltzer"></author>
          <date year="1978" month="" />
        </front>
        <seriesInfo name="Lecture Notes in Computer Science, Vol. 60. Springer-Verlag," value="" />
      </reference>

      <reference anchor="saltzer-end">
        <front>
          <title>End-to-end Arguments in System Design</title>
          <author initials="J. H." surname="Saltzer"></author> surname="Kumar">
              <organization/>
            </author>
            <author initials="D. P." surname="Reed"></author>
          <author initials="D.  D." surname="Clark"></author>
          <date year="1984" month="November" />
        </front>
        <seriesInfo name="ACM Trans. Comput. Syst., 2(4):277-288," value="" />
      </reference>

      <reference anchor="shoch-naming">
        <front>
          <title>Inter-Network Naming, Addressing, and Routing</title> initials="M." surname="Ylianttila">
              <organization/>
            </author>
            <author initials="J." surname="Shoch"></author> initials="A." surname="Gurtov">
              <organization/>
            </author>
            <date year="1978" month="" /> year="2016" month="January"/>
          </front>
          <refcontent>Security and Communication Networks, Vol. 9, pp. 1198-1215</refcontent>
          <seriesInfo name="IEEE Proc. COMPCON, pages 72-79. IEEE," value="" /> name="DOI" value="10.1002/sec.1411"/>
        </reference>

-->
    </references>

    <!-- appendix -->
    </references>

    <section title="Design considerations"> numbered="true" toc="default">
      <name>Design Considerations</name>
      <section title="Benefits anchor="sec_benefits" numbered="true" toc="default">
        <name>Benefits of HIP" anchor="sec:benefits"> HIP</name>
        <t>In the beginning, the network layer protocol (i.e., IP) had
      the following four "classic" invariants:

        <list style="numbers">

	  <t>Non-mutable:

        </t>
        <ol spacing="normal" type="1">
          <li>Non-mutable: The address sent is the address
	  received.</t>

	  <t>Non-mobile:
	  received.</li>
          <li>Non-mobile: The address doesn't change during the course
          of an "association".</t>

	  <t>Reversible: "association".</li>
          <li>Reversible: A return header can always be formed by
          reversing the source and destination addresses.</t>

	  <t>Omniscient: addresses.</li>
          <li>Omniscient: Each host knows what address a partner host
          can use to send packets to it.</t>

	</list>
      </t> it.</li>
        </ol>
        <t>Actually, the fourth can be inferred from 1 and 3, but it is
      worth mentioning explicitly for reasons that will be obvious soon if not
      already.</t>
        <t>In the current "post-classic" world, we are intentionally
      trying to get rid of the second invariant (both for mobility and
      for multi-homing), multihoming), and we have been forced to give up the first
      and the fourth.  <xref target="RFC3102">Realm target="RFC3102" format="default">Realm Specific IP</xref>
      is an attempt to reinstate the fourth invariant without the
      first invariant.  IPv6 is attempts to reinstate the first
      invariant.</t>
        <t>Few client-side systems on the Internet have DNS names that are
      meaningful. That is, if they have a Fully Qualified Domain Name
      (FQDN), that name typically belongs to a NAT device or a dial-up
      server, and does not really identify the system itself but its
      current connectivity. FQDNs (and their extensions as email
      names) are application-layer names; more frequently naming
      services than particular systems.  This is why many systems on
      the Internet are not registered in the DNS; they do not have
      services of interest to other Internet hosts.</t>
        <t>DNS names are references to IP addresses.  This only
      demonstrates the interrelationship of the networking and
      application layers.  DNS, as the Internet's only deployed and
      distributed database, is also the repository of other namespaces,
      due in part to DNSSEC and application specific application-specific key records.
      Although each namespace can be stretched (IP with v6, DNS with
      KEY records), neither can adequately provide for host
      authentication or act as a separation between internetworking
      and transport layers.</t>
        <t>The Host Identity (HI) namespace fills an important gap
      between the IP and DNS namespaces. An interesting thing about
      the HI is that it actually allows a host to give up all but the
      3rd network-layer invariant. That is to say, as long as the
      source and destination addresses in the network-layer protocol
      are reversible, HIP takes care of host identification, and
      reversibility allows a local host to receive a packet back from
      a remote host. The address changes occurring during NAT transit
      (non-mutable) or host movement (non-omniscient or non-mobile)
      can be managed by the HIP layer.</t>
        <t>With the exception of High-Performance Computing high-performance computing applications,
      the Sockets sockets API is the most common way to develop network
      applications.  Applications use the Sockets sockets API either directly
      or indirectly through some libraries or frameworks. However, the
      Sockets
      sockets API is based on the assumption of static IP addresses,
      and DNS with its lifetime values was invented at later stages
      during the evolution of the Internet. Hence, the Sockets sockets API
      does not deal with the lifetime of addresses <xref target="RFC6250" />. format="default"/>. As the majority of the end-user equipment is
      mobile today, their addresses are effectively ephemeral, but the
      Sockets
      sockets API still gives a fallacious illusion of persistent IP
      addresses to the unwary developer. HIP can be used to solidify
      this illusion because HIP provides persistent persistent, surrogate
      addresses to the application layer in the form of LSIs and
      HITs.</t>
        <t>The persistent identifiers as provided by HIP are useful in
      multiple scenarios (see, e.g., <xref target="ylitalo-diss" /> format="default"/> or
      <xref target="komu-diss" />, format="default"/> for a more elaborate
      discussion):</t>

      <t>
        <list style="symbols">

          <t>When
        <ul spacing="normal">
          <li>When a mobile host moves physically between two different
          WLAN networks and obtains a new address, an application using
          the identifiers remains isolated regardless of the topology changes
          while the underlying HIP layer re-establishes reestablishes connectivity
          (i.e.
          (i.e., a horizontal handoff).</t>

          <t>Similarly, handoff).</li>
          <li>Similarly, the application utilizing the identifiers
          remains again unaware of the topological changes when the
          underlying host equipped with WLAN and cellular network
          interfaces switches between the two different access
          technologies (i.e. (i.e., a vertical handoff).</t>

          <t>Even handoff).</li>
          <li>Even when hosts are located in private address realms,
          applications can uniquely distinguish different hosts from
          each other based on their identifiers. In other words, it can
          be stated that HIP improves Internet transparency
          for the application layer <xref target="komu-diss" />.</t>

          <t>Site format="default"/>.</li>
          <li>Site renumbering events for services can occur due to
          corporate mergers or acquisitions, or by changes in Internet
          Service Provider.
          service provider. They can involve changing the entire
          network prefix of an organization, which is problematic due
          to hard-coded addresses in service configuration files or
          cached IP addresses at the client side <xref target="RFC5887"
          />. format="default"/>. Considering such human errors, a site employing
          location-independent identifiers as promoted by HIP may
          experience fewer problems while renumbering their network.
          </t>

          <t>More
          </li>
          <li>More agile IPv6 interoperability can be achieved,
          as discussed in <xref target="lsi" />. format="default"/>. IPv6-based applications can
          communicate using HITs with IPv4-based applications that are
          using LSIs. Additionally, the underlying network type (IPv4 or IPv6)
          becomes independent of the addressing family of the
          application.</t>

          <t>HITs
          application.</li>
          <li>HITs (or LSIs) can be used in IP-based access control
          lists as a more secure replacement for IPv6
          addresses. Besides security, HIT based HIT-based access control has two
          other benefits. First, the use of HITs can potentially halve the size of access control lists
          because separate rules for IPv4 are not
          needed <xref target="komu-diss" />. format="default"/>. Second, HIT-based configuration
          rules in HIP-aware middleboxes remain static and independent
          of topology changes, thus simplifying administrative efforts
          particularly for mobile environments. For instance, the
          benefits of HIT-based access control have been harnessed in the
          case of HIP-aware firewalls, but can be utilized
          directly at the end-hosts as well <xref target="RFC6538" />.</t>

        </list>
      </t> format="default"/>.</li>
        </ul>
        <t>While some of these benefits could be and have been
      redundantly implemented by individual applications, providing
      such generic functionality at the lower layers is useful because
      it reduces software development effort and networking software
      bugs (as the layer is tested with multiple applications). It
      also allows the developer to focus on building the application
      itself rather than delving into the intricacies of mobile
      networking, thus facilitating separation of concerns.</t>
        <t>HIP could also be realized by combining a number of different
      protocols, but the complexity of the resulting software may
      become substantially larger, and the interaction between multiple multiple,
      possibly layered protocols may have adverse effects on latency
      and throughput. It is also worth noting that virtually nothing
      prevents realizing the HIP architecture, for instance, as an
      application-layer library, which has been actually implemented
      in the past <xref target="xin-hip-lib" />. format="default"/>. However, the tradeoff trade-off
      in moving the HIP layer to the application layer is that legacy
      applications may not be supported.</t>

<!--
      <t>Since all systems can have a Host Identity, every system can
      have an entry in the DNS.  The mobility features in HIP make it
      attractive to trusted 3rd parties to offer rendezvous
      servers.</t>
-->
    </section>
      <section title="Drawbacks numbered="true" toc="default">
        <name>Drawbacks of HIP"> HIP</name>
        <t>In computer science, many problems can be solved with an
      extra layer of indirection. However, the indirection always
      involves some costs as there is no such a thing as a "free lunch". In
      the case of HIP, the main costs could be stated as follows:</t>

      <t>
        <list style="symbols">

          <t>In
        <ul spacing="normal">
          <li>In general, an additional layer and a namespace always involve
          some initial effort in terms of implementation,
          deployment
          deployment, and maintenance. Some education of developers and administrators may
          also be needed. However, the HIP community at the IETF has
          spent years in experimenting, exploring, testing,
          documenting
          documenting, and implementing HIP to ease the adoption costs.
          </t>

	  <t>HIP
          </li>
          <li>HIP introduces a need to manage HIs and
	  requires a centralized approach to manage HIP-aware
	  endpoints at scale. What were formerly IP address-based ACLs
	  are now trusted HITs, and the HIT to IP HIT-to-IP address mappings as
	  well as access policies must be managed. HIP-aware endpoints
	  must also be able to operate autonomously to ensure mobility
	  and availability (an endpoint must be able to run without
	  having to have a persistent management connection).  The
	  users who want this better security and mobility of HIs
	  instead of IP address based address-based ACLs have to then manage this
	  additional 'identity layer' in a non-persistent nonpersistent fashion. As
	  exemplified in <xref target="tempered" />, format="default"/>, these challenges
	  have been already solved in an infrastructure setting to
	  distribute policy and manage the mappings and trust
	  relationships between HIP-aware endpoints.</t>

          <t>HIP endpoints.</li>
          <li>HIP decouples identifier and locator roles of IP
          addresses. Consequently, a mapping mechanism is needed to
          associate them together. A failure to map a HIT to its
          corresponding locator may result in failed connectivity
          because a HIT is "flat" by its nature and cannot be looked
          up from the hierarchically organized DNS. HITs are flat by
          design due to a security tradeoff. trade-off. The more bits that are
          allocated for the hash in the HIT, the less likely there
          will be (malicious) collisions.</t>

          <t>From collisions.</li>
          <li>From performance viewpoint, HIP control and data plane
          processing introduces some overhead in terms of throughput and
          latency as elaborated below.</t>

        </list>
      </t> below.</li>
        </ul>
        <t>Related to deployment drawbacks, firewalls are commonly used to control access
         to various services and devices in the current Internet. Since HIP introduces an additional namespace,
         it is expected that also the HIP namespace would be filtered for
         unwanted connectivity. connectivity also. While this can be achieved with existing tools
         directly in the end-hosts, filtering at the middleboxes requires
         modifications to existing firewall software or additional middleboxes <xref target="RFC6538" />. format="default"/>.
        </t>
        <t>The key exchange introduces some extra latency (two round
      trips) in the initial transport-layer connection establishment between two hosts.
      With TCP, additional delay occurs if the underlying network stack implementation drops
      the triggering SYN packet during the key exchange.
      The same cost may also occur during HIP handoff
      procedures. However, subsequent TCP sessions using the same HIP association will not bear this cost (within the key lifetime).
      Both the key exchange and handoff penalties can be minimized by caching TCP
      packets. The latter case can further be optimized with
      TCP user timeout extensions <xref target="RFC5482" /> format="default"/> as described in further
      detail by Schütz <contact fullname="Schütz"/> et al al. <xref target="schuetz-intermittent" />.</t> format="default"/>.</t>
        <t>The most CPU-intensive operations involve the use of the
      asymmetric keys and Diffie-Hellman key derivation at the control
      plane, but this occurs only during the key exchange, its
      maintenance (handoffs, (handoffs and refreshing of key material) material), and tear-down teardown
      procedures of HIP associations. The data plane is typically
      implemented with ESP because it has a smaller overhead due to symmetric key
      encryption. Naturally, even ESP involves some overhead in terms of
      latency (processing costs) and throughput (tunneling) (see,
      e.g., <xref target="ylitalo-diss" /> format="default"/> for a performance
      evaluation).</t>
      </section>
      <section title="Deployment numbered="true" toc="default">
        <name>Deployment and adoption considerations"> Adoption Considerations</name>
        <t>This section describes some deployment and adoption
      considerations related to HIP from a technical perspective.</t>
        <section title="Deployment analysis"> numbered="true" toc="default">
          <name>Deployment Analysis</name>
          <t>
       HIP has been adapted and deployed in an industrial control
       network in a production factory, in which HIP's strong network
       layer network-layer
       identity supports the secure coexistence of the control
       network with many untrusted network devices operated by
       third-party vendors <xref target="paine-hip" />. format="default"/>.  Similarly,
       HIP has also been included in a security product to support
       layer-two Virtual Private Networks
       Layer 2 VPNs <xref
       target="henderson-vpls" /> target="I-D.henderson-hip-vpls" format="default"/> to enable security zones in a
       supervisory control and data acquisition (SCADA)
       network. However, HIP has not been a "wild success" <xref target="RFC5218" /> format="default"/> in the Internet as argued by Levä <contact fullname="Levä"/> et al al.
       <xref target="leva-barriers" />. target="levae-barriers" format="default"/>. Here, we briefly highlight
       some of their findings based on interviews with 19 experts from
       the industry and academia.</t>
          <t>From a marketing perspective, the demand for HIP has been low
      and substitute technologies have been favored. Another
      identified reason has been that some technical misconceptions
      related to the early stages of HIP specifications still
      persist. Two identified misconceptions are that HIP does not
      support NAT traversal, traversal and that HIP must be implemented in the OS
      kernel. Both of these claims are untrue; HIP does have NAT
      traversal extensions <xref
      target="I-D.ietf-hip-native-nat-traversal" />, target="RFC9028" format="default"/>, and kernel
      modifications can be avoided with modern operating systems by
      diverting packets for userspace processing.
          </t>
          <t>The analysis by Levä <contact fullname="Levä"/> et al al. clarifies infrastructural requirements for
      HIP. In a minimal set up, setup, a client and server machine have to
      run HIP software. However, to avoid manual configurations,
      usually DNS records for HIP are set up. For instance, the
      popular DNS server software Bind9 does not require any changes
      to accommodate DNS records for HIP because they can be supported
      in binary format in its configuration files <xref target="RFC6538" />. format="default"/>. HIP
      rendezvous servers and firewalls are optional. No changes are
      required to network address points, NATs, edge routers routers, or core
      networks. HIP may require holes in legacy firewalls.
          </t>
          <t>The analysis also clarifies the requirements for the host
      components that consist of three parts. First, a HIP control
      plane component is required, typically implemented as a
      userspace daemon. Second, a data plane component is needed. Most
      HIP implementations utilize the so called BEET so-called Bound End-to-End Tunnel (BEET) mode of ESP that
      has been available since Linux kernel 2.6.27, but the BEET mode is also included
      as a userspace component in a few of the
      implementations. Third, HIP systems usually provide a DNS proxy
      for the local host that translates HIP DNS records to LSIs and
      HITs, and communicates the corresponding locators to the HIP
      userspace daemon. While the third component is not
      mandatory, it is very useful for avoiding manual
      configurations. The three components are further described in
      the <xref target="RFC6538">HIP target="RFC6538" format="default">HIP experiment report</xref>.</t>
          <t>Based on the interviews, Levä <contact fullname="Levä"/> et al al. suggest further
      directions to facilitate HIP deployment.
      Transitioning a number of HIP specifications to the standards track Standards Track in the
      IETF has already taken place, but the authors suggest other additional measures
      based on the interviews.
      As a more radical measure, the authors
      suggest to implement HIP as a purely application-layer library
      <xref target="xin-hip-lib" /> format="default"/> or other kind of middleware. On
      the other hand, more conservative measures include focusing on
      private deployments controlled by a single stakeholder. As a
      more concrete example of such a scenario, HIP could be used by a
      single service provider to facilitate secure connectivity between its
      servers <xref target="komu-cloud" />. format="default"/>.
          </t>
        </section>
        <section anchor="MACsec" title="HIP numbered="true" toc="default">
          <name>HIP in 802.15.4 networks"> Networks</name>
          <t>The IEEE 802 standards have been defining MAC layered MAC-layer security.  Many
      of these standards use EAP Extensible Authentication Protocol (EAP) <xref target="RFC3748"></xref> target="RFC3748" format="default"/>
      as a Key Management System (KMS) transport, but some like IEEE
      802.15.4 <xref target="IEEE.802-15-4.2011"></xref> target="IEEE.802.15.4" format="default"/> leave the
      KMS and its transport as "Out "out of Scope".</t> scope".</t>
          <t>HIP is well suited as a KMS in these environments:

        <list style="symbols">

	  <t>HIP

          </t>
          <ul spacing="normal">
            <li>HIP is independent of IP addressing and can be directly
	  transported over any network protocol.</t>

	  <t>Master Keys protocol.</li>
            <li>Master keys in 802 protocols are commonly pair-based with
	  group keys transported from the group controller using pair-wise
	  keys.</t>

	  <t>AdHoc pairwise
	  keys.</li>
            <li>Ad hoc 802 networks can be better served by a peer-to-peer
	  KMS than the EAP client/server model.</t>

	  <t>Some model.</li>
            <li>Some devices are very memory constrained constrained, and a common KMS
	  for both MAC and IP security represents a considerable code
	  savings.</t>

	</list>

      </t>
	  savings.</li>
          </ul>
        </section>
        <section title="HIP numbered="true" toc="default">
          <name>HIP and Internet of Things"> Things</name>
          <t>HIP requires certain amount computational resources from a
      device due to cryptographic processing. HIP scales down to
      phones and small system-on-chip devices (such as Raspberry Pis,
      Intel Edison), but small sensors operating with small batteries
      have remained problematic. Different extensions to the HIP have
      been developed to scale HIP down to smaller devices, typically
      with different security tradeoffs. trade-offs. For example, the
      non-cryptographic identifiers have been proposed in RFID
      scenarios. The slimfit Slimfit approach <xref target="hummen" /> format="default"/> proposes a
      compression layer for HIP to make it more suitable for
      constrained networks.  The approach is applied to a light-weight lightweight
      version of HIP (i.e. (i.e., "Diet HIP") in order to scale down to small
      sensors.</t>
          <t>The HIP Diet Exchange EXchange (DEX) <xref target="I-D.ietf-hip-dex" /> target="hip-dex" format="default"/> design aims at
      reducing to
      reduce the overhead of the employed cryptographic primitives
      by omitting public-key signatures and hash functions.  In doing
      so, the main goal is to still deliver similar security
      properties similar to the Base Exchange (BEX).</t>
          <t>DEX is primarily designed for computation computation- or memory-
      constrained memory-constrained
      sensor/actuator devices.  Like BEX, it is expected to
      be used together with a suitable security protocol such as the
      Encapsulated Security Payload (ESP)
      ESP for the protection of upper layer upper-layer
      protocol data.  In addition, DEX can also be used as a keying
      mechanism for security primitives at the MAC layer, e.g., for IEEE
      802.15.9 networks (<xref target="IEEE.802-15-9" />.</t> <xref target="IEEE.802.15.9" format="default"/>.</t>
          <t>The main differences between HIP BEX and DEX are:

      <list style="numbers">

          </t>
          <ol spacing="normal" type="1">
            <li>
              <t>Minimum collection of cryptographic primitives to reduce the
	protocol overhead.

	<list style="symbols">

	  <t>Static

              </t>
              <ul spacing="normal">
                <li>Static Elliptic Curve Diffie-Hellman (ECDH) key pairs for peer
          authentication and encryption of the session key.</t>

          <t>AES-CTR key.</li>
                <li>AES-CTR for symmetric encryption and AES-CMAC for MACing
          function.</t>

	  <t>A
          function.</li>
                <li>A simple fold function for HIT generation.</t>

	</list></t>

	<t>Forfeit of Perfect Forward Secrecy generation.</li>
              </ul>
            </li>
            <li>Forfeit of perfect forward secrecy with the dropping of an
	ephemeral Diffie-Hellman key agreement.</t>

	<t>Forfeit agreement.</li>
            <li>Forfeit of digital signatures with the removal of a hash
	function.  Reliance on ECDH derived the ECDH-derived key used in HIP_MAC to prove
	ownership of the private key.</t>

	<t>Diffie-Hellman key.</li>
            <li>Diffie-Hellman derived key ONLY used to protect the HIP packets.
	A separate secret exchange within the HIP packets creates the
	session key(s).</t>

	<t>Optional key(s).</li>
            <li>Optional retransmission strategy tailored to handle the
	potentially extensive processing time of the employed
	cryptographic operations on computationally constrained devices.</t>

      </list>

      </t> devices.</li>
          </ol>
        </section>
        <section title="Infrastructure Applications">

      <!--
	  * proxies / gateways
            X Using HIP with Forward Web Proxy
            X Using HIP with Reverse HIP Proxy
            X P2P-SIP uses overlay as "rendezvous"
              X avoids redundant tunneling
            X Sendmail and SpamAssassin
	    * VPN
              * HIP and OpenVPN
	      * HIP proxies
	      * Boeing experiments?
	      X Tempered networks product
                * hi3 (NO?)
	      X hip p2p sip
            * misc
	      X hip cloud paper(s) (container/vm migration, microservices/hybrid cloud security, portable security/mergers, heer:auth, nat traversal)
 	        X Switches - Vanilla telnet
                * Nagios Infrastructure monitoring tool (NO)
  	      X hip cellular
          * directories NO
	    * dns (opportunistic)
  	    * OpenLDAP
      --> numbered="true" toc="default">
          <name>Infrastructure Applications</name>
      <t>
	The <xref target="RFC6538">HIP target="RFC6538" format="default">HIP experimentation report</xref>
	enumerates a number of client and server applications that
	have been trialed with HIP. <!-- The report also describes the
	HIP infrastructure requirements (rendezvous servers, DNS records). -->  Based on
	the report, this section highlights and complements some
	potential ways how HIP could be exploited in existing
	infrastructure such as routers, gateways gateways, and proxies.
          </t>
          <t>HIP has been successfully used with forward web proxies (i.e., client-side proxies). HIP was used between a client
      host (web browser) and a forward proxy (Apache server) that terminated the HIP/ESP-tunnel. HIP/ESP tunnel. The
      forward web proxy translated HIP-based traffic originating from the
      client into non-HIP traffic towards any web server in the Internet. Consequently, the HIP-capable
      client could communicate with HIP-incapable web servers. This
      way, the client could utilize mobility support as provided by HIP
      while using the fixed IP address of the web proxy, for instance, to access services
      that were allowed only from the IP address range of the proxy.</t>
          <t>HIP has also been experimented with reverse web proxies (i.e. (i.e., server-side proxies) has also been investigated,
      as described in more detail in <xref target="komu-cloud"/>. target="komu-cloud" format="default"/>. In
      this scenario, a HIP-incapable client accessed a HIP-capable web service
      via an intermediary load balancer (that was a web based (a web-based load
      balancer implementation called HAProxy). The load
      balancer translated non-HIP traffic originating from the
      client into HIP-based traffic for the web service (consisting
      of front-end and back-end servers). Both the load balancer and
      the web service were located in a datacenter. data center. One of the
      key benefits for encrypting the web traffic with HIP in this
      scenario was to support supporting a private-public cloud scenario
      (i.e.
      (i.e., hybrid cloud) where the load balancer, front-end servers servers,
      and back-end servers can be were located in different datacenters
      and, thus, data centers,
      and thus the traffic needs needed to be protected when it passes passed through
      potentially insecure networks between the borders of the private and public clouds.
          </t>
          <t>While HIP could be used to secure access to intermediary
      devices (e.g., access to switches with legacy telnet), it has
      also been used to secure intermittent connectivity between
      middlebox infrastructure. For instance, earlier research <xref target="komu-mitigation" /> format="default"/> utilized HIP between Secure Simple Mail
      Transport Protocol (SMTP) servers in order to exploit the
      computational puzzles of HIP as a spam mitigation mechanism. A
      rather obvious practical challenge in this approach was the lack
      of HIP adoption on existing SMTP servers.</t>
          <t>To avoid deployment hurdles with existing infrastructure, HIP
      could be applied in the context of new protocols with little
      deployment.  Namely, HIP has been experimented studied in the context of
      a new protocol, peer-to-peer SIP <xref target="camarillo-p2psip" />. format="default"/>. The work has resulted in a
      number of related RFCs <xref target="RFC6078" />, format="default"/>, <xref target="RFC6079" />, format="default"/>, and <xref target="RFC7086" />. format="default"/>.  The key idea in the research work was to
      avoid redundant, time consuming time-consuming ICE procedures by grouping
      different connections (i.e. (i.e., SIP and media streams) together
      using the low-layer HIP HIP, which executes NAT traversal procedures
      only once per host. An interesting aspect in the approach was
      the use of P2P-SIP infrastructure as rendezvous servers for the HIP
      control plane instead of utilizing the traditional HIP rendezvous
      services <xref target="RFC8004" />.</t> format="default"/>.</t>
          <t>Researchers have proposed to use using HIP in cellular
      networks as a mobility, multihoming multihoming, and security solution. <xref target="hip-lte" /> format="default"/> provides a security analysis and simulation
      measurements of using HIP in Long Term Evolution (LTE) backhaul networks.</t>
          <t>HIP has been experimented with studied for securing cloud internal
      connectivity. First with virtual machines <xref target="komu-cloud" /> format="default"/> and then later also between Linux
      containers <xref target="ranjbar-synaptic" />. format="default"/>.  In both cases,
      HIP was suggested as a solution to NAT traversal that could be
      utilized both internally by a cloud network and between
      multi-cloud deployments. Specifically in the former case, HIP
      was beneficial sustaining connectivity with a virtual machine
      while it migrates migrated to a new location. In the latter case, a
      Software-Defined Networking (SDN) controller acted as a rendezvous
      server for HIP-capable containers. The controller enforced
      strong replay protection by adding middlebox nonces <xref target="heer-end-host" /> format="default"/> to the passing HIP base exchange
      and UPDATE messages.
          </t>
        </section>
        <section title="Management anchor="tempered" numbered="true" toc="default">
          <name>Management of Identities in a Commercial Product" anchor="tempered"> Product</name>
          <t>Tempered Networks provides HIP-based products.
      They refer to their platform as <xref
      target="tempered-networks">Identity-Defined target="tempered-networks" format="default">Identity-Defined Networking
      (IDN)</xref> because of HIP's identity-first networking
      architecture. Their objective has been to make it simple and
      non-disruptive
      nondisruptive to deploy HIP enabled HIP-enabled services widely in
      production environments with the purpose of enabling transparent
      device authentication and authorization, cloaking, segmentation,
      and end-to-end networking. The goal is to eliminate much of the
      circular dependencies, exploits, and layered complexity of
      traditional "address-defined networking" that prevents mobility
      and verifiable device access control. The products in the
      portfolio of Tempered Networks utilize HIP are as follows:

      <list style="symbols">

       <t>HIP

          </t>

          <dl newline="true">
            <dt>HIP Switches / Gateways - these Gateways</dt><dd>These are physical or virtual
       appliances that serve as the HIP gateway and policy enforcement
       point for non HIP-aware non-HIP-aware applications and devices located behind
       it. No IP or infrastructure changes are required in order to
       connect, cloak, and protect the non-HIP aware non-HIP-aware
       devices. Currently known supported platforms for HIP gateways
       are:
       are x86 and ARM chipsets, ESXi, Hyper-V, KVM, AWS, Azure, and
       Google clouds.</t>

       <t>HIP clouds.</dd>
            <dt>HIP Relays / Rendezvous - Rendezvous</dt><dd>These are physical or virtual appliances
       that serve as identity based identity-based routers authorizing and bridging
       HIP endpoints without decrypting the HIP session. A HIP Relay relay
       can be deployed as a standalone appliance or in a cluster for
       horizontal scaling. All HIP aware HIP-aware endpoints and the devices
       they're connecting and protecting can remain privately
       addressed,
       addressed. The appliances eliminate IP conflicts, tunnel through NAT and
       CGNAT,
       carrier-grade NAT, and require no changes to the underlay underlying
       infrastructure. The only requirement is that a HIP endpoint
       should have outbound access to the Internet and that a HIP Relay should have
       a public address.</t>

       <t>HIP-Aware address.</dd>
            <dt>HIP-Aware Clients and Servers - Servers</dt><dd>This is software that installs is installed in
       the host's network stack and enforces policy for that host. HIP
       clients support split tunneling. Both the HIP client and HIP server
       can interface with the local host firewall firewall, and the HIP Server server can
       be locked down to listen only on the port used for HIP, making
       the server invisible from unauthorized devices. Currently known
       supported platforms are Windows, OSX, OS X, iOS, Android, Ubuntu,
       CentOS
       CentOS, and other Linux derivatives.</t>

       <t>Policy derivatives.</dd>
            <dt>Policy Orchestration Managers - a Managers</dt><dd>These physical or virtual
       appliance that serves
       appliances serve as the engine to define and distribute
       network and security policy (HI and IP mappings, overlay networks and whitelist policies etc.) to HIP-aware endpoints. Orchestration does not need to
       persist to the HIP endpoints and vice versa allowing for
       autonomous host networking and security.</t>
      </list>

      </t>

      <!--
      <t>Their HIP enabled products include the following:

      <list style="symbols">

	<t>The Conductor: the policy orchestration engine that
	defines and distributes network and security policy to HIP
	endpoints. The Conductor does not need to persist to the HIP
	endpoints and vice versa allowing for autonomous hosts.</t>

	<t>HIPswitch: a physical or virtual appliance that serves as
	a HIP gateway and policy enforcement point for non HIP-aware
	applications and devices located behind it. Supported
	platforms are: x86 and ARM chipsets, ESXi, Hyper-V, KVM, AWS,
	Azure, and Google clouds.</t>

	<t>HIPrelay: a physical, virtual, or cloud appliance (same
	supported platforms as the HIPswitch) that serves as an
	identity-based router authorizing and bridging HIP endpoints
	without decrypting the HIP session. The HIPrelay can be
	deployed as a standalone or in a cluster for horizontal
	scaling. All HIP endpoints and the devices they're connecting
	and protecting can remain privately addressed with no IP
	conflicts, tunnels through NAT and CGNAT, and requires no
	changes to the underlay infrastructure. The only requirement
	is that a HIP endpoint have outbound access to the Internet
	and that the HIPrelay have a public address.</t>

	<t>HIPclient and HIPserver: software that installs in the
	host's network stack and enforces security policy (HI and IP mappings, overlay networks, and whitelist policies, etc.) to HIP-aware endpoints. Orchestration does not need to
       persist to the HIP endpoints and vice versa, allowing for that
	host. Supported platforms are Windows, OSX, iOS, Android,
	Ubuntu, CentOS
       autonomous host networking and other Linux derivatives.</t>

      </t>
      --> security.</dd>
          </dl>

    </section>
      </section>
      <section title="Answers numbered="true" toc="default">
        <name>Answers to NSRG questions"> Questions</name>
        <t>The IRTF Name Space Research Group has posed a number of
      evaluating questions in <xref
      target="nsrg-report">their target="I-D.irtf-nsrg-report" format="default">their report</xref>.  In this
      section, we provide answers to these questions.

          <list style="numbers">

        </t>
        <ol spacing="normal" type="1">
          <li>
            <t>How would a stack name improve the overall
            functionality of the Internet?

              <list style="empty">

            </t>
              <t>HIP decouples the internetworking layer from the
		transport layer, allowing each to evolve separately.
		The decoupling makes end-host mobility and
		multi-homing
		multihoming easier, also across IPv4 and IPv6
		networks.  HIs make network renumbering easier, and
		they also make process migration and clustered servers
		easier to implement.  Furthermore, being cryptographic
		in nature, they provide the basis for solving the
		security problems related to end-host mobility and
		multi-homing.</t>

	      </list>
            </t>
		multihoming.</t>
          </li>
          <li>
            <t>What does a stack name look like?

              <list style="empty">

            </t>
              <t>A HI is a cryptographic public key.  However,
                instead of using the keys directly, most protocols use
                a fixed-size hash of the public key.</t>

	      </list>
            </t>
          </li>
          <li>
            <t>What is its lifetime?

              <list style="empty">

            </t>
              <t>HIP provides both stable and temporary Host
		Identifiers.  Stable HIs are typically long-lived,
		with a lifetime of years or more.  The lifetime of
		temporary HIs depends on how long the upper-layer
		connections and applications need them, and can range
		from a few seconds to years.</t>

	      </list>
            </t>
          </li>
          <li>
            <t>Where does it live in the stack?

              <list style="empty">

            </t>
              <t>The HIs live between the transport and
		internetworking layers.</t>

	      </list>
            </t>
          </li>
          <li>
            <t>How is it used on the end points?

              <list style="empty"> endpoints?

            </t>
              <t>The Host Identifiers may be used directly or
		indirectly (in the form of HITs or LSIs) by
		applications when they access network services.
		Additionally, the Host Identifiers, as public keys,
		are used in the built-in key agreement protocol,
		called the HIP base exchange, to authenticate the
		hosts to each other.</t>

	      </list>
            </t>
          </li>
          <li>
            <t>What administrative infrastructure is needed to support
	    it?

              <list style="empty">

            </t>
              <t>In some environments, it is possible to use HIP
		opportunistically, without any infrastructure.
		However, to gain full benefit from HIP, the HIs must
		be stored in the DNS or a PKI, and the rendezvous
		mechanism is needed <xref target="RFC8005" />.</t>

	      </list>
            </t> format="default"/>.</t>
          </li>
          <li>
            <t>If we add an additional layer layer, would it make the address
            list in SCTP unnecessary?

              <list style="empty">
		<t>Yes</t>
	      </list>

            </t>
              <t>Yes</t>
          </li>
          <li>
            <t>What additional security benefits would a new naming
	    scheme offer?

              <list style="empty">

            </t>
              <t>HIP reduces dependency on IP addresses, making the
		so-called address ownership <xref target="Nik2001" /> format="default"/>
		problems easier to solve.  In practice, HIP provides
		security for end-host mobility and multi-homing. multihoming.
		Furthermore, since HIP Host Identifiers are public
		keys, standard public key certificate infrastructures
		can be applied on the top of HIP.</t>
	      </list>
            </t>
          </li>
          <li>
            <t>What would the resolution mechanisms be, or what
            characteristics of a resolution mechanisms would be
            required?

              <list style="empty">

            </t>
              <t>For most purposes, an approach where DNS names are
		resolved simultaneously to HIs and IP addresses is
		sufficient.  However, if it becomes necessary to
		resolve HIs into IP addresses or back to DNS names, a
		flat resolution infrastructure is needed.  Such an
		infrastructure could be based on the ideas of
		Distributed Hash Tables, but would require significant
		new development and deployment.</t>

	      </list>
            </t>
	  </list>
        </t>
          </li>
        </ol>
      </section>
    </section> <!-- design considerations -->

  <!-- appendix -->
    <section numbered="false" toc="default">
      <name>Acknowledgments</name>
      <t>For the people historically involved in the early stages of
      HIP, see the Acknowledgments section in the
      Host Identity Protocol specification.</t>
      <t>During the later stages of this document, when the editing
      baton was transferred to <contact fullname="Pekka Nikander"/>, the comments from the
      early implementers and others, including <contact fullname="Jari Arkko"/>,  <contact fullname="Jeff Ahrenholz"/>,  <contact fullname="Tom
      Henderson"/>,  <contact fullname="Petri Jokela"/>, <contact fullname="Miika Komu"/>,  <contact fullname="Mika Kousa"/>,  <contact fullname="Andrew
      McGregor"/>,  <contact fullname="Jan Melen"/>,  <contact fullname="Tim Shepard"/>,  <contact fullname="Jukka Ylitalo"/>,  <contact fullname="Sasu Tarkoma"/>,
      and  <contact fullname="Jorma Wall"/>, were invaluable. Also, the comments from  <contact fullname="Lars Eggert"/>,
       <contact fullname="Spencer Dawkins"/>,  <contact fullname="Dave Crocker"/>, and  <contact fullname="Erik Giesa"/> were also useful.</t>

      <t>The authors want to express their special thanks to
       <contact fullname="Tom Henderson"/>, who took the burden of editing the document
      in response to IESG comments at the time when both of the
      authors were busy doing other things.  Without his perseverance,
      the original document might have never made it as RFC 4423.</t>
      <t>This main effort to update and move HIP forward within the
      IETF process owes its impetus to a number of HIP development
      teams. The authors are grateful for Boeing, Helsinki Institute
      for Information Technology (HIIT), NomadicLab of Ericsson, and
      the three universities: RWTH Aachen, Aalto, and University of
      Helsinki for their efforts.  Without their collective efforts,
      HIP would have withered as on the IETF vine as a nice
      concept.</t>
      <t>Thanks also to <contact fullname="Suvi Koskinen"/> for her help with proofreading
      and with the reference jungle.</t>
    </section>
  </back>
</rfc>