draft-ietf-hip-rfc4423-bis-07.txt   draft-ietf-hip-rfc4423-bis-08.txt 
Network Working Group R. Moskowitz, Ed. Network Working Group R. Moskowitz, Ed.
Internet-Draft Verizon Internet-Draft Verizon
Obsoletes: 4423 (if approved) M. Komu Obsoletes: 4423 (if approved) M. Komu
Intended status: Informational Aalto Intended status: Informational Aalto
Expires: June 21, 2014 December 18, 2013 Expires: October 26, 2014 April 24, 2014
Host Identity Protocol Architecture Host Identity Protocol Architecture
draft-ietf-hip-rfc4423-bis-07 draft-ietf-hip-rfc4423-bis-08
Abstract Abstract
This memo describes a new namespace, the Host Identity namespace, and This memo describes a new namespace, the Host Identity namespace, and
a new protocol layer, the Host Identity Protocol, between the a new protocol layer, the Host Identity Protocol, between the
internetworking and transport layers. Herein are presented the internetworking and transport layers. Herein are presented the
basics of the current namespaces, their strengths and weaknesses, and basics of the current namespaces, their strengths and weaknesses, and
how a new namespace will add completeness to them. The roles of this how a new namespace will add completeness to them. The roles of this
new namespace in the protocols are defined. new namespace in the protocols are defined.
This document obsoletes RFC 4423 and addresses the concerns raised by This document obsoletes RFC 4423 and addresses the concerns raised by
the IESG, particularly that of crypto agility. It incorporates the IESG, particularly that of crypto agility. It incorporates
lessons learned from the implementations of RFC 5201 and goes further lessons learned from the implementations of RFC 5201 and goes further
to explain how HIP works as a secure signaling channel. to explain how HIP works as a secure signaling channel.
Status of this Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on June 21, 2014. This Internet-Draft will expire on October 26, 2014.
Copyright Notice Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the Copyright (c) 2014 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
skipping to change at page 3, line 7 skipping to change at page 2, line 26
modifications of such material outside the IETF Standards Process. modifications of such material outside the IETF Standards Process.
Without obtaining an adequate license from the person(s) controlling Without obtaining an adequate license from the person(s) controlling
the copyright in such materials, this document may not be modified the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other it for publication as an RFC or to translate it into languages other
than English. than English.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.1. Terms common to other documents . . . . . . . . . . . . . 5 2.1. Terms common to other documents . . . . . . . . . . . . . . 4
2.2. Terms specific to this and other HIP documents . . . . . 5 2.2. Terms specific to this and other HIP documents . . . . . . 5
3. Background . . . . . . . . . . . . . . . . . . . . . . . 7 3. Background . . . . . . . . . . . . . . . . . . . . . . . . . 6
3.1. A desire for a namespace for computing platforms . . . . 7 3.1. A desire for a namespace for computing platforms . . . . . 6
4. Host Identity namespace . . . . . . . . . . . . . . . . . 9 4. Host Identity namespace . . . . . . . . . . . . . . . . . . . 8
4.1. Host Identifiers . . . . . . . . . . . . . . . . . . . . 10 4.1. Host Identifiers . . . . . . . . . . . . . . . . . . . . . 9
4.2. Host Identity Hash (HIH) . . . . . . . . . . . . . . . . 11 4.2. Host Identity Hash (HIH) . . . . . . . . . . . . . . . . . 10
4.3. Host Identity Tag (HIT) . . . . . . . . . . . . . . . . . 11 4.3. Host Identity Tag (HIT) . . . . . . . . . . . . . . . . . . 10
4.4. Local Scope Identifier (LSI) . . . . . . . . . . . . . . 11 4.4. Local Scope Identifier (LSI) . . . . . . . . . . . . . . . 11
4.5. Storing Host Identifiers in directories . . . . . . . . . 12 4.5. Storing Host Identifiers in directories . . . . . . . . . . 12
5. New stack architecture . . . . . . . . . . . . . . . . . 13 5. New stack architecture . . . . . . . . . . . . . . . . . . . 12
5.1. On the multiplicity of identities . . . . . . . . . . . . 14 5.1. On the multiplicity of identities . . . . . . . . . . . . . 13
6. Control plane . . . . . . . . . . . . . . . . . . . . . . 15 6. Control plane . . . . . . . . . . . . . . . . . . . . . . . . 14
6.1. Base exchange . . . . . . . . . . . . . . . . . . . . . . 15 6.1. Base exchange . . . . . . . . . . . . . . . . . . . . . . . 14
6.2. End-host mobility and multi-homing . . . . . . . . . . . 16 6.2. End-host mobility and multi-homing . . . . . . . . . . . . 15
6.3. Rendezvous mechanism . . . . . . . . . . . . . . . . . . 16 6.3. Rendezvous mechanism . . . . . . . . . . . . . . . . . . . 16
6.4. Relay mechanism . . . . . . . . . . . . . . . . . . . . . 17 6.4. Relay mechanism . . . . . . . . . . . . . . . . . . . . . . 16
6.5. Termination of the control plane . . . . . . . . . . . . 17 6.5. Termination of the control plane . . . . . . . . . . . . . 16
7. Data plane . . . . . . . . . . . . . . . . . . . . . . . 17 7. Data plane . . . . . . . . . . . . . . . . . . . . . . . . . 16
8. HIP and NATs . . . . . . . . . . . . . . . . . . . . . . 18 8. HIP and NATs . . . . . . . . . . . . . . . . . . . . . . . . 17
8.1. HIP and Upper-layer checksums . . . . . . . . . . . . . . 19 8.1. HIP and Upper-layer checksums . . . . . . . . . . . . . . . 18
9. Multicast . . . . . . . . . . . . . . . . . . . . . . . . 19 9. Multicast . . . . . . . . . . . . . . . . . . . . . . . . . . 18
10. HIP policies . . . . . . . . . . . . . . . . . . . . . . 19 10. HIP policies . . . . . . . . . . . . . . . . . . . . . . . . 18
11. Design considerations . . . . . . . . . . . . . . . . . . 20 11. Design considerations . . . . . . . . . . . . . . . . . . . . 19
11.1. Benefits of HIP . . . . . . . . . . . . . . . . . . . . . 20 11.1. Benefits of HIP . . . . . . . . . . . . . . . . . . . . . 19
11.2. Drawbacks of HIP . . . . . . . . . . . . . . . . . . . . 23 11.2. Drawbacks of HIP . . . . . . . . . . . . . . . . . . . . . 22
11.3. Deployment and adoption considerations . . . . . . . . . 24 11.3. Deployment and adoption considerations . . . . . . . . . . 23
11.3.1. Deployment analysis . . . . . . . . . . . . . . . . . . . 24 11.3.1. Deployment analysis . . . . . . . . . . . . . . . . . . 23
11.3.2. HIP in 802.15.4 networks . . . . . . . . . . . . . . . . 25 11.3.2. HIP in 802.15.4 networks . . . . . . . . . . . . . . . . 24
11.4. Answers to NSRG questions . . . . . . . . . . . . . . . . 26 11.4. Answers to NSRG questions . . . . . . . . . . . . . . . . 25
12. Security considerations . . . . . . . . . . . . . . . . . 28 12. Security considerations . . . . . . . . . . . . . . . . . . . 27
12.1. MiTM Attacks . . . . . . . . . . . . . . . . . . . . . . 28 12.1. MiTM Attacks . . . . . . . . . . . . . . . . . . . . . . . 27
12.2. Protection against flooding attacks . . . . . . . . . . . 29 12.2. Protection against flooding attacks . . . . . . . . . . . 28
12.3. HITs used in ACLs . . . . . . . . . . . . . . . . . . . . 30 12.3. HITs used in ACLs . . . . . . . . . . . . . . . . . . . . 29
12.4. Alternative HI considerations . . . . . . . . . . . . . . 31 12.4. Alternative HI considerations . . . . . . . . . . . . . . 30
13. IANA considerations . . . . . . . . . . . . . . . . . . . 32 13. IANA considerations . . . . . . . . . . . . . . . . . . . . . 31
14. Acknowledgments . . . . . . . . . . . . . . . . . . . . . 32 14. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 31
15. Changes from RFC 4423 . . . . . . . . . . . . . . . . . . 32 15. Changes from RFC 4423 . . . . . . . . . . . . . . . . . . . . 31
16. References . . . . . . . . . . . . . . . . . . . . . . . 33 16. References . . . . . . . . . . . . . . . . . . . . . . . . . 31
16.1. Normative References . . . . . . . . . . . . . . . . . . 33 16.1. Normative References . . . . . . . . . . . . . . . . . . . 32
16.2. Informative references . . . . . . . . . . . . . . . . . 34 16.2. Informative references . . . . . . . . . . . . . . . . . . 33
Authors' Addresses . . . . . . . . . . . . . . . . . . . 40 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 39
1. Introduction 1. Introduction
The Internet has two important global namespaces: Internet Protocol The Internet has two important global namespaces: Internet Protocol
(IP) addresses and Domain Name Service (DNS) names. These two (IP) addresses and Domain Name Service (DNS) names. These two
namespaces have a set of features and abstractions that have powered namespaces have a set of features and abstractions that have powered
the Internet to what it is today. They also have a number of the Internet to what it is today. They also have a number of
weaknesses. Basically, since they are all we have, we try and do too weaknesses. Basically, since they are all we have, we try and do too
much with them. Semantic overloading and functionality extensions much with them. Semantic overloading and functionality extensions
have greatly complicated these namespaces. have greatly complicated these namespaces.
The proposed Host Identity namespace fills an important gap between The proposed Host Identity namespace fills an important gap between
the IP and DNS namespaces. A Host Identity conceptually refers to a the IP and DNS namespaces. A Host Identity conceptually refers to a
computing platform, and there may be multiple such Host Identities computing platform, and there may be multiple such Host Identities
per computing platform (because the platform may wish to present a per computing platform (because the platform may wish to present a
different identity to different communicating peers). The Host different identity to different communicating peers). The Host
Identity namespace consists of Host Identifiers (HI). There is Identity namespace consists of Host Identifiers (HI). There is
exactly one Host Identifier for each Host Identity. While this text exactly one Host Identifier for each Host Identity (although there
later talks about non-cryptographic Host Identifiers, the may be transient periods of time such as key replacement when more
architecture focuses on the case in which Host Identifiers are than one identifier may be active). While this text later talks
cryptographic in nature. Specifically, the Host Identifier is the about non-cryptographic Host Identifiers, the architecture focuses on
public key of an asymmetric key-pair. Each Host Identity uniquely the case in which Host Identifiers are cryptographic in nature.
identifies a single host, i.e., no two hosts have the same Host Specifically, the Host Identifier is the public key of an asymmetric
Identity. If two or more computing platforms have the same Host key-pair. Each Host Identity uniquely identifies a single host,
Identifier, then they are instantiating a distributed host. The Host i.e., no two hosts have the same Host Identity. If two or more
Identifier can either be public (e.g. published in the DNS), or computing platforms have the same Host Identifier, then they are
unpublished. Client systems will tend to have both public and instantiating a distributed host. The Host Identifier can either be
unpublished Host Identifiers. public (e.g. published in the DNS), or unpublished. Client systems
will tend to have both public and unpublished Host Identifiers.
There is a subtle but important difference between Host Identities There is a subtle but important difference between Host Identities
and Host Identifiers. An Identity refers to the abstract entity that and Host Identifiers. An Identity refers to the abstract entity that
is identified. An Identifier, on the other hand, refers to the is identified. An Identifier, on the other hand, refers to the
concrete bit pattern that is used in the identification process. concrete bit pattern that is used in the identification process.
Although the Host Identifiers could be used in many authentication Although the Host Identifiers could be used in many authentication
systems, such as IKEv2 [RFC4306], the presented architecture systems, such as IKEv2 [RFC4306], the presented architecture
introduces a new protocol, called the Host Identity Protocol (HIP), introduces a new protocol, called the Host Identity Protocol (HIP),
and a cryptographic exchange, called the HIP base exchange; see also and a cryptographic exchange, called the HIP base exchange; see also
Section 7. HIP provides for limited forms of trust between systems, Section 6. HIP provides for limited forms of trust between systems,
enhance mobility, multi-homing and dynamic IP renumbering, aid in enhance mobility, multi-homing and dynamic IP renumbering, aid in
protocol translation / transition, and reduce certain types of protocol translation / transition, and reduce certain types of
denial-of-service (DoS) attacks. denial-of-service (DoS) attacks.
When HIP is used, the actual payload traffic between two HIP hosts is When HIP is used, the actual payload traffic between two HIP hosts is
typically, but not necessarily, protected with ESP. The Host typically, but not necessarily, protected with ESP
Identities are used to create the needed ESP Security Associations [I-D.ietf-hip-rfc5202-bis]. The Host Identities are used to create
(SAs) and to authenticate the hosts. When ESP is used, the actual the needed ESP Security Associations (SAs) and to authenticate the
payload IP packets do not differ in any way from standard ESP hosts. When ESP is used, the actual payload IP packets do not differ
protected IP packets. in any way from standard ESP protected IP packets.
Much has been learned about HIP [RFC6538] since [RFC4423] was Much has been learned about HIP [RFC6538] since [RFC4423] was
published. This document expands Host Identities beyond use to published. This document expands Host Identities beyond use to
enable IP connectivity and security to general interhost secure enable IP connectivity and security to general interhost secure
signalling at any protocol layer. The signal may establish a signalling at any protocol layer. The signal may establish a
security association between the hosts, or simply pass information security association between the hosts, or simply pass information
within the channel. within the channel.
2. Terminology 2. Terminology
2.1. Terms common to other documents 2.1. Terms common to other documents
+---------------+---------------------------------------------------+ +-------------+-----------------------------------------------------+
| Term | Explanation | | Term | Explanation |
+---------------+---------------------------------------------------+ +-------------+-----------------------------------------------------+
| Public key | The public key of an asymmetric cryptographic key | | Public key | The public key of an asymmetric cryptographic key |
| | pair. Used as a publicly known identifier for | | | pair. Used as a publicly known identifier for |
| | cryptographic identity authentication. Public is | | | cryptographic identity authentication. Public is a |
| | a relative term here, ranging from known to peers | | | a relative term here, ranging from "known to peers |
| | only to known to the World. | | | only" to "known to the world." |
| | | | Private key | The private or secret key of an asymmetric |
| Private key | The private or secret key of an asymmetric | | | cryptographic key pair. Assumed to be known only |
| | cryptographic key pair. Assumed to be known only | | | to the party identified by the corresponding public |
| | to the party identified by the corresponding | | | key. Used by the identified party to authenticate |
| | public key. Used by the identified party to | | | its identity to other parties. |
| | authenticate its identity to other parties. | | Public key | An asymmetric cryptographic key pair consisting of |
| | | | pair | public and private keys. For example, Rivest- |
| Public key | An asymmetric cryptographic key pair consisting | | | Shamir-Adelman (RSA), Digital Signature Algorithm |
| pair | of public and private keys. For example, | | | (DSA) and Elliptic Curve DSA (ECDSA) key pairs are |
| | Rivest-Shamir-Adelman (RSA), Digital Signature | | | such key pairs. |
| | Algorithm (DSA) and Elliptic Curve DSA (ECDSA) | | End-point | A communicating entity. For historical reasons, |
| | key pairs are such key pairs. | | | the term 'computing platform' is used in this |
| | | | | document as a (rough) synonym for end-point. |
| End-point | A communicating entity. For historical reasons, | +-------------+-----------------------------------------------------+
| | the term 'computing platform' is used in this |
| | document as a (rough) synonym for end-point. |
+---------------+---------------------------------------------------+
2.2. Terms specific to this and other HIP documents 2.2. Terms specific to this and other HIP documents
It should be noted that many of the terms defined herein are It should be noted that many of the terms defined herein are
tautologous, self-referential or defined through circular reference tautologous, self-referential or defined through circular reference
to other terms. This is due to the succinct nature of the to other terms. This is due to the succinct nature of the
definitions. See the text elsewhere in this document and in RFC 5201 definitions. See the text elsewhere in this document and in RFC 5201
[I-D.ietf-hip-rfc5201-bis] for more elaborate explanations. [I-D.ietf-hip-rfc5201-bis] for more elaborate explanations.
+---------------+---------------------------------------------------+ +-------------------+-----------------------------------------------+
| Term | Explanation | | Term | Explanation |
+---------------+---------------------------------------------------+ +-------------------+-----------------------------------------------+
| Computing | An entity capable of communicating and computing, | | Computing | An entity capable of communicating and |
| platform | for example, a computer. See the definition of | | platform | computing, for example, a computer. See the |
| | 'End-point', above. | | | definition of 'End-point', above. |
| | | | HIP base exchange | A cryptographic protocol; see also Section 6. |
| HIP base | A cryptographic protocol; see also Section 7. | | HIP packet | An IP packet that carries a 'Host Identity |
| exchange | | | | Protocol' message. |
| | | | Host Identity | An abstract concept assigned to a 'computing |
| HIP packet | An IP packet that carries a 'Host Identity | | | platform'. See 'Host Identifier', below. |
| | Protocol' message. | | Host Identity | A name space formed by all possible Host |
| | | | namespace | Identifiers. |
| Host Identity | An abstract concept assigned to a 'computing | | Host Identity | A protocol used to carry and authenticate |
| | platform'. See 'Host Identifier', below. | | Protocol | Host Identifiers and other information. |
| | | | Host Identity | The cryptographic hash used in creating the |
| Host Identity | A name space formed by all possible Host | | Hash | Host Identity Tag from the Host Identity. |
| namespace | Identifiers. | | Host Identity Tag | A 128-bit datum created by taking a |
| | | | | cryptographic hash over a Host Identifier |
| Host Identity | A protocol used to carry and authenticate Host | | | plus bits to identify which hash used. |
| Protocol | Identifiers and other information. | | Host Identifier | A public key used as a name for a Host |
| | | | | Identity. |
| Host Identity | The cryptographic hash used in creating the Host | | Local Scope | A 32-bit datum denoting a Host Identity. |
| Hash | Identity Tag from the Host Identity. | | Identifier | |
| | | | Public Host | A published or publicly known Host Identifier |
| Host Identity | A 128-bit datum created by taking a cryptographic | | Identifier and | used as a public name for a Host Identity, |
| Tag | hash over a Host Identifier plus bits to identify | | Identity | and the corresponding Identity. |
| | which hash used. | | Unpublished Host | A Host Identifier that is not placed in any |
| | | | Identifier and | public directory, and the corresponding Host |
| Host | A public key used as a name for a Host Identity. | | Identity | Identity. Unpublished Host Identities are |
| Identifier | | | | typically short lived in nature, being often |
| | | | | replaced and possibly used just once. |
| Local Scope | A 32-bit datum denoting a Host Identity. | | Rendezvous | A mechanism used to locate mobile hosts based |
| Identifier | | | Mechanism | on their HIT. |
| | | +-------------------+-----------------------------------------------+
| Public Host | A published or publicly known Host Identifier |
| Identifier | used as a public name for a Host Identity, and |
| and Identity | the corresponding Identity. |
| | |
| Unpublished | A Host Identifier that is not placed in any |
| Host | public directory, and the corresponding Host |
| Identifier | Identity. Unpublished Host Identities are |
| and Identity | typically short lived in nature, being often |
| | replaced and possibly used just once. |
| | |
| Rendezvous | A mechanism used to locate mobile hosts based on |
| Mechanism | their HIT. |
+---------------+---------------------------------------------------+
3. Background 3. Background
The Internet is built from three principal components: computing The Internet is built from three principal components: computing
platforms (end-points), packet transport (i.e., internetworking) platforms (end-points), packet transport (i.e., internetworking)
infrastructure, and services (applications). The Internet exists to infrastructure, and services (applications). The Internet exists to
service two principal components: people and robotic services service two principal components: people and robotic services
(silicon-based people, if you will). All these components need to be (silicon-based people, if you will). All these components need to be
named in order to interact in a scalable manner. Here we concentrate named in order to interact in a scalable manner. Here we concentrate
on naming computing platforms and packet transport elements. on naming computing platforms and packet transport elements.
skipping to change at page 8, line 47 skipping to change at page 7, line 51
computational concern in affordability. computational concern in affordability.
o Name collisions should be avoided as much as possible. The o Name collisions should be avoided as much as possible. The
mathematics of the birthday paradox can be used to estimate the mathematics of the birthday paradox can be used to estimate the
chance of a collision in a given population and hash space. In 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 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 to obtain a collision after approximately 1.2*sqrt(2**n) hashes
were obtained. For 64 bits, this number is roughly 4 billion. A 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 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 large population; for example, there is a 1% chance of collision
in a population of 640M. For 100 bits (or more), we would not in a population of 640M. For 100 bits (or more), we would not
expect a collision until approximately 2**50 (1 quadrillion) expect a collision until approximately 2**50 (1 quadrillion)
hashes were generated. hashes were generated.
o The names should have a localized abstraction so that it can be o The names should have a localized abstraction so that they can be
used in existing protocols and APIs. used in existing protocols and APIs.
o It must be possible to create names locally. When such names are o It must be possible to create names locally. When such names are
not published, this can provide anonymity at the cost of making not published, this can provide anonymity at the cost of making
resolvability very difficult. resolvability very difficult.
o The namespace should provide authentication services. o The namespace should provide authentication services.
o The names should be long lived, but replaceable at any time. This o The names should be long lived, but replaceable at any time. This
impacts access control lists; short lifetimes will tend to result impacts access control lists; short lifetimes will tend to result
skipping to change at page 9, line 45 skipping to change at page 8, line 47
to another namespace. It is expected that the Host Identifiers will to another namespace. It is expected that the Host Identifiers will
initially be authenticated with DNSSEC and that all implementations initially be authenticated with DNSSEC and that all implementations
will support DNSSEC as a minimal baseline. will support DNSSEC as a minimal baseline.
In theory, any name that can claim to be 'statistically globally In theory, any name that can claim to be 'statistically globally
unique' may serve as a Host Identifier. In the HIP architecture, the 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 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 Identifier because it can be self managed and it is computationally
difficult to forge. As specified in the Host Identity Protocol difficult to forge. As specified in the Host Identity Protocol
[I-D.ietf-hip-rfc5201-bis] specification, a public-key-based HI can [I-D.ietf-hip-rfc5201-bis] specification, a public-key-based HI can
authenticate the HIP packets and protect them for man-in-the-middle authenticate the HIP packets and protect them from man-in-the-middle
attacks. Since authenticated datagrams are mandatory to provide much attacks. Since authenticated datagrams are mandatory to provide much
of HIP's denial-of-service protection, the Diffie-Hellman exchange in of HIP's denial-of-service protection, the Diffie-Hellman exchange in
HIP BEX has to be authenticated. Thus, only public-key HI and HIP base exchange has to be authenticated. Thus, only public-key HI
authenticated HIP messages are supported in practice. and authenticated HIP messages are supported in practice.
In this document, the non-cryptographic forms of HI and HIP are In this document, the non-cryptographic forms of HI and HIP are
presented to complete the theory of HI, but they should not be presented to complete the theory of HI, but they should not be
implemented as they could produce worse denial-of-service attacks implemented as they could produce worse denial-of-service attacks
than the Internet has without Host Identity. There has been past than the Internet has without Host Identity. There has been past
research in challenge puzzles to use non-cryptographic HI, for Radio research in challenge puzzles to use non-cryptographic HI, for Radio
Frequency IDentification (RFID), in an HIP exchange tailored to the Frequency IDentification (RFID), in an HIP exchange tailored to the
workings of such challenges (as described further in [urien-rfid] and workings of such challenges (as described further in [urien-rfid] and
[urien-rfid-draft]). [urien-rfid-draft]).
skipping to change at page 11, line 8 skipping to change at page 10, line 17
may be stored in various DNS or other directories as identified may be stored in various DNS or other directories as identified
elsewhere in this document, and they are passed in the HIP base elsewhere in this document, and they are passed in the HIP base
exchange. A Host Identity Tag (HIT) is used in other protocols to exchange. A Host Identity Tag (HIT) is used in other protocols to
represent the Host Identity. Another representation of the Host represent the Host Identity. Another representation of the Host
Identities, the Local Scope Identifier (LSI), can also be used in Identities, the Local Scope Identifier (LSI), can also be used in
protocols and APIs. protocols and APIs.
4.2. Host Identity Hash (HIH) 4.2. Host Identity Hash (HIH)
The Host Identity Hash is the cryptographic hash algorithm used in The Host Identity Hash is the cryptographic hash algorithm used in
producing the HIT from the HI. It is also the hash used through out producing the HIT from the HI. It is also the hash used throughout
the HIP protocol for consistency and simplicity. It is possible to the HIP protocol for consistency and simplicity. It is possible to
for the two hosts in the HIP exchange to use different hash for the two hosts in the HIP exchange to use different hash
algorithms. algorithms.
Multiple HIHs within HIP are needed to address the moving target of Multiple HIHs within HIP are needed to address the moving target of
creation and eventual compromise of cryptographic hashes. This creation and eventual compromise of cryptographic hashes. This
significantly complicates HIP and offers an attacker an additional significantly complicates HIP and offers an attacker an additional
downgrade attack that is mitigated in the HIP protocol downgrade attack that is mitigated in the HIP protocol
[I-D.ietf-hip-rfc5201-bis]. [I-D.ietf-hip-rfc5201-bis].
skipping to change at page 11, line 37 skipping to change at page 10, line 46
identity in a consistent format to the protocol independent of the identity in a consistent format to the protocol independent of the
cryptographic algorithms used. cryptographic algorithms used.
In essence, the HIT is a hash over the public key. As such, two 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 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 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 bit presentation of the HIT. As the two communicating parties may
support different algorithms, [I-D.ietf-hip-rfc5201-bis] defines the support different algorithms, [I-D.ietf-hip-rfc5201-bis] defines the
minimum set for interoperability. For further interoperability, the minimum set for interoperability. For further interoperability, the
responder may store its keys in DNS records, and thus the initiator responder may store its keys in DNS records, and thus the initiator
may have to couple destination HITs with appropriate source HIts may have to couple destination HITs with appropriate source HITs
according to matching HIH. according to matching HIH.
In the HIP packets, the HITs identify the sender and recipient of a In the HIP packets, the HITs identify the sender and recipient of a
packet. Consequently, a HIT should be unique in the whole IP 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 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 a single HIT mapping to more than one Host Identity, the Host
Identifiers (public keys) will make the final difference. If there 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 is more than one public key for a given node, the HIT acts as a hint
for the correct public key to use. for the correct public key to use.
skipping to change at page 13, line 8 skipping to change at page 12, line 17
4.5. Storing Host Identifiers in directories 4.5. Storing Host Identifiers in directories
The public Host Identifiers should be stored in DNS; the unpublished The public Host Identifiers should be stored in DNS; the unpublished
Host Identifiers should not be stored anywhere (besides the Host Identifiers should not be stored anywhere (besides the
communicating hosts themselves). The (public) HI along with the communicating hosts themselves). The (public) HI along with the
supported HIHs are stored in a new RR type. This RR type is defined supported HIHs are stored in a new RR type. This RR type is defined
in HIP DNS Extension [I-D.ietf-hip-rfc5205-bis]. in HIP DNS Extension [I-D.ietf-hip-rfc5205-bis].
Alternatively, or in addition to storing Host Identifiers in the DNS, Alternatively, or in addition to storing Host Identifiers in the DNS,
they may be stored in various other directories. For instance, they may be stored in various other directories. For instance, a
Light-weight Directory Access Protocol (LDAP) or in a Public Key directory based on the Lightweight Directory Access Protocol (LDAP)
Infrastructure (PKI) [I-D.ietf-hip-rfc6253-bis]. Alternatively, or a Public Key Infrastructure (PKI) [I-D.ietf-hip-rfc6253-bis] may
Distributed Hash Tables (DHTs) [RFC6537] have successfully been be used. Alternatively, Distributed Hash Tables (DHTs) [RFC6537]
utilized [RFC6538]. Such a practice may allow them to be used for have successfully been utilized [RFC6538]. Such a practice may allow
purposes other than pure host identification. them to be used for purposes other than pure host identification.
Some types of application may cache and use Host Identifiers Some types of applications may cache and use Host Identifiers
directly, while others may indirectly discover them through symbolic directly, while others may indirectly discover them through symbolic
host name (such as FQDN) look up from a directory. Even though Host host name (such as FQDN) look up from a directory. Even though Host
Identities can have a substantially longer lifetime associate with Identities can have a substantially longer lifetime associated with
them than routable IP addresses, directories may be a better approach them than routable IP addresses, directories may be a better approach
to manage the lifespan of Host Identities. For example, a LDAP or to manage the lifespan of Host Identities. For example, an LDAP-
DHT can be used for locally published identities whereas DNS can be based directory or DHT can be used for locally published identities
more suitable for public advertisement. whereas DNS can be more suitable for public advertisement.
5. New stack architecture 5. New stack architecture
One way to characterize Host Identity is to compare the proposed new One way to characterize Host Identity is to compare the proposed new
architecture with the current one. As discussed above, the IP architecture with the current one. Using the terminology from the
addresses can be seen to be a confounding of routing direction IRTF Name Space Research Group Report [nsrg-report] and, e.g., the
vectors and interface names. Using the terminology from the IRTF
Name Space Research Group Report [nsrg-report] and, e.g., the
unpublished Internet-Draft Endpoints and Endpoint Names unpublished Internet-Draft Endpoints and Endpoint Names
[chiappa-endpoints], the IP addresses currently embody the dual role [chiappa-endpoints], the IP addresses currently embody the dual role
of locators and end-point identifiers. That is, each IP address of locators and end-point identifiers. That is, each IP address
names a topological location in the Internet, thereby acting as a names a topological location in the Internet, thereby acting as a
routing direction vector, or locator. At the same time, the IP routing direction vector, or locator. At the same time, the IP
address names the physical network interface currently located at the address names the physical network interface currently located at the
point-of-attachment, thereby acting as a end-point name. point-of-attachment, thereby acting as a end-point name.
In the HIP architecture, the end-point names and locators are In the HIP architecture, the end-point names and locators are
separated from each other. IP addresses continue to act as locators. separated from each other. IP addresses continue to act as locators.
skipping to change at page 18, line 40 skipping to change at page 17, line 42
changing IP addresses in the packet header. This may occur, for changing IP addresses in the packet header. This may occur, for
example, when a packet is passed between the public Internet and a example, when a packet is passed between the public Internet and a
private address space, or between IPv4 and IPv6 networks. The private address space, or between IPv4 and IPv6 networks. The
address translation is usually implemented as Network Address address translation is usually implemented as Network Address
Translation (NAT) [RFC3022] or NAT Protocol translation (NAT-PT) Translation (NAT) [RFC3022] or NAT Protocol translation (NAT-PT)
[RFC2766]. [RFC2766].
In a network environment where identification is based on the IP In a network environment where identification is based on the IP
addresses, identifying the communicating nodes is difficult when NATs addresses, identifying the communicating nodes is difficult when NATs
are employed because private address spaces are overlapping. In are employed because private address spaces are overlapping. In
other words, two hosts cannot distinguished from each other solely other words, two hosts cannot be distinguished from each other solely
based on their IP address. With HIP, the transport-layer end-points based on their IP address. With HIP, the transport-layer end-points
(i.e. applications) are bound to unique Host Identities rather than (i.e. applications) are bound to unique Host Identities rather than
overlapping private addresses. This allows two end-points to overlapping private addresses. This allows two end-points to
distinguish one other even when they are located in different private distinguish one other even when they are located in different private
address realms. Thus, the IP addresses are used only for routing address realms. Thus, the IP addresses are used only for routing
purposes and can be changed freely by NATs when a packet between two purposes and can be changed freely by NATs when a packet between two
HIP capable hosts traverses through multiple private address realms. HIP capable hosts traverses through multiple private address realms.
NAT traversal extensions for HIP [I-D.ietf-hip-native-nat-traversal] NAT traversal extensions for HIP [I-D.ietf-hip-native-nat-traversal]
can be used to realize the actual end-to-end connectivity through NAT can be used to realize the actual end-to-end connectivity through NAT
skipping to change at page 19, line 38 skipping to change at page 18, line 42
incoming packet are not necessarily the same as they were on the incoming packet are not necessarily the same as they were on the
sending host. Furthermore, it is not possible to recompute the sending host. Furthermore, it is not possible to recompute the
upper-layer checksums in the NAT/NAT-PT system, since the traffic is upper-layer checksums in the NAT/NAT-PT system, since the traffic is
ESP protected. Consequently, the TCP and UDP checksums are ESP protected. Consequently, the TCP and UDP checksums are
calculated using the HITs in the place of the IP addresses in the calculated using the HITs in the place of the IP addresses in the
pseudo header. Furthermore, only the IPv6 pseudo header format is pseudo header. Furthermore, only the IPv6 pseudo header format is
used. This provides for IPv4 / IPv6 protocol translation. used. This provides for IPv4 / IPv6 protocol translation.
9. Multicast 9. Multicast
A number of studies intestigating HIP-based multicast have been A number of studies investigating HIP-based multicast have been
published (including [shields-hip], [xueyong-hip], [xueyong-hip], published (including [shields-hip], [xueyong-hip], [xueyong-hip],
[amir-hip], [kovacshazi-host] and [xueyong-secure]). Particularly, [amir-hip], [kovacshazi-host] and [xueyong-secure]). In particular,
so called bloom filters, that allow compressing of multiple labels so-called Bloom filters, that allow compressing of multiple labels
into small datastructures, may be a promising way forward into small data structures, may be a promising way forward
[sarela-bloom]. However, the different schemes have not been adopted [sarela-bloom]. However, the different schemes have not been adopted
by HIP working group (nor the HIP research group in IRTF), so the by the HIP working group (nor the HIP research group in IRTF), so the
details are not further elaborated here. details are not further elaborated here.
10. HIP policies 10. HIP policies
There are a number of variables that influence the HIP exchange that There are a number of variables that influence the HIP exchange that
each host must support. All HIP implementations should support at each host must support. All HIP implementations should support at
least 2 HIs, one to publish in DNS or similar directory service and least 2 HIs, one to publish in DNS or similar directory service and
an unpublished one for anonymous usage. Although unpublished HIs an unpublished one for anonymous usage. Although unpublished HIs
will be rarely used as responder HIs, they are likely to be common will be rarely used as responder HIs, they are likely to be common
for initiators. Support for multiple HIs is recommended. This for initiators. Support for multiple HIs is recommended. This
provides new challenges for systems or users to decide which type of provides new challenges for systems or users to decide which type of
HI to expose when they start a new session. HI to expose when they start a new session.
Opportunistic mode (where the initiator starts a HIP exchange without Opportunistic mode (where the initiator starts a HIP exchange without
skipping to change at page 20, line 21 skipping to change at page 19, line 22
Opportunistic mode (where the initiator starts a HIP exchange without Opportunistic mode (where the initiator starts a HIP exchange without
prior knowledge of the responder's HI) presents a security tradeoff. prior knowledge of the responder's HI) presents a security tradeoff.
At the expense of being subject to MITM attacks, the opportunistic At the expense of being subject to MITM attacks, the opportunistic
mode allows the initiator to learn the identity of the responder mode allows the initiator to learn the identity of the responder
during communication rather than from an external directory. during communication rather than from an external directory.
Opportunistic mode can be used for registration to HIP-based services Opportunistic mode can be used for registration to HIP-based services
[I-D.ietf-hip-rfc5203-bis] (i.e. utilized by HIP for its own internal [I-D.ietf-hip-rfc5203-bis] (i.e. utilized by HIP for its own internal
purposes) or by the application layer [komu-leap]. For security purposes) or by the application layer [komu-leap]. For security
reasons, especially the latter requires some involvement from the reasons, especially the latter requires some involvement from the
user to accept the identity of the responder in a similar vain as SSH user to accept the identity of the responder similar to how SSH
prompts the user when connecting to a server for the first time prompts the user when connecting to a server for the first time
[pham-leap]. In practice, this can be realized in end-host based [pham-leap]. In practice, this can be realized in end-host based
firewalls in the case of legacy applications [karvonen-usable] or firewalls in the case of legacy applications [karvonen-usable] or
with native APIs for HIP APIs [RFC6317] in the case of HIP-aware with native APIs for HIP APIs [RFC6317] in the case of HIP-aware
applications. applications.
Many initiators would want to use a different HI for different Many initiators would want to use a different HI for different
responders. The implementations should provide for a policy of responders. The implementations should provide for a policy mapping
initiator HIT to responder HIT. This policy should also include of initiator HITs to responder HITs. This policy should also include
preferred transforms and local lifetimes. preferred transforms and local lifetimes.
Responders would need a similar policy, describing the hosts allowed Responders would need a similar policy, describing the hosts allowed
to participate in HIP exchanges, and the preferred transforms and to participate in HIP exchanges, and the preferred transforms and
local lifetimes. local lifetimes.
11. Design considerations 11. Design considerations
11.1. Benefits of HIP 11.1. Benefits of HIP
skipping to change at page 21, line 48 skipping to change at page 20, line 48
The Host Identity (HI) namespace fills an important gap between the The Host Identity (HI) namespace fills an important gap between the
IP and DNS namespaces. An interesting thing about the HI is that it 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 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 invariant. That is to say, as long as the source and destination
addresses in the network-layer protocol are reversible, HIP takes addresses in the network-layer protocol are reversible, HIP takes
care of host identification, and reversibility allows a local host to care of host identification, and reversibility allows a local host to
receive a packet back from a remote host. The address changes receive a packet back from a remote host. The address changes
occurring during NAT transit (non-mutable) or host movement (non- occurring during NAT transit (non-mutable) or host movement (non-
omniscient or non-mobile) can be managed by the HIP layer. omniscient or non-mobile) can be managed by the HIP layer.
With the exception High-Performance Computing applications, the With the exception of High-Performance Computing applications, the
Sockets API is the most common way to develop network applications. Sockets API is the most common way to develop network applications.
Applications use the Sockets API either directly or indirectly Applications use the Sockets API either directly or indirectly
through some libraries or frameworks. However, the Sockets API is through some libraries or frameworks. However, the Sockets API is
based on the assumption of static IP addresses, and DNS with its based on the assumption of static IP addresses, and DNS with its
lifetime values was invented at later stages during the evolution of lifetime values was invented at later stages during the evolution of
the Internet. Hence, the Sockets API does not deal with the lifetime the Internet. Hence, the Sockets API does not deal with the lifetime
of addresses [RFC6250]. As majority of the end-user equipment is of addresses [RFC6250]. As the majority of the end-user equipment is
mobile today, their addresses are effectively ephemeral, but the mobile today, their addresses are effectively ephemeral, but the
Sockets API still gives a fallacious illusion of persistent IP Sockets API still gives a fallacious illusion of persistent IP
addresses to the unwary developer. HIP can be used to solidify this addresses to the unwary developer. HIP can be used to solidify this
illusion because HIP provides persistent surrogate addresses to the illusion because HIP provides persistent surrogate addresses to the
application layer in the form of LSIs and HITs. application layer in the form of LSIs and HITs.
The persistent identifiers as provided by HIP are useful in multiple The persistent identifiers as provided by HIP are useful in multiple
scenarios (see, e.g., [ylitalo-diss] or [komu-diss], for a more scenarios (see, e.g., [ylitalo-diss] or [komu-diss], for a more
elaborate discussion): elaborate discussion):
skipping to change at page 22, line 44 skipping to change at page 21, line 44
o Site renumbering events for services can occur due to corporate o Site renumbering events for services can occur due to corporate
mergers or acquisitions, or by changes in Internet Service mergers or acquisitions, or by changes in Internet Service
Provider. They can involve changing the entire network prefix of Provider. They can involve changing the entire network prefix of
an organization, which is problematic due to hard-coded addresses an organization, which is problematic due to hard-coded addresses
in service configuration files or cached IP addresses at the in service configuration files or cached IP addresses at the
client side [RFC5887]. Considering such human errors, a site client side [RFC5887]. Considering such human errors, a site
employing location-independent identifiers as promoted by HIP may employing location-independent identifiers as promoted by HIP may
experience less problems while renumbering their network. experience less problems while renumbering their network.
o More agile IPv6 interoperability as discussed in Section 4.4. o More agile IPv6 interoperability can be achieved, as discussed in
IPv6-based applications can communicate using HITs with IPv4-based Section 4.4. IPv6-based applications can communicate using HITs
applications that are using LSIs. An addition, the underlying with IPv4-based applications that are using LSIs. Additionally,
network type (IPv4 or IPv6) becomes independent of the addressing the underlying network type (IPv4 or IPv6) becomes independent of
family of the application. the addressing family of the application.
o HITs (or LSIs) can be used in IP-based access control lists as a o HITs (or LSIs) can be used in IP-based access control lists as a
more secure replacement for IPv6 addresses. Besides security, HIT more secure replacement for IPv6 addresses. Besides security, HIT
based access control has two other benefits. First, the use of based access control has two other benefits. First, the use of
HITs halves the size of access control lists because separate HITs can potentially halve the size of access control lists
rules for IPv4 are not needed [komu-diss]. Second, HIT-based because separate rules for IPv4 are not needed [komu-diss].
configuration rules in HIP-aware middleboxes remain static and Second, HIT-based configuration rules in HIP-aware middleboxes
independent of topology changes, thus simplifying administrative remain static and independent of topology changes, thus
efforts particularly for mobile environments. For instance, the simplifying administrative efforts particularly for mobile
benefits of HIT based access control have been harnessed in the environments. For instance, the benefits of HIT based access
case of HIP-aware firewalls, but can be utilized directly at the control have been harnessed in the case of HIP-aware firewalls,
end-hosts as well [RFC6538]. but can be utilized directly at the end-hosts as well [RFC6538].
While some of these benefits could be and have been redundantly While some of these benefits could be and have been redundantly
implemented by individual applications, providing such generic implemented by individual applications, providing such generic
functionality at the lower layers is useful because it reduces functionality at the lower layers is useful because it reduces
software development effort and networking software bugs (as the software development effort and networking software bugs (as the
layer is tested with multiple applications). It also allows the layer is tested with multiple applications). It also allows the
developer to focus on building the application itself rather than developer to focus on building the application itself rather than
delving into the intricacies of mobile networking, thus facilitating delving into the intricacies of mobile networking, thus facilitating
separation of concerns. separation of concerns.
skipping to change at page 24, line 22 skipping to change at page 23, line 22
The key exchange introduces some extra latency (two round trips) in The key exchange introduces some extra latency (two round trips) in
the initial transport layer connection establishment between two the initial transport layer connection establishment between two
hosts. With TCP, additional delay occurs if the underlying network hosts. With TCP, additional delay occurs if the underlying network
stack implementation drops the triggering SYN packet during the key stack implementation drops the triggering SYN packet during the key
exchange. The same cost may also occur during HIP handoff exchange. The same cost may also occur during HIP handoff
procedures. However, subsequent TCP sessions using the same HIP procedures. However, subsequent TCP sessions using the same HIP
association will not bear this cost (within the key lifetime). Both association will not bear this cost (within the key lifetime). Both
the key exchange and handoff penalties can be minimized by caching the key exchange and handoff penalties can be minimized by caching
TCP packets. The latter case can further be optimized with TCP user TCP packets. The latter case can further be optimized with TCP user
timeout extensions [RFC5482] as described in further detail by timeout extensions [RFC5482] as described in further detail by
Schuetz et al [scultz-intermittent]. Schuetz et al [schuetz-intermittent].
The most CPU-intensive operations involve the use of the asymmetric The most CPU-intensive operations involve the use of the asymmetric
keys and Diffie-Hellman key derivation at the control plane, but this keys and Diffie-Hellman key derivation at the control plane, but this
occurs only during the key exchange, its maintenance (handoffs, occurs only during the key exchange, its maintenance (handoffs,
refreshing of key material) and tear down procedures of HIP refreshing of key material) and tear down procedures of HIP
associations. The data plane is typically implemented with ESP associations. The data plane is typically implemented with ESP
because it has a smaller overhead due to symmetric key encryption. because it has a smaller overhead due to symmetric key encryption.
Naturally, even ESP involves some overhead in terms of latency Naturally, even ESP involves some overhead in terms of latency
(processing costs) and throughput (tunneling) (see e.g. (processing costs) and throughput (tunneling) (see e.g.
[ylitalo-diss] for a performance evaluation). [ylitalo-diss] for a performance evaluation).
skipping to change at page 25, line 17 skipping to change at page 24, line 17
HIP must be implemented in the OS kernel. Both of these claims are HIP must be implemented in the OS kernel. Both of these claims are
untrue; HIP does have NAT traversal extensions untrue; HIP does have NAT traversal extensions
[I-D.ietf-hip-native-nat-traversal], and kernel modifications can be [I-D.ietf-hip-native-nat-traversal], and kernel modifications can be
avoided with modern operating systems by diverting packets for avoided with modern operating systems by diverting packets for
userspace processing. userspace processing.
The analysis by Levae et al clarifies infrastructural requirements The analysis by Levae et al clarifies infrastructural requirements
for HIP. In a minimal set up, a client and server machine have to for HIP. In a minimal set up, a client and server machine have to
run HIP software. However, to avoid manual configurations, usually run HIP software. However, to avoid manual configurations, usually
DNS records for HIP are set up. For instance, the popular DNS server DNS records for HIP are set up. For instance, the popular DNS server
software Bind9 does not require any changes to accomodate DNS records software Bind9 does not require any changes to accommodate DNS
for HIP because they can be supported in binary format in its records for HIP because they can be supported in binary format in its
configuration files [RFC6538]. HIP rendezvous servers and firewalls configuration files [RFC6538]. HIP rendezvous servers and firewalls
are optional. No changes are required to network address points, are optional. No changes are required to network address points,
NATs, edge routers or core networks. HIP may require holes in legacy NATs, edge routers or core networks. HIP may require holes in legacy
firewalls. firewalls.
The analysis also clarifies the requirements for the host components The analysis also clarifies the requirements for the host components
that consist of three parts. First, a HIP control plane component is that consist of three parts. First, a HIP control plane component is
required, typically implemented as a userspace daemon. Second, a required, typically implemented as a userspace daemon. Second, a
data plane component is needed. Most HIP implementations utilize the data plane component is needed. Most HIP implementations utilize the
so called BEET mode of ESP that has been available since Linux kernel so called BEET mode of ESP that has been available since Linux kernel
2.6.27, but is included also as a userspace component in a few of the 2.6.27, but is included also as a userspace component in a few of the
implementations. Third, HIP systems usually provide a DNS proxy for implementations. Third, HIP systems usually provide a DNS proxy for
the local host that translates HIP DNS records to LSIs and HITs, and the local host that translates HIP DNS records to LSIs and HITs, and
communicates the corresponding locators to HIP userspace daemon. communicates the corresponding locators to HIP userspace daemon.
While the third component is not strictly speaking mandatory, it is While the third component is not mandatory, it is very useful for
very useful for avoiding manual configurations. The three components avoiding manual configurations. The three components are further
are further described in the HIP experiment report [RFC6538]. described in the HIP experiment report [RFC6538].
Based on the interviews, Levae et al suggest further directions to Based on the interviews, Levae et al suggest further directions to
facilitate HIP deployment. Transitioning the HIP specifications to facilitate HIP deployment. Transitioning the HIP specifications to
the standards track may help, but other measures could be taken. As the standards track may help, but other measures could be taken. As
a more radical measure, the authors suggest to implement HIP as a a more radical measure, the authors suggest to implement HIP as a
purely application-layer library [xin-hip-lib] or other kind of purely application-layer library [xin-hip-lib] or other kind of
middleware. On the other hand, more conservative measures include middleware. On the other hand, more conservative measures include
focusing on private deployments controlled by a single stakeholder. focusing on private deployments controlled by a single stakeholder.
As a more concrete example of such a scenario, HIP could be used by a As a more concrete example of such a scenario, HIP could be used by a
single service provider to facilitate secure connectivity between its single service provider to facilitate secure connectivity between its
skipping to change at page 29, line 51 skipping to change at page 28, line 51
distributed flooding attack an attacker opens high volume HIP distributed flooding attack an attacker opens high volume HIP
connections with a large number of hosts (using unpublished HIs), and 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 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, 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 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 prevent this type of attack, HIP mobility extensions include a return
routability check procedure where the reachability of a node is routability check procedure where the reachability of a node is
separately checked at each address before using the address for separately checked at each address before using the address for
larger amounts of traffic. larger amounts of traffic.
A credit-based authorization approach Host Mobility with the Host A credit-based authorization approach for host mobility with the Host
Identity Protocol [I-D.ietf-hip-rfc5206-bis] can be used between Identity Protocol [I-D.ietf-hip-rfc5206-bis] can be used between
hosts for sending data prior to completing the address tests. hosts for sending data prior to completing the address tests.
Otherwise, if HIP is used between two hosts that fully trust each Otherwise, if HIP is used between two hosts that fully trust each
other, the hosts may optionally decide to skip the address tests. other, the hosts may optionally decide to skip the address tests.
However, such performance optimization must be restricted to peers However, such performance optimization must be restricted to peers
that are known to be trustworthy and capable of protecting themselves that are known to be trustworthy and capable of protecting themselves
from malicious software. from malicious software.
12.3. HITs used in ACLs 12.3. HITs used in ACLs
skipping to change at page 30, line 31 skipping to change at page 29, line 31
practice, firewalls can inspect HIP packets to learn of the bindings practice, firewalls can inspect HIP packets to learn of the bindings
between HITs, SPI values, and IP addresses. They can even explicitly between HITs, SPI values, and IP addresses. They can even explicitly
control ESP usage, dynamically opening ESP only for specific SPI control ESP usage, dynamically opening ESP only for specific SPI
values and IP addresses. The signatures in HIP packets allow a values and IP addresses. The signatures in HIP packets allow a
capable firewall to ensure that the HIP exchange is indeed occurring capable firewall to ensure that the HIP exchange is indeed occurring
between two known hosts. This may increase firewall security. between two known hosts. This may increase firewall security.
A potential drawback of HITs in ACLs is their 'flatness' means they A potential drawback of HITs in ACLs is their 'flatness' means they
cannot be aggregated, and this could potentially result in larger cannot be aggregated, and this could potentially result in larger
table searches in HIP-aware firewalls. A way to optimize this could table searches in HIP-aware firewalls. A way to optimize this could
be to utilize bloom filters for grouping of HITs [sarela-bloom]. be to utilize Bloom filters for grouping of HITs [sarela-bloom].
However, it should be noted that it is also easier to exclude However, it should be noted that it is also easier to exclude
individual, misbehaving hosts out when the firewall rules concern individual, misbehaving hosts out when the firewall rules concern
individual HITs rather than groups. individual HITs rather than groups.
There has been considerable bad experience with distributed ACLs that There has been considerable bad experience with distributed ACLs that
contain public key related material, for example, with SSH. If the contain public key related material, for example, with SSH. If the
owner of a key needs to revoke it for any reason, the task of finding 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 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 the reason for the revocation is due to private key theft, this could
be a serious issue. be a serious issue.
A host can keep track of all of its partners that might use its HIT 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 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 log responder hosts. With this information, the host can notify the
various hosts about the change to the HIT. There has been attempts various hosts about the change to the HIT. There have been attempts
to develop a secure method to issue the HIT revocation notice to develop a secure method to issue the HIT revocation notice
[zhang-revocation]. [zhang-revocation].
Some of the HIP-aware middleboxes, such as firewalls Some of the HIP-aware middleboxes, such as firewalls
[lindqvist-enterprise] or NATs [ylitalo-spinat], may observe the on- [lindqvist-enterprise] or NATs [ylitalo-spinat], may observe the on-
path traffic passively. Such middleboxes are transparent by their path traffic passively. Such middleboxes are transparent by their
nature and may not get a notification when a host moves to a nature and may not get a notification when a host moves to a
different network. Thus, such middleboxes should maintain soft state different network. Thus, such middleboxes should maintain soft state
and timeout when the control and data plane between two HIP end-hosts and timeout when the control and data plane between two HIP end-hosts
has been idle too long. Correspondingly, the two end-hosts may send has been idle too long. Correspondingly, the two end-hosts may send
periodically keepalives, such as UPDATE packets or ICMP messages periodically keepalives, such as UPDATE packets or ICMP messages
inside the ESP tunnel, to sustain state at the on-path middleboxes. inside the ESP tunnel, to sustain state at the on-path middleboxes.
One general limitation related to end-to-end encryption is that One general limitation related to end-to-end encryption is that
middleboxes may not be able to participate to the protection of middleboxes may not be able to participate to the protection of data
malign data flows. While the issue may affect also other protocols, flows. While the issue may affect also other protocols, Heer at al
Heer at al [heer-end-host] have analyzed the problem in the context [heer-end-host] have analyzed the problem in the context of HIP.
of HIP. More specifically, when ESP is used as the data-plane More specifically, when ESP is used as the data-plane protocol for
protocol for HIP, the association between the control and data plane HIP, the association between the control and data plane is weak and
is weak and can be exploited under certain assumptions. In the can be exploited under certain assumptions. In the scenario, the
scenario, the attacker has already gained access to the target attacker has already gained access to the target network protected by
network protected by a HIP-aware firewall, but wants to circumvent a HIP-aware firewall, but wants to circumvent the HIP-based firewall.
the HIP-based firewall. To achieve this, the attacker passively To achieve this, the attacker passively observes a base exchange
observes a base exchange between two HIP hosts and later replays it. between two HIP hosts and later replays it. This way, the attacker
This way, the attacker manages to penetrate the firewall and can use manages to penetrate the firewall and can use a fake ESP tunnel to
a fake ESP tunnel to transport its own data. This is possible transport its own data. This is possible because the firewall cannot
because the firewall cannot distinguish when the ESP tunnel is valid. distinguish when the ESP tunnel is valid. As a solution, HIP-aware
As a solution, HIP-aware middleboxes may participate to the control middleboxes may participate to the control plane interaction by
plane interaction by adding random nonce parameters to the control adding random nonce parameters to the control traffic, which the end-
traffic, which the the end-hosts have to sign to guarantee the hosts have to sign to guarantee the freshness of the control traffic
freshness of the control traffic [heer-midauth]. As an alternative, [heer-midauth]. As an alternative, extensions for transporting data
extensions for transporting data plane directly over the control plane directly over the control plane can be used [RFC6078].
plane can be used [RFC6078].
12.4. Alternative HI considerations 12.4. Alternative HI considerations
The definition of the Host Identifier states that the HI need not be 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 a public key. It implies that the HI could be any value; for example
a FQDN. This document does not describe how to support such a non- a FQDN. This document does not describe how to support such a non-
cryptographic HI, but examples of such protocol variants do exist cryptographic HI, but examples of such protocol variants do exist
([urien-rfid], [urien-rfid-draft]). A non-cryptographic HI would ([urien-rfid], [urien-rfid-draft]). A non-cryptographic HI would
still offer the services of the HIT or LSI for NAT traversal. It 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 would be possible to carry HITs in HIP packets that had neither
skipping to change at page 32, line 43 skipping to change at page 31, line 42
Technology (HIIT), NomadicLab of Ericsson, and the three Technology (HIIT), NomadicLab of Ericsson, and the three
universities: RWTH Aachen, Aalto and University of Helsinki, for universities: RWTH Aachen, Aalto and University of Helsinki, for
their efforts. Without their collective efforts HIP would have their efforts. Without their collective efforts HIP would have
withered as on the IETF vine as a nice concept. withered as on the IETF vine as a nice concept.
Thanks also for Suvi Koskinen for her help with proofreading and with Thanks also for Suvi Koskinen for her help with proofreading and with
the reference jungle. the reference jungle.
15. Changes from RFC 4423 15. Changes from RFC 4423
In a nutshell, the changes from RFC 4424 [RFC4423] are mostly In a nutshell, the changes from RFC 4423 [RFC4423] are mostly
editorial, including clarifications on topics described in a editorial, including clarifications on topics described in a
difficult way and omitting some of the non-architectural difficult way and omitting some of the non-architectural
(implementation) details that are already described in other (implementation) details that are already described in other
documents. A number of missing references to the literature were documents. A number of missing references to the literature were
also added. New topics include the drawbacks of HIP, discussion on also added. New topics include the drawbacks of HIP, discussion on
802.15.4 and MAC security, deployment considerations and description 802.15.4 and MAC security, deployment considerations and description
of the base exchange. of the base exchange.
16. References 16. References
16.1. Normative References 16.1. Normative References
[I-D.ietf-hip-multihoming] [I-D.ietf-hip-multihoming]
Henderson, T., Vogt, C., and J. Arkko, "Host Multihoming Henderson, T., Vogt, C., and J. Arkko, "Host Multihoming
with the Host Identity Protocol", with the Host Identity Protocol", draft-ietf-hip-
draft-ietf-hip-multihoming-03 (work in progress), multihoming-03 (work in progress), July 2013.
July 2013.
[I-D.ietf-hip-native-nat-traversal] [I-D.ietf-hip-native-nat-traversal]
Keranen, A. and J. Melen, "Native NAT Traversal Mode for Keranen, A. and J. Melen, "Native NAT Traversal Mode for
the Host Identity Protocol", the Host Identity Protocol", draft-ietf-hip-native-nat-
draft-ietf-hip-native-nat-traversal-05 (work in progress), traversal-06 (work in progress), December 2013.
June 2013.
[I-D.ietf-hip-rfc5201-bis] [I-D.ietf-hip-rfc5201-bis]
Moskowitz, R., Heer, T., Jokela, P., and T. Henderson, Moskowitz, R., Heer, T., Jokela, P., and T. Henderson,
"Host Identity Protocol Version 2 (HIPv2)", "Host Identity Protocol Version 2 (HIPv2)", draft-ietf-
draft-ietf-hip-rfc5201-bis-14 (work in progress), hip-rfc5201-bis-14 (work in progress), October 2013.
October 2013.
[I-D.ietf-hip-rfc5202-bis] [I-D.ietf-hip-rfc5202-bis]
Jokela, P., Moskowitz, R., and J. Melen, "Using the Jokela, P., Moskowitz, R., and J. Melen, "Using the
Encapsulating Security Payload (ESP) Transport Format with Encapsulating Security Payload (ESP) Transport Format with
the Host Identity Protocol (HIP)", the Host Identity Protocol (HIP)", draft-ietf-hip-
draft-ietf-hip-rfc5202-bis-05 (work in progress), rfc5202-bis-05 (work in progress), November 2013.
November 2013.
[I-D.ietf-hip-rfc5203-bis] [I-D.ietf-hip-rfc5203-bis]
Laganier, J. and L. Eggert, "Host Identity Protocol (HIP) Laganier, J. and L. Eggert, "Host Identity Protocol (HIP)
Registration Extension", draft-ietf-hip-rfc5203-bis-02 Registration Extension", draft-ietf-hip-rfc5203-bis-05
(work in progress), September 2012. (work in progress), March 2014.
[I-D.ietf-hip-rfc5204-bis] [I-D.ietf-hip-rfc5204-bis]
Laganier, J. and L. Eggert, "Host Identity Protocol (HIP) Laganier, J. and L. Eggert, "Host Identity Protocol (HIP)
Rendezvous Extension", draft-ietf-hip-rfc5204-bis-02 (work Rendezvous Extension", draft-ietf-hip-rfc5204-bis-03 (work
in progress), September 2012. in progress), December 2013.
[I-D.ietf-hip-rfc5205-bis] [I-D.ietf-hip-rfc5205-bis]
Laganier, J., "Host Identity Protocol (HIP) Domain Name Laganier, J., "Host Identity Protocol (HIP) Domain Name
System (DNS) Extension", draft-ietf-hip-rfc5205-bis-02 System (DNS) Extension", draft-ietf-hip-rfc5205-bis-04
(work in progress), September 2012. (work in progress), January 2014.
[I-D.ietf-hip-rfc5206-bis] [I-D.ietf-hip-rfc5206-bis]
Henderson, T., Vogt, C., and J. Arkko, "Host Mobility with Henderson, T., Vogt, C., and J. Arkko, "Host Mobility with
the Host Identity Protocol", draft-ietf-hip-rfc5206-bis-06 the Host Identity Protocol", draft-ietf-hip-rfc5206-bis-06
(work in progress), July 2013. (work in progress), July 2013.
[I-D.ietf-hip-rfc6253-bis] [I-D.ietf-hip-rfc6253-bis]
Heer, T. and S. Varjonen, "Host Identity Protocol Heer, T. and S. Varjonen, "Host Identity Protocol
Certificates", draft-ietf-hip-rfc6253-bis-01 (work in Certificates", draft-ietf-hip-rfc6253-bis-01 (work in
progress), October 2013. progress), October 2013.
[RFC5482] Eggert, L. and F. Gont, "TCP User Timeout Option", [RFC5482] Eggert, L. and F. Gont, "TCP User Timeout Option", RFC
RFC 5482, March 2009. 5482, March 2009.
16.2. Informative references 16.2. Informative references
[IEEE.802-15-4.2011] [IEEE.802-15-4.2011]
"Information technology - Telecommunications and , "Information technology - Telecommunications and
information exchange between systems - Local and information exchange between systems - Local and
metropolitan area networks - Specific requirements - Part metropolitan area networks - Specific requirements - Part
15.4: Wireless Medium Access Control (MAC) and Physical 15.4: Wireless Medium Access Control (MAC) and Physical
Layer (PHY) Specifications for Low-Rate Wireless Personal Layer (PHY) Specifications for Low-Rate Wireless Personal
Area Networks (WPANs)", IEEE Standard 802.15.4, Area Networks (WPANs)", IEEE Standard 802.15.4, September
September 2011, <http://standards.ieee.org/getieee802/ 2011, <http://standards.ieee.org/getieee802/download/
download/802.15.4-2011.pdf>. 802.15.4-2011.pdf>.
[Nik2001] Nikander, P., "Denial-of-Service, Address Ownership, and [Nik2001] Nikander, P., "Denial-of-Service, Address Ownership, and
Early Authentication in the IPv6 World", in Proceesings Early Authentication in the IPv6 World", in Proceesings of
of Security Protocols, 9th International Workshop, Security Protocols, 9th International Workshop, Cambridge,
Cambridge, UK, April 25-27 2001, LNCS 2467, pp. 12-26, UK, April 25-27 2001, LNCS 2467, pp. 12-26, Springer,
Springer, 2002. 2002.
[RFC2136] Vixie, P., Thomson, S., Rekhter, Y., and J. Bound, [RFC2136] Vixie, P., Thomson, S., Rekhter, Y., and J. Bound,
"Dynamic Updates in the Domain Name System (DNS UPDATE)", "Dynamic Updates in the Domain Name System (DNS UPDATE)",
RFC 2136, April 1997. RFC 2136, April 1997.
[RFC2535] Eastlake, D., "Domain Name System Security Extensions", [RFC2535] Eastlake, D., "Domain Name System Security Extensions",
RFC 2535, March 1999. RFC 2535, March 1999.
[RFC2766] Tsirtsis, G. and P. Srisuresh, "Network Address [RFC2766] Tsirtsis, G. and P. Srisuresh, "Network Address
Translation - Protocol Translation (NAT-PT)", RFC 2766, Translation - Protocol Translation (NAT-PT)", RFC 2766,
February 2000. February 2000.
[RFC3022] Srisuresh, P. and K. Egevang, "Traditional IP Network [RFC3022] Srisuresh, P. and K. Egevang, "Traditional IP Network
Address Translator (Traditional NAT)", RFC 3022, Address Translator (Traditional NAT)", RFC 3022, January
January 2001. 2001.
[RFC3102] Borella, M., Lo, J., Grabelsky, D., and G. Montenegro, [RFC3102] Borella, M., Lo, J., Grabelsky, D., and G. Montenegro,
"Realm Specific IP: Framework", RFC 3102, October 2001. "Realm Specific IP: Framework", RFC 3102, October 2001.
[RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H.
Levkowetz, "Extensible Authentication Protocol (EAP)", Levkowetz, "Extensible Authentication Protocol (EAP)", RFC
RFC 3748, June 2004. 3748, June 2004.
[RFC4225] Nikander, P., Arkko, J., Aura, T., Montenegro, G., and E. [RFC4225] Nikander, P., Arkko, J., Aura, T., Montenegro, G., and E.
Nordmark, "Mobile IP Version 6 Route Optimization Security Nordmark, "Mobile IP Version 6 Route Optimization Security
Design Background", RFC 4225, December 2005. Design Background", RFC 4225, December 2005.
[RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", [RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", RFC
RFC 4306, December 2005. 4306, December 2005.
[RFC4423] Moskowitz, R. and P. Nikander, "Host Identity Protocol [RFC4423] Moskowitz, R. and P. Nikander, "Host Identity Protocol
(HIP) Architecture", RFC 4423, May 2006. (HIP) Architecture", RFC 4423, May 2006.
[RFC5218] Thaler, D. and B. Aboba, "What Makes For a Successful [RFC5218] Thaler, D. and B. Aboba, "What Makes For a Successful
Protocol?", RFC 5218, July 2008. Protocol?", RFC 5218, July 2008.
[RFC5338] Henderson, T., Nikander, P., and M. Komu, "Using the Host [RFC5338] Henderson, T., Nikander, P., and M. Komu, "Using the Host
Identity Protocol with Legacy Applications", RFC 5338, Identity Protocol with Legacy Applications", RFC 5338,
September 2008. September 2008.
[RFC5887] Carpenter, B., Atkinson, R., and H. Flinck, "Renumbering [RFC5887] Carpenter, B., Atkinson, R., and H. Flinck, "Renumbering
Still Needs Work", RFC 5887, May 2010. Still Needs Work", RFC 5887, May 2010.
[RFC6078] Camarillo, G. and J. Melen, "Host Identity Protocol (HIP) [RFC6078] Camarillo, G. and J. Melen, "Host Identity Protocol (HIP)
Immediate Carriage and Conveyance of Upper-Layer Protocol Immediate Carriage and Conveyance of Upper-Layer Protocol
Signaling (HICCUPS)", RFC 6078, January 2011. Signaling (HICCUPS)", RFC 6078, January 2011.
[RFC6250] Thaler, D., "Evolution of the IP Model", RFC 6250, [RFC6250] Thaler, D., "Evolution of the IP Model", RFC 6250, May
May 2011. 2011.
[RFC6281] Cheshire, S., Zhu, Z., Wakikawa, R., and L. Zhang, [RFC6281] Cheshire, S., Zhu, Z., Wakikawa, R., and L. Zhang,
"Understanding Apple's Back to My Mac (BTMM) Service", "Understanding Apple's Back to My Mac (BTMM) Service", RFC
RFC 6281, June 2011. 6281, June 2011.
[RFC6317] Komu, M. and T. Henderson, "Basic Socket Interface [RFC6317] Komu, M. and T. Henderson, "Basic Socket Interface
Extensions for the Host Identity Protocol (HIP)", Extensions for the Host Identity Protocol (HIP)", RFC
RFC 6317, July 2011. 6317, July 2011.
[RFC6537] Ahrenholz, J., "Host Identity Protocol Distributed Hash [RFC6537] Ahrenholz, J., "Host Identity Protocol Distributed Hash
Table Interface", RFC 6537, February 2012. Table Interface", RFC 6537, February 2012.
[RFC6538] Henderson, T. and A. Gurtov, "The Host Identity Protocol [RFC6538] Henderson, T. and A. Gurtov, "The Host Identity Protocol
(HIP) Experiment Report", RFC 6538, March 2012. (HIP) Experiment Report", RFC 6538, March 2012.
[amir-hip] [amir-hip]
Amir, K., Forsgren, H., Grahn, K., Karvi, T., and G. Amir, K., Forsgren, H., Grahn, K., Karvi, T., and G.
Pulkkis, "Security and Trust of Public Key Cryptography Pulkkis, "Security and Trust of Public Key Cryptography
skipping to change at page 36, line 16 skipping to change at page 35, line 11
2(3), 17-35, DOI: 10.4018/jdtis.2011070102, 2013. 2(3), 17-35, DOI: 10.4018/jdtis.2011070102, 2013.
[aura-dos] [aura-dos]
Aura, T., Nikander, P., and J. Leiwo, "DOS-resistant Aura, T., Nikander, P., and J. Leiwo, "DOS-resistant
Authentication with Client Puzzles", 8th International Authentication with Client Puzzles", 8th International
Workshop on Security Protocols, pages 170-177. Springer, , Workshop on Security Protocols, pages 170-177. Springer, ,
April 2001. April 2001.
[beal-dos] [beal-dos]
Beal, J. and T. Shephard, "Deamplification of DoS Attacks Beal, J. and T. Shephard, "Deamplification of DoS Attacks
via Puzzles", , October 2004. via Puzzles", , October 2004.
[chiappa-endpoints] [chiappa-endpoints]
Chiappa, J., "Endpoints and Endpoint Names: A Proposed Chiappa, J., "Endpoints and Endpoint Names: A Proposed
Enhancement to the Internet Architecture", Enhancement to the Internet Architecture", URL
URL http://www.chiappa.net/~jnc/tech/endpoints.txt, 1999. http://www.chiappa.net/~jnc/tech/endpoints.txt, 1999.
[heer-end-host] [heer-end-host]
Heer, T., Hummen, R., Komu, M., Goetz, S., and K. Wehre, Heer, T., Hummen, R., Komu, M., Goetz, S., and K. Wehre,
"End-host Authentication and Authorization for Middleboxes "End-host Authentication and Authorization for Middleboxes
based on a Cryptographic Namespace", ICC2009 Communication based on a Cryptographic Namespace", ICC2009 Communication
and Information Systems Security Symposium, , 2009. and Information Systems Security Symposium, , 2009.
[heer-midauth] [heer-midauth]
Heer, T. and M. Komu, "End-Host Authentication for HIP Heer, T. and M. Komu, "End-Host Authentication for HIP
Middleboxes", Working draft draft-heer-hip-middle-auth-02, Middleboxes", Working draft draft-heer-hip-middle-auth-02,
September 2009. September 2009.
[henderson-vpls] [henderson-vpls]
Henderson, T. and D. Mattes, "", Working Henderson, T. and D. Mattes, "HIP-based Virtual Private
draft draft-henderson-hip-vpls-06, June 2013. LAN Service (HIPLS)", Working draft draft-henderson-hip-
vpls-07, Dec 2013.
[hip-srtp] [hip-srtp]
Tschofenig, H., Muenz, F., and M. Shanmugam, "Using SRTP Tschofenig, H., Muenz, F., and M. Shanmugam, "Using SRTP
transport format with HIP", Working transport format with HIP", Working draft draft-
draft draft-tschofenig-hiprg-hip-srtp-01, October 2005. tschofenig-hiprg-hip-srtp-01, October 2005.
[karvonen-usable] [karvonen-usable]
Karvonen, K., Komu, M., and A. Gurtov, "Usable Security Karvonen, K., Komu, M., and A. Gurtov, "Usable Security
Management with Host Identity Protocol", 7th ACS/IEEE Management with Host Identity Protocol", 7th ACS/IEEE
International Conference on Computer Systems and International Conference on Computer Systems and
Applications, (AICCSA-2009), 2009. Applications, (AICCSA-2009), 2009.
[komu-cloud] [komu-cloud]
Komu, M., Sethi, M., Mallavarapu, R., Oirola, H., Khan, Komu, M., Sethi, M., Mallavarapu, R., Oirola, H., Khan,
R., and S. Tarkoma, "Secure Networking for Virtual R., and S. Tarkoma, "Secure Networking for Virtual
Machines in the Cloud", International Workshop on Power Machines in the Cloud", International Workshop on Power
and QoS Aware Computing (PQoSCom2012), IEEE, ISBN: 978-1- and QoS Aware Computing (PQoSCom2012), IEEE, ISBN:
4244-8567-3, September 2012. 978-1-4244-8567-3, September 2012.
[komu-diss] [komu-diss]
Komu, M., "A Consolidated Namespace for Network Komu, M., "A Consolidated Namespace for Network
Applications, Developers, Administrators and Users", Applications, Developers, Administrators and Users",
Dissertation, Aalto University, Espoo, Finland ISBN: 978- Dissertation, Aalto University, Espoo, Finland ISBN:
952-60-4904-5 (printed), ISBN: 978-952-60-4905-2 978-952-60-4904-5 (printed), ISBN: 978-952-60-4905-2
(electronic). , December 2012. (electronic). , December 2012.
[komu-leap] [komu-leap]
Komu, M. and J. Lindqvist, "Leap-of-Faith Security is Komu, M. and J. Lindqvist, "Leap-of-Faith Security is
Enough for IP Mobility", 6th Annual IEEE Consumer Enough for IP Mobility", 6th Annual IEEE Consumer
Communications and Networking Conference IEEE CCNC 2009, Communications and Networking Conference IEEE CCNC 2009,
Las Vegas, Nevada, , January 2009. Las Vegas, Nevada, , January 2009.
[komu-mitigation] [komu-mitigation]
Komu, M., Tarkoma, S., and A. Lukyanenko, "Mitigation of Komu, M., Tarkoma, S., and A. Lukyanenko, "Mitigation of
Unsolicited Traffic Across Domains with Host Identities Unsolicited Traffic Across Domains with Host Identities
and Puzzles", 15th Nordic Conference on Secure IT Systems and Puzzles", 15th Nordic Conference on Secure IT Systems
(NordSec 2010), Springer Lecture Notes in Computer (NordSec 2010), Springer Lecture Notes in Computer
Science, Volume 7127, pp. 33-48, ISBN: 978-3-642-27936-2, Science, Volume 7127, pp. 33-48, ISBN: 978-3-642-27936-2,
October 2010. October 2010.
[kovacshazi-host] [kovacshazi-host]
Kovacshazi, Z. and R. Vida, "Host Identity Specific Kovacshazi, Z. and R. Vida, "Host Identity Specific
Multicast", International conference on Networking and Multicast", International conference on Networking and
Services (ICNS'06), IEEE Computer Society, Los Alamitos, Services (ICNS'06), IEEE Computer Society, Los Alamitos,
CA, USA, http://doi.ieeecomputersociety.org/10.1109/ CA, USA,
ICNS.2007.66, 2007. http://doi.ieeecomputersociety.org/10.1109/ICNS.2007.66,
2007.
[leva-barriers] [leva-barriers]
Levae, A., Komu, M., and S. Luukkainen, "Adoption Barriers Levae, A., Komu, M., and S. Luukkainen, "Adoption Barriers
of Network-layer Protocols: the Case of Host Identity of Network-layer Protocols: the Case of Host Identity
Protocol", The International Journal of Computer and Protocol", The International Journal of Computer and
Telecommunications Networking, ISSN: 1389-1286, Telecommunications Networking, ISSN: 1389-1286, March
March 2013. 2013.
[lindqvist-enterprise] [lindqvist-enterprise]
Lindqvist, J., Vehmersalo, E., Manner, J., and M. Komu, Lindqvist, J., Vehmersalo, E., Manner, J., and M. Komu,
"Enterprise Network Packet Filtering for Mobile "Enterprise Network Packet Filtering for Mobile
Cryptographic Identities", International Journal of Cryptographic Identities", International Journal of
Handheld Computing Research, 1 (1), 79-94, , January- Handheld Computing Research, 1 (1), 79-94, , January-March
March 2010. 2010.
[nsrg-report] [nsrg-report]
Lear, E. and R. Droms, "What's In A Name:Thoughts from the Lear, E. and R. Droms, "What's In A Name:Thoughts from the
NSRG", draft-irtf-nsrg-report-10 (work in progress), NSRG", draft-irtf-nsrg-report-10 (work in progress),
September 2003. September 2003.
[paine-hip] [paine-hip]
Paine, R., "Beyond HIP: The End to Hacking As We Know It", Paine, R., "Beyond HIP: The End to Hacking As We Know It",
BookSurge Publishing, ISBN: 1439256047, 9781439256046, BookSurge Publishing, ISBN: 1439256047, 9781439256046,
2009. 2009.
[pham-leap] [pham-leap]
Pham, V. and T. Aura, "Security Analysis of Leap-of-Faith Pham, V. and T. Aura, "Security Analysis of Leap-of-Faith
Protocols", Seventh ICST International Conference on Protocols", Seventh ICST International Conference on
Security and Privacy for Communication Networks, , Security and Privacy for Communication Networks, ,
September 2011. September 2011.
[sarela-bloom] [sarela-bloom]
Saerelae, M., Esteve Rothenberg, C., Zahemszky, A., Saerelae, M., Esteve Rothenberg, C., Zahemszky, A.,
Nikander, P., and J. Ott, "BloomCasting: Security in Bloom Nikander, P., and J. Ott, "BloomCasting: Security in Bloom
filter based multicast", , Lecture Notes in Computer filter based multicast", , Lecture Notes in Computer
Science 2012, , pages 1-16, Springer Berlin Heidelberg, Science 2012, , pages 1-16, Springer Berlin Heidelberg,
2012. 2012.
[scultz-intermittent] [schuetz-intermittent]
Schuetz, S., Eggert, L., Schmid, S., and M. Brunner, Schuetz, S., Eggert, L., Schmid, S., and M. Brunner,
"Protocol enhancements for intermittently connected "Protocol enhancements for intermittently connected
hosts", SIGCOMM Comput. Commun. Rev., 35(3):5-18, , hosts", SIGCOMM Comput. Commun. Rev., 35(3):5-18, , July
July 2005. 2005.
[shields-hip] [shields-hip]
Shields, C. and J. Garcia-Luna-Aceves, "The HIP protocol Shields, C. and J. Garcia-Luna-Aceves, "The HIP protocol
for hierarchical multicast routing", Proceedings of the for hierarchical multicast routing", Proceedings of the
seventeenth annual ACM symposium on Principles of seventeenth annual ACM symposium on Principles of
distributed computing, pages 257-266. ACM, New York, NY, distributed computing, pages 257-266. ACM, New York, NY,
USA, ISBN: 0-89791-977-7, DOI: 10.1145/277697.277744, USA, ISBN: 0-89791-977-7, DOI: 10.1145/277697.277744,
1998. 1998.
[tritilanunt-dos] [tritilanunt-dos]
Tritilanunt, S., Boyd, C., Foo, E., and J. Nieto, Tritilanunt, S., Boyd, C., Foo, E., and J. Nieto,
"Examining the DoS Resistance of HIP", OTM Workshops (1), "Examining the DoS Resistance of HIP", OTM Workshops (1),
volume 4277 of Lecture Notes in Computer Science, pages volume 4277 of Lecture Notes in Computer Science, pages
616-625,Springer , 2006. 616-625,Springer , 2006.
[urien-rfid-draft]
Urien, P., Lee, G., and G. Pujolle, "HIP support for
RFIDs", IRTF Working draft draft-irtf-hiprg-rfid-07, April
2013.
[urien-rfid] [urien-rfid]
Urien, P., Chabanne, H., Bouet, M., de Cunha, D., Guyot, Urien, P., Chabanne, H., Bouet, M., de Cunha, D., Guyot,
V., Pujolle, G., Paradinas, P., Gressier, E., and J. V., Pujolle, G., Paradinas, P., Gressier, E., and J.
Susini, "HIP-based RFID Networking Architecture", IFIP Susini, "HIP-based RFID Networking Architecture", IFIP
International Conference on Wireless and Optical International Conference on Wireless and Optical
Communications Networks, DOI: 10.1109/WOCN.2007.4284140, Communications Networks, DOI: 10.1109/WOCN.2007.4284140,
July 2007. July 2007.
[urien-rfid-draft]
Urien, P., Lee, G., and G. Pujolle, "HIP support for
RFIDs", IRTF Working draft draft-irtf-hiprg-rfid-07,
April 2013.
[varjonen-split] [varjonen-split]
Varjonen, S., Komu, M., and A. Gurtov, "Secure and Varjonen, S., Komu, M., and A. Gurtov, "Secure and
Efficient IPv4/IPv6 Handovers Using Host-Based Identifier- Efficient IPv4/IPv6 Handovers Using Host-Based Identifier-
Location Split", Journal of Communications Software and Location Split", Journal of Communications Software and
Systems, 6(1), 2010, ISSN: 18456421, 2010. Systems, 6(1), 2010, ISSN: 18456421, 2010.
[xin-hip-lib] [xin-hip-lib]
Xin, G., "Host Identity Protocol Version 2.5", Master's Xin, G., "Host Identity Protocol Version 2.5", Master's
Thesis, Aalto University, Espoo, Finland, , June 2012. Thesis, Aalto University, Espoo, Finland, , June 2012.
skipping to change at page 39, line 46 skipping to change at page 38, line 43
Ylitalo, J., "Secure Mobility at Multiple Granularity Ylitalo, J., "Secure Mobility at Multiple Granularity
Levels over Heterogeneous Datacom Networks", Dissertation, Levels over Heterogeneous Datacom Networks", Dissertation,
Helsinki University of Technology, Espoo, Finland ISBN Helsinki University of Technology, Espoo, Finland ISBN
978-951-22-9531-9, 2008. 978-951-22-9531-9, 2008.
[ylitalo-spinat] [ylitalo-spinat]
Ylitalo, J., Salmela, P., and H. Tschofenig, "SPINAT: Ylitalo, J., Salmela, P., and H. Tschofenig, "SPINAT:
Integrating IPsec into overlay routing", Proceedings of Integrating IPsec into overlay routing", Proceedings of
the First International Conference on Security and Privacy the First International Conference on Security and Privacy
for Emerging Areas in Communication Networks (SecureComm for Emerging Areas in Communication Networks (SecureComm
2005). Athens, Greece. IEEE Computer Society, pages 315- 2005). Athens, Greece. IEEE Computer Society, pages
326, ISBN: 0-7695-2369-2, September 2005. 315-326, ISBN: 0-7695-2369-2, September 2005.
[zhang-revocation] [zhang-revocation]
Zhang, D., Kuptsov, D., and S. Shen, "Host Identifier Zhang, D., Kuptsov, D., and S. Shen, "Host Identifier
Revocation in HIP", IRTF Working Revocation in HIP", IRTF Working draft draft-irtf-hiprg-
draft draft-irtf-hiprg-revocation-05, Mar 2012. revocation-05, Mar 2012.
Authors' Addresses Authors' Addresses
Robert Moskowitz (editor) Robert Moskowitz (editor)
Verizon Verizon
1000 Bent Creek Blvd, Suite 200 1000 Bent Creek Blvd, Suite 200
Mechanicsburg, PA Mechanicsburg, PA
USA USA
Email: robert.moskowitz@verizon.com Email: robert.moskowitz@verizon.com
 End of changes. 76 change blocks. 
288 lines changed or deleted 266 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/