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/