Request for Comments: 4423 ICSAlabs, a Division of TruSecure
Category: Informational Corporation
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
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
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.
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.
+--------------+----------------------------------------------------+
| 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). |
+--------------+----------------------------------------------------+
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.
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.
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.
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