doc: Add RFC documents

1 files changed, 1347 insertions, 0 deletions

diff --git a/doc/rfc/rfc4423.txt b/doc/rfc/rfc4423.txt
new file mode 100644
index 0000000..b35aeb8
--- /dev/null
+++ b/doc/rfc/rfc4423.txt
@@ -0,0 +1,1347 @@
+
+
+
+
+
+
+Network Working Group                                       R. Moskowitz
+Request for Comments: 4423     ICSA Labs, a division of Cybertrust, Inc.
+Category: Informational                                      P. Nikander
+                                           Ericsson Research Nomadic Lab
+                                                                May 2006
+
+
+               Host Identity Protocol (HIP) Architecture
+
+
+Status of This Memo
+
+   This memo provides information for the Internet community.  It does
+   not specify an Internet standard of any kind.  Distribution of this
+   memo is unlimited.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2006).
+
+Abstract
+
+   This memo describes a snapshot of the reasoning behind a proposed new
+   namespace, the Host Identity namespace, and a new protocol layer, the
+   Host Identity Protocol (HIP), between the internetworking and
+   transport layers.  Herein are presented the basics of the current
+   namespaces, their strengths and weaknesses, and how a new namespace
+   will add completeness to them.  The roles of this new namespace in
+   the protocols are defined.  The memo describes the thinking of the
+   authors as of Fall 2003.  The architecture may have evolved since.
+   This document represents one stable point in that evolution of
+   understanding.
+
+Table of Contents
+
+   1. Disclaimer ......................................................2
+   2. Introduction ....................................................2
+   3. Terminology .....................................................4
+      3.1. Terms Common to Other Documents ............................4
+      3.2. Terms Specific to This and Other HIP Documents .............4
+   4. Background ......................................................6
+      4.1. A Desire for a Namespace for Computing Platforms ...........6
+   5. Host Identity Namespace .........................................8
+      5.1. Host Identifiers ...........................................9
+      5.2. Storing Host Identifiers in DNS ............................9
+      5.3. Host Identity Tag (HIT) ...................................10
+      5.4. Local Scope Identifier (LSI) ..............................10
+   6. New Stack Architecture .........................................11
+
+
+
+Moskowitz & Nikander         Informational                      [Page 1]
+
+RFC 4423       Host Identity Protocol (HIP) Architecture        May 2006
+
+
+      6.1. Transport Associations and End-points .....................11
+   7. End-host Mobility and Multi-homing .............................12
+      7.1. Rendezvous Mechanism ......................................13
+      7.2. Protection against Flooding Attacks .......................13
+   8. HIP and IPsec ..................................................14
+   9. HIP and NATs ...................................................15
+      9.1. HIP and TCP Checksums .....................................15
+   10. Multicast .....................................................16
+   11. HIP Policies ..................................................16
+   12. Benefits of HIP ...............................................16
+      12.1. HIP's Answers to NSRG Questions ..........................17
+   13. Security Considerations .......................................19
+      13.1. HITs Used in ACLs ........................................21
+      13.2. Non-security considerations ..............................21
+   14. Acknowledgements ..............................................22
+   15. Informative References ........................................22
+
+1.  Disclaimer
+
+   The purpose of this memo is to provide a stable reference point in
+   the development of the Host Identity Protocol architecture.  This
+   memo describes the thinking of the authors as of Fall 2003; their
+   thinking may have evolved since then.  Occasionally, this memo may be
+   confusing or self-contradicting.  That is (partially) intentional,
+   and it reflects the snapshot nature of this memo.
+
+   This RFC is not a candidate for any level of Internet Standard.  The
+   IETF disclaims any knowledge of the fitness of this RFC for any
+   purpose and notes that the decision to publish is not based on IETF
+   review.  However, the ideas put forth in this RFC have generated
+   significant interest, including the formation of the IETF HIP Working
+   Group and the IRTF HIP Research Group.  These groups are expected to
+   generate further documents, sharing their findings with the whole
+   Internet community.
+
+2.  Introduction
+
+   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.
+
+   The proposed Host Identity namespace fills an important gap between
+   the IP and DNS namespaces.  The Host Identity namespace consists of
+   Host Identifiers (HIs).  A Host Identifier is cryptographic in its
+
+
+
+Moskowitz & Nikander         Informational                      [Page 2]
+
+RFC 4423       Host Identity Protocol (HIP) Architecture        May 2006
+
+
+   nature; it is the public key of an asymmetric key-pair.  Each host
+   will have at least one Host Identity, but it will typically have more
+   than one.  Each Host Identity uniquely identifies a single host;
+   i.e., no two hosts have the same Host Identity.  The Host Identity,
+   and the corresponding Host Identifier, can be either public (e.g.,
+   published in the DNS) or unpublished.  Client systems will tend to
+   have both public and unpublished Identities.
+
+   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.
+
+   Although the Host Identifiers could be used in many authentication
+   systems, such as the Internet Key Exchange (IKEv2) Protocol [9], the
+   presented architecture introduces a new protocol, called the Host
+   Identity Protocol (HIP), and a cryptographic exchange, called the HIP
+   base exchange; see also Section 8.  The HIP protocols provide for
+   limited forms of trust between systems, enhance mobility, multi-
+   homing, and dynamic IP renumbering; aid in protocol
+   translation/transition; and reduce certain types of denial-of-service
+   (DoS) attacks.
+
+   When HIP is used, the actual payload traffic between two HIP hosts is
+   typically, but not necessarily, protected with IPsec.  The Host
+   Identities are used to create the needed IPsec Security Associations
+   (SAs) and to authenticate the hosts.  When IPsec is used, the actual
+   payload IP packets do not differ in any way from standard IPsec-
+   protected IP packets.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Moskowitz & Nikander         Informational                      [Page 3]
+
+RFC 4423       Host Identity Protocol (HIP) Architecture        May 2006
+
+
+3.  Terminology
+
+3.1.  Terms Common to Other Documents
+
+   +--------------+----------------------------------------------------+
+   | Term         | Explanation                                        |
+   +--------------+----------------------------------------------------+
+   | public key   | The public key of an asymmetric cryptographic key  |
+   |              | pair.  Used as a publicly known identifier for     |
+   |              | cryptographic identity authentication.             |
+   |              |                                                    |
+   | Private key  | 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.        |
+   |              |                                                    |
+   | public key   | An asymmetric cryptographic key pair consisting of |
+   | pair         | public and private keys.  For example,             |
+   |              | Rivest-Shamir-Adelman (RSA) and Digital Signature  |
+   |              | Algorithm (DSA) key pairs are such key pairs.      |
+   |              |                                                    |
+   | end-point    | A communicating entity.  For historical reasons,   |
+   |              | the term 'computing platform' is used in this      |
+   |              | document as a (rough) synonym for end-point.       |
+   +--------------+----------------------------------------------------+
+
+3.2.  Terms Specific to This and Other HIP Documents
+
+   It should be noted that many of the terms defined herein are
+   tautologous, 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 for more
+   elaborate explanations.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Moskowitz & Nikander         Informational                      [Page 4]
+
+RFC 4423       Host Identity Protocol (HIP) Architecture        May 2006
+
+
+   +--------------+----------------------------------------------------+
+   | Term         | Explanation                                        |
+   +--------------+----------------------------------------------------+
+   | computing    | An entity capable of communicating and computing,  |
+   | platform     | for example, a computer.  See the definition of    |
+   |              | 'end-point', above.                                |
+   |              |                                                    |
+   | HIP base     | A cryptographic protocol; see also Section 8.      |
+   | exchange     |                                                    |
+   |              |                                                    |
+   | HIP packet   | An IP packet that carries a 'Host Identity         |
+   |              | Protocol' message.                                 |
+   |              |                                                    |
+   | Host         | An abstract concept assigned to a 'computing       |
+   | Identity     | platform'.  See 'Host Identifier', below.          |
+   |              |                                                    |
+   | Host         | A namespace formed by all possible Host            |
+   | Identity     | Identifiers.                                       |
+   | namespace    |                                                    |
+   |              |                                                    |
+   | Host         | A protocol used to carry and authenticate Host     |
+   | Identity     | Identifiers and other information.                 |
+   | Protocol     |                                                    |
+   |              |                                                    |
+   | Host         | A 128-bit datum created by taking a cryptographic  |
+   | Identity Tag | hash over a Host Identifier.                       |
+   |              |                                                    |
+   | Host         | A public key used as a name for a Host Identity.   |
+   | Identifier   |                                                    |
+   |              |                                                    |
+   | Local Scope  | A 32-bit datum denoting a Host Identity.           |
+   | Identifier   |                                                    |
+   |              |                                                    |
+   | Public Host  | A published or publicly known Host Identifier used |
+   | Identifier   | as a public name for a Host Identity, and the      |
+   | and Identity | corresponding Identity.                            |
+   |              |                                                    |
+   | Unpublished  | A Host Identifier that is not placed in any public |
+   | Host         | directory, and the corresponding Host Identity.    |
+   | Identifier   | Unpublished Host Identities are typically          |
+   | and Identity | shortlived in nature, being often replaced and     |
+   |              | possibly used just once.                           |
+   |              |                                                    |
+   | Rendezvous   | A mechanism used to locate mobile hosts based on   |
+   | Mechanism    | their Host Identity Tag (HIT).                    |
+   +--------------+----------------------------------------------------+
+
+
+
+
+
+Moskowitz & Nikander         Informational                      [Page 5]
+
+RFC 4423       Host Identity Protocol (HIP) Architecture        May 2006
+
+
+4.  Background
+
+   The Internet is built from three principal components: computing
+   platforms (end-points), 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.
+
+   There are two principal namespaces in use in the Internet for these
+   components: IP numbers 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.
+
+   IP numbers are a confounding of two namespaces, the names of a host's
+   networking interfaces and the names of the locations ('confounding'
+   is a term used in statistics to discuss metrics that are merged into
+   one with a gain in indexing, but a loss in informational value).  The
+   names of locations should be understood as denoting routing direction
+   vectors, i.e., information that is used to deliver packets to their
+   destinations.
+
+   IP numbers name networking interfaces, and typically only when the
+   interface is connected to the network.  Originally, IP numbers had
+   long-term significance.  Today, the vast number of interfaces use
+   ephemeral and/or non-unique IP numbers.  That is, every time an
+   interface is connected to the network, it is assigned an IP number.
+
+   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.
+
+   There are three critical deficiencies with the current namespaces.
+   First, dynamic readdressing cannot be directly managed.  Second,
+   anonymity 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.
+
+4.1.  A Desire for a Namespace for Computing Platforms
+
+   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.
+
+
+
+Moskowitz & Nikander         Informational                      [Page 6]
+
+RFC 4423       Host Identity Protocol (HIP) Architecture        May 2006
+
+
+   This could support rapid readdressing of the internetworking layer
+   because of mobility, rehoming, or renumbering.
+
+   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.
+
+   Such a namespace (for computing platforms) and the names in it should
+   have the following characteristics:
+
+   o  The namespace should be applied to the IP 'kernel'.  The IP kernel
+      is the 'component' between applications and the packet transport
+      infrastructure.
+
+   o  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 may require changes to the current APIs.  In
+      the long run, it is probable that some new APIs are needed.
+
+   o  The introduction of the namespace should not mandate any
+      administrative infrastructure.  Deployment must come from the
+      bottom up, in a pairwise deployment.
+
+   o  The names should have a fixed-length representation, for easy
+      inclusion in datagram headers and existing programming interfaces
+      (e.g., the TCB).
+
+   o  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.
+
+   o  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) 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 (1 quadrillion)
+      hashes were generated.
+
+   o  The names should have a localized abstraction that can be used in
+      existing protocols and APIs.
+
+
+
+
+Moskowitz & Nikander         Informational                      [Page 7]
+
+RFC 4423       Host Identity Protocol (HIP) Architecture        May 2006
+
+
+   o  It must be possible to create names locally.  This can provide
+      anonymity at the cost of making resolvability very difficult.
+
+      *  Sometimes the names may contain a delegation component.  This
+         is the cost of resolvability.
+
+   o  The namespace should provide authentication services.
+
+   o  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.
+
+   In this document, a new 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.
+
+5.  Host Identity Namespace
+
+   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
+   DNS Security (DNSSEC) [2], Pretty Good Privacy (PGP), or X.509 to
+   'notarize' the identity assertion.  It is expected that the Host
+   Identifiers will initially be authenticated with DNSSEC and that all
+   implementations will support DNSSEC as a minimal baseline.
+
+   In theory, any name that can claim to be 'statistically globally
+   unique' may serve as a Host Identifier.  However, in the authors'
+   opinion, a public key of a 'public key pair' makes the best Host
+   Identifier.  As will be specified in the Host Identity Protocol
+   specification, a public-key-based HI can authenticate the HIP packets
+   and protect them from man-in-the-middle attacks.  Since authenticated
+   datagrams are mandatory to provide much of HIP's DoS protection, the
+   Diffie-Hellman exchange in HIP has to be authenticated.  Thus, only
+   public key HI and authenticated HIP messages are supported in
+   practice.  In this document, the non-cryptographic forms of HI and
+   HIP are presented to complete the theory of HI, but they should not
+   be implemented as they could produce worse DoS attacks than the
+   Internet has without Host Identity.
+
+
+
+
+
+Moskowitz & Nikander         Informational                      [Page 8]
+
+RFC 4423       Host Identity Protocol (HIP) Architecture        May 2006
+
+
+5.1.  Host Identifiers
+
+   Host Identity adds two main features to Internet protocols.  The
+   first is a decoupling of the internetworking and transport layers;
+   see Section 6.  This decoupling will allow for independent evolution
+   of the two layers.  In addition, 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 IPsec.
+
+   The only completely defined structure of the Host Identity is that of
+   a public/private key pair.  In this case, 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.
+
+   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 / low risk, that is,
+   any place where host authentication is not needed (no risk of host
+   spoofing and no use of IPsec).  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.
+
+   The actual Host Identities are never directly used in any Internet
+   protocols.  The corresponding Host Identifiers (public keys) may be
+   stored in various DNS or Lightweight Directory Access Protocol (LDAP)
+   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.
+
+5.2.  Storing Host Identifiers in DNS
+
+   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 is stored in a new
+   Resource Record (RR) type, to be defined.  This RR type is likely to
+   be quite similar to the IPSECKEY RR [6].
+
+
+
+
+
+Moskowitz & Nikander         Informational                      [Page 9]
+
+RFC 4423       Host Identity Protocol (HIP) Architecture        May 2006
+
+
+   Alternatively, or in addition to storing Host Identifiers in the DNS,
+   they may be stored in various kinds of Public Key Infrastructure
+   (PKI).  Such a practice may allow them to be used for purposes other
+   than pure host identification.
+
+5.3.  Host Identity Tag (HIT)
+
+   A Host Identity Tag is a 128-bit representation for a Host Identity.
+   It is created by taking a cryptographic hash over the corresponding
+   Host Identifier.  There are two advantages of using a hash over using
+   the Host Identifier in protocols.  First, its fixed length makes for
+   easier protocol coding and also better manages the packet size cost
+   of this technology.  Second, it presents the identity in a consistent
+   format to the protocol independent of the cryptographic algorithms
+   used.
+
+   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.
+
+5.4.  Local Scope Identifier (LSI)
+
+   A Local Scope Identifier (LSI) is a 32-bit localized representation
+   for a Host Identity.  The purpose of an LSI is to facilitate using
+   Host Identities in existing protocols and APIs.  LSI's advantage over
+   HIT is its size; its disadvantage is its local scope.
+
+   Examples of how LSIs can be used include: as the address in an FTP
+   command and as the address in a socket call.  Thus, LSIs act as a
+   bridge for Host Identities into IPv4-based protocols and APIs.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Moskowitz & Nikander         Informational                     [Page 10]
+
+RFC 4423       Host Identity Protocol (HIP) Architecture        May 2006
+
+
+6.  New Stack Architecture
+
+   One way to characterize Host Identity is to compare the proposed new
+   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 IRTF
+   Name Space Research Group Report [7] and, e.g., the unpublished
+   Internet Draft "Endpoints and Endpoint Names" [10] by Noel Chiappa,
+   the IP addresses currently embody the dual role of locators and end-
+   point 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 an end-point name.
+
+   In the HIP architecture, the end-point names and locators are
+   separated from each other.  IP addresses continue to act as locators.
+   The Host Identifiers take the role of end-point identifiers.  It is
+   important to understand that the end-point names based on Host
+   Identities are slightly different from interface names; a Host
+   Identity can be simultaneously reachable through several interfaces.
+
+   The difference between the bindings of the logical entities is
+   illustrated in Figure 1.
+
+
+   Service ------ Socket                  Service ------ Socket
+                    |                                      |
+                    |                                      |
+                    |                                      |
+                    |                                      |
+   End-point        |                    End-point --- Host Identity
+            \       |                                      |
+              \     |                                      |
+                \   |                                      |
+                  \ |                                      |
+   Location --- IP address                Location --- IP address
+
+
+                                 Figure 1
+
+
+6.1.  Transport Associations and End-points
+
+   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 to Host Identities.
+
+
+
+Moskowitz & Nikander         Informational                     [Page 11]
+
+RFC 4423       Host Identity Protocol (HIP) Architecture        May 2006
+
+
+   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.
+
+7.  End-host Mobility and Multi-homing
+
+   HIP decouples the transport from the internetworking layer, and binds
+   the transport associations to the Host Identities (through actually
+   either the HIT or LSI).  Consequently, HIP can provide for a degree
+   of internetworking mobility and multi-homing 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, Dynamic Host
+   Configuration Protocol (DHCP), IPv6 prefix reassignments, or a
+   Network Address Translation (NAT) device remapping its translation.
+   Likewise, a system is considered multi-homed if it has more than one
+   globally routable IP address at the same time.  HIP links IP
+   addresses together, when multiple IP addresses correspond to the same
+   Host Identity, and if one address becomes unusable, or a more
+   preferred address becomes available, existing transport associations
+   can easily be moved to another address.
+
+   When a node moves while communication is already ongoing, address
+   changes are rather straightforward.  The peer of the mobile node can
+   just accept a HIP or an integrity protected IPsec packet from any
+   address and ignore the source address.  However, as discussed in
+   Section 7.2 below, a mobile node must send a HIP readdress packet to
+   inform the peer of the new address(es), and the peer must verify that
+   the mobile node is reachable through these addresses.  This is
+   especially helpful for those situations where the peer node is
+   sending data periodically to the mobile node (that is restarting a
+   connection after the initial connection).
+
+
+
+
+
+
+
+
+
+
+
+
+Moskowitz & Nikander         Informational                     [Page 12]
+
+RFC 4423       Host Identity Protocol (HIP) Architecture        May 2006
+
+
+7.1.  Rendezvous Mechanism
+
+   Making a contact to a mobile node is slightly more involved.  In
+   order to start the HIP exchange, the initiator node has to know how
+   to reach the mobile node.  Although infrequently moving HIP nodes
+   could use Dynamic DNS [1] to update their reachability information in
+   the DNS, an alternative to using DNS in this fashion is to use a
+   piece of new static infrastructure to facilitate rendezvous between
+   HIP nodes.
+
+   The mobile node keeps the rendezvous infrastructure continuously
+   updated with its current IP address(es).  The mobile nodes must trust
+   the rendezvous mechanism to properly maintain their HIT and IP
+   address mappings.
+
+   The rendezvous mechanism is also needed if both of the nodes happen
+   to change their address at the same time, either because they are
+   mobile and happen to move at the same time, because one of them is
+   off-line for a while, or because of some other reason.  In such a
+   case, the HIP readdress packets will cross each other in the network
+   and never reach the peer node.
+
+   A separate document will specify the details of the HIP rendezvous
+   mechanism.
+
+7.2.  Protection against Flooding Attacks
+
+   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.
+
+   Blindly accepting new addresses would potentially lead to flooding
+   DoS attacks against third parties [8].  In a distributed flooding
+   attack, an attacker opens high-volume HIP connections with a large
+   number of hosts (using unpublished 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 close this attack, HIP
+   includes an address check mechanism where the reachability of a node
+   is separately checked at each address before using the address for
+   larger amounts of traffic.
+
+   Whenever HIP is used between two hosts that fully trust each other,
+   the hosts may optionally decide to skip the address tests.  However,
+
+
+
+Moskowitz & Nikander         Informational                     [Page 13]
+
+RFC 4423       Host Identity Protocol (HIP) Architecture        May 2006
+
+
+   such performance optimization must be restricted to peers that are
+   known to be trustworthy and capable of protecting themselves from
+   malicious software.
+
+8.  HIP and IPsec
+
+   The preferred way of implementing HIP is to use IPsec to carry the
+   actual data traffic.  As of today, the only completely defined method
+   is to use IPsec Encapsulating Security Payload (ESP) to carry the
+   data packets.  In the future, other ways of transporting payload data
+   may be developed, including ones that do not use cryptographic
+   protection.
+
+   In practice, the HIP base exchange uses the cryptographic Host
+   Identifiers to set up a pair of ESP Security Associations (SAs) to
+   enable ESP in an end-to-end manner.  This is implemented in a way
+   that can span addressing realms.
+
+   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 are a
+   number of historical reasons for this, and there are also a few
+   architectural reasons.  First, IKE and IKEv2 were not designed with
+   middle boxes in mind.  As adding a new naming layer allows one to
+   potentially add a new forwarding layer (see Section 9, below), it is
+   very important that the HIP protocols are friendly toward any middle
+   boxes.
+
+   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 particular, the current thinking is limited to a situation
+   where, conceptually, there is only one pair of SAs between any given
+   pair of HITs.  In other words, from an architectural point of view,
+   HIP only supports host-to-host (or endpoint-to-endpoint) Security
+   Associations.  If two hosts need more pairs of parallel SAs, they
+   should use separate HITs for that.  However, future HIP extensions
+   may provide for more granularity and creation of several ESP SAs
+   between a pair of HITs.
+
+   Since 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 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.
+
+
+
+Moskowitz & Nikander         Informational                     [Page 14]
+
+RFC 4423       Host Identity Protocol (HIP) Architecture        May 2006
+
+
+   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 [12].
+
+   Since HIP does not negotiate any SA lifetimes, all lifetimes are
+   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 are received using that SA.
+   Implementations may support lifetimes for the various ESP transforms.
+
+9.  HIP and NATs
+
+   Passing packets between different IP addressing realms requires
+   changing IP addresses in the packet header.  This may happen, 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 Network Address
+   Translation (NAT) [4] or NAT Protocol Translation (NAT-PT) [3].
+
+   In a network environment where identification is based on the IP
+   addresses, identifying the communicating nodes is difficult when NAT
+   is used.  With HIP, the transport-layer end-points are bound to the
+   Host Identities.  Thus, a connection between two hosts can traverse
+   many addressing realm boundaries.  The IP addresses are used only for
+   routing purposes; they may be changed freely during packet traversal.
+
+   For a HIP-based flow, a HIP-aware NAT or NAT-PT system tracks the
+   mapping of HITs, and the corresponding IPsec 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.
+
+   NAT systems cannot touch the datagrams within the IPsec envelope;
+   thus, application-specific address translation must be done in the
+   end systems.  HIP provides for 'Distributed NAT', and uses the HIT or
+   the LSI as a placeholder for embedded IP addresses.
+
+9.1.  HIP and TCP Checksums
+
+   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
+
+
+
+Moskowitz & Nikander         Informational                     [Page 15]
+
+RFC 4423       Host Identity Protocol (HIP) Architecture        May 2006
+
+
+   sending host.  Furthermore, it is not possible to recompute the
+   upper-layer checksums in the NAT/NAT-PT system, since the traffic is
+   IPsec 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.
+
+10.  Multicast
+
+   Back in the Fall of 2003, there were little if any concrete thoughts
+   about how HIP might affect IP-layer or application-layer multicast.
+
+11.  HIP Policies
+
+   There are a number of variables that will influence the HIP exchanges
+   that each host must support.  All HIP implementations should support
+   at least 2 HIs, one to publish in DNS and an unpublished one for
+   anonymous usage.  Although unpublished HIs will be rarely used as
+   responder HIs, they are likely be common for initiators.  Support for
+   multiple HIs is recommended.
+
+   Many initiators would want to use a different HI for different
+   responders.  The implementations should provide for a policy of
+   initiator HIT to responder HIT.  This policy should also include
+   preferred transforms and local lifetimes.
+
+   Responders would need a similar policy, describing the hosts allowed
+   to participate in HIP exchanges, and the preferred transforms and
+   local lifetimes.
+
+12.  Benefits of HIP
+
+   In the beginning, the network layer protocol (i.e., IP) had the
+   following four "classic" invariants:
+
+   o  Non-mutable: The address sent is the address received.
+
+   o  Non-mobile: The address does not change during the course of an
+      "association".
+
+   o  Reversible: A return header can always be formed by reversing the
+      source and destination addresses.
+
+   o  Omniscient: Each host knows what address a partner host can use to
+      send packets to it.
+
+   Actually, the fourth can be inferred from 1 and 3, but it is worth
+   mentioning for reasons that will be obvious soon if not already.
+
+
+
+Moskowitz & Nikander         Informational                     [Page 16]
+
+RFC 4423       Host Identity Protocol (HIP) Architecture        May 2006
+
+
+   In the current "post-classic" world, we are intentionally trying to
+   get rid of the second invariant (both for mobility and for multi-
+   homing), and we have been forced to give up the first and the fourth.
+   Realm Specific IP [5] is an attempt to reinstate the fourth invariant
+   without the first invariant.  IPv6 is an attempt to reinstate the
+   first invariant.
+
+   Few 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 a particular system.
+   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.
+
+   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, distributed database, is also the
+   repository of other namespaces, due in part to DNSSEC-specific and
+   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.
+
+   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 one 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, then things
+   work OK because HIP takes care of host identification, and
+   reversibility allows one to get a packet back to one's partner host.
+   You do not care if the network-layer address changes in transit
+   (mutable), and you do not care what network-layer address the partner
+   is using (non-omniscient).
+
+12.1.  HIP's Answers to NSRG Questions
+
+   The IRTF Name Space Research Group has posed a number of evaluating
+   questions in its report [7].  In this section, we provide answers to
+   these questions.
+
+   1.  How would a stack name improve the overall functionality of the
+       Internet?
+
+          HIP decouples the internetworking layer from the transport
+          layer, allowing each to evolve separately.  The decoupling
+          makes end-host mobility and multi-homing easier, also across
+
+
+
+Moskowitz & Nikander         Informational                     [Page 17]
+
+RFC 4423       Host Identity Protocol (HIP) Architecture        May 2006
+
+
+          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.
+
+   2.  What does a stack name look like?
+
+          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.
+
+   3.  What is its lifetime?
+
+          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.
+
+   4.  Where does it live in the stack?
+
+          The HIs live between the transport and internetworking layers.
+
+   5.  How is it used on the end-points?
+
+          The Host Identifiers may be used directly or indirectly (in
+          the form of HITs or LSIs) by applications when they access
+          network services.  In addition, 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.
+
+   6.  What administrative infrastructure is needed to support it?
+
+          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 a new rendezvous mechanism is needed.  Such a
+          new rendezvous mechanism may need new infrastructure to be
+          deployed.
+
+   7.  If we add an additional layer, would it make the address list in
+       Stream Control Transmission Protocol (SCTP) unnecessary?
+
+          Yes.
+
+
+
+
+
+Moskowitz & Nikander         Informational                     [Page 18]
+
+RFC 4423       Host Identity Protocol (HIP) Architecture        May 2006
+
+
+   8.  What additional security benefits would a new naming scheme
+       offer?
+
+          HIP reduces dependency on IP addresses, making the so-called
+          address ownership [11] problems easier to solve.  In practice,
+          HIP provides security for end-host mobility and multi-homing.
+          Furthermore, since HIP Host Identifiers are public keys,
+          standard public key certificate infrastructures can be applied
+          on the top of HIP.
+
+   9.  What would the resolution mechanisms be, or what characteristics
+       of a resolution mechanisms would be required?
+
+          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.
+
+13.  Security Considerations
+
+   HIP takes advantage of the new Host Identity paradigm to provide
+   secure authentication of hosts and to provide a fast key exchange for
+   IPsec.  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.
+
+   Resource-exhausting DoS attacks take advantage of the cost of setting
+   up a state for a protocol on the responder compared to the
+   'cheapness' on the initiator.  HIP allows a responder to increase the
+   cost of the start of state on the initiator and makes an effort to
+   reduce the cost to the responder.  This is done by having the
+   responder start the authenticated Diffie-Hellman exchange instead of
+   the initiator, making the HIP base exchange 4 packets long.  There
+   are more details on this process in the Host Identity Protocol.
+
+   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 HIP packet that it can pre-build.  Since this
+
+
+
+Moskowitz & Nikander         Informational                     [Page 19]
+
+RFC 4423       Host Identity Protocol (HIP) Architecture        May 2006
+
+
+   packet is fixed and easily replayed, the initiator reacts to it only
+   if it has just started a connection to the responder.
+
+   MitM attacks are difficult to defend 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 an MitM attack.  If the responder's HI is retrieved
+   from a signed DNS zone or secured by some other means, the initiator
+   can use this to authenticate the signed HIP packets.  Likewise, if
+   the initiator's HI is in a secure DNS zone, the responder can
+   retrieve it and validate the signed HIP packets.  However, since an
+   initiator may choose to use an unpublished HI, it knowingly risks an
+   MitM attack.  The responder may choose not to accept a HIP exchange
+   with an initiator using an unknown HI.
+
+   In HIP, the Security Association for IPsec is indexed by the SPI; the
+   source address is always ignored, and the destination address may be
+   ignored as well.  Therefore, HIP-enabled IPsec Encapsulated Security
+   Payload (ESP) is IP address independent.  This might seem to make it
+   easier for an attacker, 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 IPsec ESP to DoS attacks.
+
+   Since not all hosts will ever support HIP, ICMPv4 'Destination
+   Unreachable, Protocol Unreachable' and ICMPv6 'Parameter Problem,
+   Unrecognized Next Header' messages are to be expected and present a
+   DoS attack.  Against an initiator, the attack would look like the
+   responder does not support HIP, but shortly after receiving the ICMP
+   message, the initiator would receive a valid HIP packet.  Thus, to
+   protect against this attack, an initiator should not react to an ICMP
+   message until a reasonable time has passed, allowing it to get the
+   real responder's HIP packet.  A similar attack against the responder
+   is more involved.
+
+   Another MitM attack is simulating a responder's administrative
+   rejection of a HIP initiation.  This is a simple ICMP 'Destination
+   Unreachable, Administratively Prohibited' message.  A HIP packet is
+   not used because it would have to either have unique content, and
+   thus difficult to generate, resulting in yet another DoS attack, or
+   be just as spoofable as the ICMP message.  Like in the previous case,
+   the defense against this attack is for the initiator to wait a
+   reasonable time period to get a valid HIP packet.  If one does not
+   come, then the initiator has to assume that the ICMP message is
+   valid.  Since this is the only point in the HIP base exchange where
+   this ICMP message is appropriate, it can be ignored at any other
+   point in the exchange.
+
+
+
+
+
+Moskowitz & Nikander         Informational                     [Page 20]
+
+RFC 4423       Host Identity Protocol (HIP) Architecture        May 2006
+
+
+13.1.  HITs Used in ACLs
+
+   It is expected that HITs will be used in Access Control Lists (ACLs).
+   Future firewalls can use HITs to control egress and ingress to
+   networks, with an assurance level difficult to achieve today.  As
+   discussed above in Section 8, once a HIP session has been
+   established, the SPI value in an IPsec 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 IPsec usage, dynamically
+   opening IPsec 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 happening between two known hosts.  This may
+   increase firewall security.
+
+   There has been considerable bad experience with distributed ACLs that
+   contain public-key-related material, for example, with Secure SHell
+   Protocol (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.
+
+   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 hosts.  With this information, the host can notify the
+   various hosts about the change to the HIT.  There has been no attempt
+   to develop a secure method to issue the HIT revocation notice.
+
+   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 get updated
+   with the HIT change.
+
+13.2.  Non-security considerations
+
+   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; for
+   example, an FQDN.  This document does not describe how to support
+   such a non-cryptographic HI.  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.  Since such a mode would offer so little additional
+   functionality for so much addition to the IP kernel, it has not been
+
+
+
+Moskowitz & Nikander         Informational                     [Page 21]
+
+RFC 4423       Host Identity Protocol (HIP) Architecture        May 2006
+
+
+   defined.  Given how little public key cryptography HIP requires, HIP
+   should only be implemented using public key Host Identities.
+
+   If it is desirable to use HIP in a 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.
+
+14.  Acknowledgements
+
+   For the people historically involved in the early stages of HIP, see
+   the Acknowledgements section in the Host Identity Protocol
+   specification.
+
+   During the later stages of this document, when the editing baton was
+   transfered to Pekka Nikander, the comments from the early
+   implementors and others, including Jari Arkko, Tom Henderson, Petri
+   Jokela, Miika Komu, Mika Kousa, Andrew McGregor, Jan Melen, Tim
+   Shepard, Jukka Ylitalo, and Jorma Wall, were invaluable.  Finally,
+   Lars Eggert, Spencer Dawkins, and Dave Crocker provided valuable
+   input during the final stages of publication, most of which was
+   incorporated but some of which the authors decided to ignore in order
+   to get this document published in the first place.
+
+15.  Informative References
+
+   [1]   Vixie, P., Thomson,  S., Rekhter, Y., and J. Bound, "Dynamic
+         Updates in the Domain Name System (DNS UPDATE)", RFC 2136,
+         April 1997.
+
+   [2]   Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,
+         "DNS Security Introduction and Requirements", RFC 4033, March
+         2005.
+
+         Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,
+         "Resource Records for the DNS Security Extensions", RFC 4034,
+         March 2005.
+
+         Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,
+         "Protocol Modifications for the DNS Security Extensions", RFC
+         4035, March 2005
+
+   [3]   Tsirtsis, G. and P. Srisuresh, "Network Address Translation -
+         Protocol Translation (NAT-PT)", RFC 2766, February 2000.
+
+
+
+
+Moskowitz & Nikander         Informational                     [Page 22]
+
+RFC 4423       Host Identity Protocol (HIP) Architecture        May 2006
+
+
+   [4]   Srisuresh, P. and K. Egevang, "Traditional IP Network Address
+         Translator (Traditional NAT)", RFC 3022, January 2001.
+
+   [5]   Borella, M., Lo, J., Grabelsky, D., and G. Montenegro, "Realm
+         Specific IP: Framework", RFC 3102, October 2001.
+
+   [6]   Richardson, M., "A Method for Storing IPsec Keying Material in
+         DNS", RFC 4025, March 2005.
+
+   [7]   Lear, E. and R. Droms, "What's In A Name: Thoughts from the
+         NSRG", Work in Progress, September 2003.
+
+   [8]   Nikander, P., et al, "Mobile IP Version 6 Route Optimization
+         Security Design Background", RFC 4225, December 2005.
+
+   [9]   Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", RFC
+         4306, December 2005.
+
+   [10]  Chiappa, J., "Endpoints and Endpoint Names: A Proposed
+         Enhancement to the Internet Architecture", URL
+         http://users.exis.net/~jnc/tech/endpoints.txt, 1999.
+
+   [11]  Nikander, P., "Denial-of-Service, Address Ownership, and Early
+         Authentication in the IPv6 World", in Security Protocols, 9th
+         International Workshop, Cambridge, UK, April 25-27 2001, LNCS
+         2467, pp. 12-26, Springer, 2002.
+
+   [12]  Bellovin, S., "EIDs, IPsec, and HostNAT", in Proceedings of the
+         41st IETF, Los Angeles, CA, March 1998.
+
+Authors' Addresses
+
+   Robert Moskowitz
+   ICSAlabs, a Division of Cybertrust Corporation
+   1000 Bent Creek Blvd, Suite 200
+   Mechanicsburg, PA
+   USA
+
+   EMail: rgm@icsalabs.com
+
+
+   Pekka Nikander
+   Ericsson Research Nomadic Lab
+   JORVAS  FIN-02420
+   FINLAND
+
+   Phone: +358 9 299 1
+   EMail: pekka.nikander@nomadiclab.com
+
+
+
+Moskowitz & Nikander         Informational                     [Page 23]
+
+RFC 4423       Host Identity Protocol (HIP) Architecture        May 2006
+
+
+Full Copyright Statement
+
+   Copyright (C) The Internet Society (2006).
+
+   This document is subject to the rights, licenses and restrictions
+   contained in BCP 78, and except as set forth therein, the authors
+   retain all their rights.
+
+   This document and the information contained herein are provided on an
+   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
+   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
+   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
+   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
+   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Intellectual Property
+
+   The IETF takes no position regarding the validity or scope of any
+   Intellectual Property Rights or other rights that might be claimed to
+   pertain to the implementation or use of the technology described in
+   this document or the extent to which any license under such rights
+   might or might not be available; nor does it represent that it has
+   made any independent effort to identify any such rights.  Information
+   on the procedures with respect to rights in RFC documents can be
+   found in BCP 78 and BCP 79.
+
+   Copies of IPR disclosures made to the IETF Secretariat and any
+   assurances of licenses to be made available, or the result of an
+   attempt made to obtain a general license or permission for the use of
+   such proprietary rights by implementers or users of this
+   specification can be obtained from the IETF on-line IPR repository at
+   http://www.ietf.org/ipr.
+
+   The IETF invites any interested party to bring to its attention any
+   copyrights, patents or patent applications, or other proprietary
+   rights that may cover technology that may be required to implement
+   this standard.  Please address the information to the IETF at
+   ietf-ipr@ietf.org.
+
+Acknowledgement
+
+   Funding for the RFC Editor function is provided by the IETF
+   Administrative Support Activity (IASA).
+
+
+
+
+
+
+
+Moskowitz & Nikander         Informational                     [Page 24]
+