draft-ietf-hip-rfc4423-bis-14.txt   draft-ietf-hip-rfc4423-bis-15.txt 
Network Working Group R. Moskowitz, Ed. Network Working Group R. Moskowitz, Ed.
Internet-Draft HTT Consulting Internet-Draft HTT Consulting
Obsoletes: 4423 (if approved) M. Komu Obsoletes: 4423 (if approved) M. Komu
Intended status: Informational Ericsson Intended status: Informational Ericsson
Expires: December 9, 2016 June 7, 2016 Expires: May 18, 2017 November 14, 2016
Host Identity Protocol Architecture Host Identity Protocol Architecture
draft-ietf-hip-rfc4423-bis-14 draft-ietf-hip-rfc4423-bis-15
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.
skipping to change at page 1, line 41 skipping to change at page 1, line 41
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 December 9, 2016. This Internet-Draft will expire on May 18, 2017.
Copyright Notice Copyright Notice
Copyright (c) 2016 IETF Trust and the persons identified as the Copyright (c) 2016 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
skipping to change at page 2, line 31 skipping to change at page 2, line 31
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 . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.1. Terms common to other documents . . . . . . . . . . . . . . 4 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 . . . . . . . . . . . . . . . . . . . . . . . . . 6 3. Background . . . . . . . . . . . . . . . . . . . . . . . . . 6
3.1. A desire for a namespace for computing platforms . . . . . 6 3.1. A desire for a namespace for computing platforms . . . . . 7
4. Host Identity namespace . . . . . . . . . . . . . . . . . . . 8 4. Host Identity namespace . . . . . . . . . . . . . . . . . . . 9
4.1. Host Identifiers . . . . . . . . . . . . . . . . . . . . . 9 4.1. Host Identifiers . . . . . . . . . . . . . . . . . . . . . 10
4.2. Host Identity Hash (HIH) . . . . . . . . . . . . . . . . . 10 4.2. Host Identity Hash (HIH) . . . . . . . . . . . . . . . . . 10
4.3. Host Identity Tag (HIT) . . . . . . . . . . . . . . . . . . 10 4.3. Host Identity Tag (HIT) . . . . . . . . . . . . . . . . . . 11
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 . . . . . . . . . . . . . . . . . . . 12 5. New stack architecture . . . . . . . . . . . . . . . . . . . 13
5.1. On the multiplicity of identities . . . . . . . . . . . . . 13 5.1. On the multiplicity of identities . . . . . . . . . . . . . 14
6. Control plane . . . . . . . . . . . . . . . . . . . . . . . . 14 6. Control plane . . . . . . . . . . . . . . . . . . . . . . . . 15
6.1. Base exchange . . . . . . . . . . . . . . . . . . . . . . . 14 6.1. Base exchange . . . . . . . . . . . . . . . . . . . . . . . 15
6.2. End-host mobility and multi-homing . . . . . . . . . . . . 15 6.2. End-host mobility and multi-homing . . . . . . . . . . . . 16
6.3. Rendezvous mechanism . . . . . . . . . . . . . . . . . . . 16 6.3. Rendezvous mechanism . . . . . . . . . . . . . . . . . . . 16
6.4. Relay mechanism . . . . . . . . . . . . . . . . . . . . . . 16 6.4. Relay mechanism . . . . . . . . . . . . . . . . . . . . . . 17
6.5. Termination of the control plane . . . . . . . . . . . . . 16 6.5. Termination of the control plane . . . . . . . . . . . . . 17
7. Data plane . . . . . . . . . . . . . . . . . . . . . . . . . 16 7. Data plane . . . . . . . . . . . . . . . . . . . . . . . . . 17
8. HIP and NATs . . . . . . . . . . . . . . . . . . . . . . . . 17 8. HIP and NATs . . . . . . . . . . . . . . . . . . . . . . . . 18
8.1. HIP and Upper-layer checksums . . . . . . . . . . . . . . . 18 8.1. HIP and Upper-layer checksums . . . . . . . . . . . . . . . 19
9. Multicast . . . . . . . . . . . . . . . . . . . . . . . . . . 18 9. Multicast . . . . . . . . . . . . . . . . . . . . . . . . . . 19
10. HIP policies . . . . . . . . . . . . . . . . . . . . . . . . 19 10. HIP policies . . . . . . . . . . . . . . . . . . . . . . . . 19
11. Design considerations . . . . . . . . . . . . . . . . . . . . 20 11. Design considerations . . . . . . . . . . . . . . . . . . . . 20
11.1. Benefits of HIP . . . . . . . . . . . . . . . . . . . . . 20 11.1. Benefits of HIP . . . . . . . . . . . . . . . . . . . . . 20
11.2. Drawbacks of HIP . . . . . . . . . . . . . . . . . . . . . 22 11.2. Drawbacks of HIP . . . . . . . . . . . . . . . . . . . . . 23
11.3. Deployment and adoption considerations . . . . . . . . . . 23 11.3. Deployment and adoption considerations . . . . . . . . . . 24
11.3.1. Deployment analysis . . . . . . . . . . . . . . . . . . 24 11.3.1. Deployment analysis . . . . . . . . . . . . . . . . . . 24
11.3.2. HIP in 802.15.4 networks . . . . . . . . . . . . . . . . 25 11.3.2. HIP in 802.15.4 networks . . . . . . . . . . . . . . . . 25
11.4. Answers to NSRG questions . . . . . . . . . . . . . . . . 25 11.3.3. HIP and Internet of Things . . . . . . . . . . . . . . . 26
12. Security considerations . . . . . . . . . . . . . . . . . . . 27 11.4. Answers to NSRG questions . . . . . . . . . . . . . . . . 27
12.1. MiTM Attacks . . . . . . . . . . . . . . . . . . . . . . . 27 12. Security considerations . . . . . . . . . . . . . . . . . . . 29
12.2. Protection against flooding attacks . . . . . . . . . . . 28 12.1. MiTM Attacks . . . . . . . . . . . . . . . . . . . . . . . 29
12.3. HITs used in ACLs . . . . . . . . . . . . . . . . . . . . 29 12.2. Protection against flooding attacks . . . . . . . . . . . 30
12.4. Alternative HI considerations . . . . . . . . . . . . . . 31 12.3. HITs used in ACLs . . . . . . . . . . . . . . . . . . . . 31
13. IANA considerations . . . . . . . . . . . . . . . . . . . . . 31 12.4. Alternative HI considerations . . . . . . . . . . . . . . 32
14. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 31 13. IANA considerations . . . . . . . . . . . . . . . . . . . . . 33
15. Changes from RFC 4423 . . . . . . . . . . . . . . . . . . . . 32 14. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 33
16. References . . . . . . . . . . . . . . . . . . . . . . . . . 32 15. Changes from RFC 4423 . . . . . . . . . . . . . . . . . . . . 33
16.1. Normative References . . . . . . . . . . . . . . . . . . . 32 16. References . . . . . . . . . . . . . . . . . . . . . . . . . 34
16.2. Informative references . . . . . . . . . . . . . . . . . . 33 16.1. Normative References . . . . . . . . . . . . . . . . . . . 34
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 39 16.2. Informative references . . . . . . . . . . . . . . . . . . 35
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 42
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.
skipping to change at page 4, line 36 skipping to change at page 5, line 4
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 a relative term here, ranging from "known to |
| | a relative term here, ranging from "known to peers | | | 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 |
| | to the party identified by the corresponding public | | | public key. Used by the identified party to |
| | key. Used by the identified party to authenticate | | | authenticate its identity to other parties. |
| | its identity to other parties. | | Public key | An asymmetric cryptographic key pair consisting |
| Public key | An asymmetric cryptographic key pair consisting of | | pair | of public and private keys. For example, Rivest- |
| pair | public and private keys. For example, Rivest- | | | Shamir-Adleman (RSA), Digital Signature Algorithm |
| | Shamir-Adleman (RSA), Digital Signature Algorithm | | | (DSA) and Elliptic Curve DSA (ECDSA) key pairs |
| | (DSA) and Elliptic Curve DSA (ECDSA) key pairs are | | | are such key pairs. |
| | such key pairs. | | End-point | A communicating entity. For historical reasons, |
| End-point | A communicating entity. For historical reasons, | | | the term 'computing platform' is used in this |
| | the term 'computing platform' is used in this | | | document as a (rough) synonym for end-point. |
| | 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 the base definitions. See the text elsewhere in this document and the base
specification [RFC7401] for more elaborate explanations. specification [RFC7401] for more elaborate explanations.
+-------------------+-----------------------------------------------+ +---------------+---------------------------------------------------+
| Term | Explanation | | Term | Explanation |
+-------------------+-----------------------------------------------+ +---------------+---------------------------------------------------+
| Computing | An entity capable of communicating and | | Computing | An entity capable of communicating and computing, |
| platform | computing, for example, a computer. See the | | platform | for example, a computer. See the definition of |
| | definition of 'End-point', above. | | | 'End-point', above. |
| HIP base exchange | A cryptographic protocol; see also Section 6. | | HIP base | A cryptographic protocol; see also Section 6. |
| HIP packet | An IP packet that carries a 'Host Identity | | exchange | |
| | Protocol' message. | | HIP packet | An IP packet that carries a 'Host Identity |
| Host Identity | An abstract concept assigned to a 'computing | | | Protocol' message. |
| | platform'. See 'Host Identifier', below. | | Host Identity | An abstract concept assigned to a 'computing |
| Host Identity | A name space formed by all possible Host | | | platform'. See 'Host Identifier', below. |
| namespace | Identifiers. | | Host Identity | A name space formed by all possible Host |
| Host Identity | A protocol used to carry and authenticate | | namespace | Identifiers. |
| Protocol | Host Identifiers and other information. | | Host Identity | A protocol used to carry and authenticate Host |
| Host Identity | The cryptographic hash used in creating the | | Protocol | Identifiers and other information. |
| Hash | Host Identity Tag from the Host Identity. | | Host Identity | The cryptographic hash used in creating the Host |
| Host Identity Tag | A 128-bit datum created by taking a | | Hash | Identity Tag from the Host Identity. |
| | cryptographic hash over a Host Identifier | | Host Identity | A 128-bit datum created by taking a cryptographic |
| | plus bits to identify which hash used. | | Tag | hash over a Host Identifier plus bits to identify |
| Host Identifier | A public key used as a name for a Host | | | which hash used. |
| | Identity. | | Host | A public key used as a name for a Host Identity. |
| Local Scope | A 32-bit datum denoting a Host Identity. | | Identifier | |
| Identifier | | | Local Scope | A 32-bit datum denoting a Host Identity. |
| Public Host | A published or publicly known Host Identifier | | Identifier | |
| Identifier and | used as a public name for a Host Identity, | | Public Host | A published or publicly known Host Identifier |
| Identity | and the corresponding Identity. | | Identifier | used as a public name for a Host Identity, and |
| Unpublished Host | A Host Identifier that is not placed in any | | and Identity | the corresponding Identity. |
| Identifier and | public directory, and the corresponding Host | | Unpublished | A Host Identifier that is not placed in any |
| Identity | Identity. Unpublished Host Identities are | | Host | public directory, and the corresponding Host |
| | typically short lived in nature, being often | | Identifier | Identity. Unpublished Host Identities are |
| | replaced and possibly used just once. | | and Identity | typically short lived in nature, being often |
| Rendezvous | A mechanism used to locate mobile hosts based | | | replaced and possibly used just once. |
| Mechanism | on their HIT. | | 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 12, line 13 skipping to change at page 12, line 45
for IPv4. In other words, the applications violating layering for IPv4. In other words, the applications violating layering
principles are already broken by the NAT boxes that are ubiquitously principles are already broken by the NAT boxes that are ubiquitously
deployed. deployed.
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 [RFC8005].
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, a they may be stored in various other directories. For instance, a
directory based on the Lightweight Directory Access Protocol (LDAP) directory based on the Lightweight Directory Access Protocol (LDAP)
or a Public Key Infrastructure (PKI) [I-D.ietf-hip-rfc6253-bis] may or a Public Key Infrastructure (PKI) [I-D.ietf-hip-rfc6253-bis] may
be used. Alternatively, Distributed Hash Tables (DHTs) [RFC6537] be used. Alternatively, Distributed Hash Tables (DHTs) [RFC6537]
have successfully been utilized [RFC6538]. Such a practice may allow have successfully been utilized [RFC6538]. Such a practice may allow
them to be used for purposes other than pure host identification. them to be used for purposes other than pure host identification.
Some types of applications may cache and use Host Identifiers Some types of applications may cache and use Host Identifiers
skipping to change at page 16, line 13 skipping to change at page 17, line 7
connection after the initial connection). connection after the initial connection).
6.3. Rendezvous mechanism 6.3. Rendezvous mechanism
Establishing a contact to a mobile, moving node is slightly more Establishing a contact to a mobile, moving node is slightly more
involved. In order to start the HIP exchange, the initiator node has involved. In order to start the HIP exchange, the initiator node has
to know how to reach the mobile node. For instance, the mobile node to know how to reach the mobile node. For instance, the mobile node
can employ Dynamic DNS [RFC2136] to update its reachability can employ Dynamic DNS [RFC2136] to update its reachability
information in the DNS. To avoid the dependency to DNS, HIP provides information in the DNS. To avoid the dependency to DNS, HIP provides
its own HIP-specific alternative: the HIP rendezvous mechanism as its own HIP-specific alternative: the HIP rendezvous mechanism as
defined in HIP Rendezvous specifications [I-D.ietf-hip-rfc5204-bis]. defined in HIP Rendezvous specifications [RFC8004].
Using the HIP rendezvous extensions, the mobile node keeps the Using the HIP rendezvous extensions, the mobile node keeps the
rendezvous infrastructure continuously updated with its current IP rendezvous infrastructure continuously updated with its current IP
address(es). The mobile nodes trusts the rendezvous mechanism in address(es). The mobile nodes trusts the rendezvous mechanism in
order to properly maintain their HIT and IP address mappings. order to properly maintain their HIT and IP address mappings.
The rendezvous mechanism is especially useful in scenarios where both The rendezvous mechanism is especially useful in scenarios where both
of the nodes are expected to change their address at the same time. of the nodes are expected to change their address at the same time.
In such a case, the HIP UPDATE packets will cross each other in the In such a case, the HIP UPDATE packets will cross each other in the
network and never reach the peer node. network and never reach the peer node.
skipping to change at page 19, line 29 skipping to change at page 20, line 13
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
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 [RFC8003] (i.e. utilized by HIP for its own internal purposes) or by
purposes) or by the application layer [komu-leap]. For security the application layer [komu-leap]. For security reasons, especially
reasons, especially the latter requires some involvement from the the latter requires some involvement from the user to accept the
user to accept the identity of the responder similar to how SSH identity of the responder similar to how SSH prompts the user when
prompts the user when connecting to a server for the first time connecting to a server for the first time [pham-leap]. In practice,
[pham-leap]. In practice, this can be realized in end-host based this can be realized in end-host based firewalls in the case of
firewalls in the case of legacy applications [karvonen-usable] or legacy applications [karvonen-usable] or with native APIs for HIP
with native APIs for HIP APIs [RFC6317] in the case of HIP-aware 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 mapping responders. The implementations should provide for a policy mapping
of initiator HITs to responder HITs. 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.
skipping to change at page 25, line 37 skipping to change at page 26, line 17
o Master Keys in 802 protocols are commonly pair-based with group o Master Keys in 802 protocols are commonly pair-based with group
keys transported from the group controller using pair-wise keys. keys transported from the group controller using pair-wise keys.
o AdHoc 802 networks can be better served by a peer-to-peer KMS than o AdHoc 802 networks can be better served by a peer-to-peer KMS than
the EAP client/server model. the EAP client/server model.
o Some devices are very memory constrained and a common KMS for both o Some devices are very memory constrained and a common KMS for both
MAC and IP security represents a considerable code savings. MAC and IP security represents a considerable code savings.
11.3.3. HIP and Internet of Things
HIP requires certain amount computational resources from a device due
to cryptographic processing. HIP scales down to phones and small
system-on-chip devices (such as Raspberry Pis, Intel Edison), but
small sensors operating with small batteries have remained
problematic. Different extensions to the HIP have been developed to
scale HIP down to smaller devices, typically with different security
tradeoffs. For example, the non-cryptographic identifiers have been
proposed in RFID scenarios. The slimfit approach [hummen] proposes a
compression layer for HIP to make it more suitable for constrained
networks. The approach is applied to a light-weight version of HIP
(i.e. "Diet HIP") in order to scale down to small sensors.
The HIP Diet Exchange [I-D.ietf-hip-dex] design aims at reducing the
overhead of the employed cryptographic primitives by omitting public-
key signatures and hash functions. In doing so, the main goal is to
still deliver similar security properties to the Base Exchange (BEX).
DEX is primarily designed for computation or memory- constrained
sensor/actuator devices. Like BEX, it is expected to be used
together with a suitable security protocol such as the Encapsulated
Security Payload (ESP) for the protection of upper layer protocol
data. In addition, DEX can also be used as a keying mechanism for
security primitives at the MAC layer, e.g., for IEEE 802.15.9
networks ([IEEE.802-15-9].
The main differences between HIP BEX and DEX are:
1. Minimum collection of cryptographic primitives to reduce the
protocol overhead.
* Static Elliptic Curve Diffie-Hellman key pairs for peer
authentication and encryption of the session key.
* AES-CTR for symmetric encryption and AES-CMAC for MACing
function.
* A simple fold function for HIT generation.
2. Forfeit of Perfect Forward Secrecy with the dropping of an
ephemeral Diffie-Hellman key agreement.
3. Forfeit of digital signatures with the removal of a hash
function. Reliance on ECDH derived key used in HIP_MAC to prove
ownership of the private key.
4. Diffie-Hellman derived key ONLY used to protect the HIP packets.
A separate secret exchange within the HIP packets creates the
session key(s).
5. Optional retransmission strategy tailored to handle the
potentially extensive processing time of the employed
cryptographic operations on computationally constrained devices.
11.4. Answers to NSRG questions 11.4. Answers to NSRG questions
The IRTF Name Space Research Group has posed a number of evaluating The IRTF Name Space Research Group has posed a number of evaluating
questions in their report [nsrg-report]. In this section, we provide questions in their report [nsrg-report]. In this section, we provide
answers to these questions. answers to these questions.
1. How would a stack name improve the overall functionality of the 1. How would a stack name improve the overall functionality of the
Internet? Internet?
HIP decouples the internetworking layer from the transport HIP decouples the internetworking layer from the transport
layer, allowing each to evolve separately. The decoupling layer, allowing each to evolve separately. The decoupling
makes end-host mobility and multi-homing easier, also across makes end-host mobility and multi-homing easier, also across
IPv4 and IPv6 networks. HIs make network renumbering easier, IPv4 and IPv6 networks. HIs make network renumbering easier,
and they also make process migration and clustered servers and they also make process migration and clustered servers
easier to implement. Furthermore, being cryptographic in easier to implement. Furthermore, being cryptographic in
nature, they provide the basis for solving the security nature, they provide the basis for solving the security
problems related to end-host mobility and multi-homing. problems related to end-host mobility and multi-homing.
2. What does a stack name look like? 2. What does a stack name look like?
skipping to change at page 26, line 45 skipping to change at page 28, line 26
network services. Additionally, the Host Identifiers, as network services. Additionally, the Host Identifiers, as
public keys, are used in the built in key agreement protocol, public keys, are used in the built in key agreement protocol,
called the HIP base exchange, to authenticate the hosts to called the HIP base exchange, to authenticate the hosts to
each other. each other.
6. What administrative infrastructure is needed to support it? 6. What administrative infrastructure is needed to support it?
In some environments, it is possible to use HIP In some environments, it is possible to use HIP
opportunistically, without any infrastructure. However, to opportunistically, without any infrastructure. However, to
gain full benefit from HIP, the HIs must be stored in the DNS gain full benefit from HIP, the HIs must be stored in the DNS
or a PKI, and a new rendezvous mechanism is needed or a PKI, and a new rendezvous mechanism is needed [RFC8005].
[I-D.ietf-hip-rfc5205-bis].
7. If we add an additional layer would it make the address list in 7. If we add an additional layer would it make the address list in
SCTP unnecessary? SCTP unnecessary?
Yes Yes
8. What additional security benefits would a new naming scheme 8. What additional security benefits would a new naming scheme
offer? offer?
HIP reduces dependency on IP addresses, making the so called HIP reduces dependency on IP addresses, making the so called
skipping to change at page 32, line 20 skipping to change at page 33, line 50
the reference jungle. the reference jungle.
15. Changes from RFC 4423 15. Changes from RFC 4423
In a nutshell, the changes from RFC 4423 [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, HIP for IoT scenarios, deployment
of the base exchange. considerations and description of the base exchange.
16. References 16. References
16.1. Normative References 16.1. Normative References
[I-D.ietf-hip-dex]
Moskowitz, R. and R. Hummen, "HIP Diet EXchange (DEX)",
draft-ietf-hip-dex-04 (work in progress), October 2016.
[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", draft-ietf-hip- with the Host Identity Protocol", draft-ietf-hip-
multihoming-09 (work in progress), May 2016. multihoming-12 (work in progress), October 2016.
[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., Melen, J., and M. Komu, "Native NAT Traversal
the Host Identity Protocol", draft-ietf-hip-native-nat- Mode for the Host Identity Protocol", draft-ietf-hip-
traversal-10 (work in progress), January 2016. native-nat-traversal-13 (work in progress), July 2016.
[I-D.ietf-hip-rfc5203-bis]
Laganier, J. and L. Eggert, "Host Identity Protocol (HIP)
Registration Extension", draft-ietf-hip-rfc5203-bis-10
(work in progress), January 2016.
[I-D.ietf-hip-rfc5204-bis]
Laganier, J. and L. Eggert, "Host Identity Protocol (HIP)
Rendezvous Extension", draft-ietf-hip-rfc5204-bis-07 (work
in progress), December 2015.
[I-D.ietf-hip-rfc5205-bis]
Laganier, J., "Host Identity Protocol (HIP) Domain Name
System (DNS) Extension", draft-ietf-hip-rfc5205-bis-09
(work in progress), January 2016.
[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-12 the Host Identity Protocol", draft-ietf-hip-rfc5206-bis-14
(work in progress), May 2016. (work in progress), October 2016.
[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-08 (work in Certificates", draft-ietf-hip-rfc6253-bis-09 (work in
progress), April 2016. progress), July 2016.
[RFC5482] Eggert, L. and F. Gont, "TCP User Timeout Option", RFC [RFC5482] Eggert, L. and F. Gont, "TCP User Timeout Option",
5482, DOI 10.17487/RFC5482, March 2009, RFC 5482, DOI 10.17487/RFC5482, March 2009,
<http://www.rfc-editor.org/info/rfc5482>. <http://www.rfc-editor.org/info/rfc5482>.
[RFC7343] Laganier, J. and F. Dupont, "An IPv6 Prefix for Overlay [RFC7343] Laganier, J. and F. Dupont, "An IPv6 Prefix for Overlay
Routable Cryptographic Hash Identifiers Version 2 Routable Cryptographic Hash Identifiers Version 2
(ORCHIDv2)", RFC 7343, DOI 10.17487/RFC7343, September (ORCHIDv2)", RFC 7343, DOI 10.17487/RFC7343, September
2014, <http://www.rfc-editor.org/info/rfc7343>. 2014, <http://www.rfc-editor.org/info/rfc7343>.
[RFC7401] Moskowitz, R., Ed., Heer, T., Jokela, P., and T. [RFC7401] Moskowitz, R., Ed., Heer, T., Jokela, P., and T.
Henderson, "Host Identity Protocol Version 2 (HIPv2)", RFC Henderson, "Host Identity Protocol Version 2 (HIPv2)",
7401, DOI 10.17487/RFC7401, April 2015, RFC 7401, DOI 10.17487/RFC7401, April 2015,
<http://www.rfc-editor.org/info/rfc7401>. <http://www.rfc-editor.org/info/rfc7401>.
[RFC7402] Jokela, P., Moskowitz, R., and J. Melen, "Using the [RFC7402] 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)", RFC 7402, DOI 10.17487/ the Host Identity Protocol (HIP)", RFC 7402,
RFC7402, April 2015, DOI 10.17487/RFC7402, April 2015,
<http://www.rfc-editor.org/info/rfc7402>. <http://www.rfc-editor.org/info/rfc7402>.
16.2. Informative references [RFC8003] Laganier, J. and L. Eggert, "Host Identity Protocol (HIP)
Registration Extension", RFC 8003, DOI 10.17487/RFC8003,
[IEEE.802-15-4.2011] October 2016, <http://www.rfc-editor.org/info/rfc8003>.
, "Information technology - Telecommunications and
information exchange between systems - Local and
metropolitan area networks - Specific requirements - Part
15.4: Wireless Medium Access Control (MAC) and Physical
Layer (PHY) Specifications for Low-Rate Wireless Personal
Area Networks (WPANs)", IEEE Standard 802.15.4, September
2011, <http://standards.ieee.org/getieee802/download/
802.15.4-2011.pdf>.
[Nik2001] Nikander, P., "Denial-of-Service, Address Ownership, and
Early Authentication in the IPv6 World", in Proceesings of
Security Protocols, 9th International Workshop, Cambridge,
UK, April 25-27 2001, LNCS 2467, pp. 12-26, Springer,
2002.
[RFC2136] Vixie, P., Ed., Thomson, S., Rekhter, Y., and J. Bound,
"Dynamic Updates in the Domain Name System (DNS UPDATE)",
RFC 2136, DOI 10.17487/RFC2136, April 1997,
<http://www.rfc-editor.org/info/rfc2136>.
[RFC2535] Eastlake 3rd, D., "Domain Name System Security
Extensions", RFC 2535, DOI 10.17487/RFC2535, March 1999,
<http://www.rfc-editor.org/info/rfc2535>.
[RFC2766] Tsirtsis, G. and P. Srisuresh, "Network Address
Translation - Protocol Translation (NAT-PT)", RFC 2766,
DOI 10.17487/RFC2766, February 2000,
<http://www.rfc-editor.org/info/rfc2766>.
[RFC3022] Srisuresh, P. and K. Egevang, "Traditional IP Network
Address Translator (Traditional NAT)", RFC 3022, DOI
10.17487/RFC3022, January 2001,
<http://www.rfc-editor.org/info/rfc3022>.
[RFC3102] Borella, M., Lo, J., Grabelsky, D., and G. Montenegro,
"Realm Specific IP: Framework", RFC 3102, DOI 10.17487/
RFC3102, October 2001,
<http://www.rfc-editor.org/info/rfc3102>.
[RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H.
Levkowetz, Ed., "Extensible Authentication Protocol
(EAP)", RFC 3748, DOI 10.17487/RFC3748, June 2004,
<http://www.rfc-editor.org/info/rfc3748>.
[RFC4225] Nikander, P., Arkko, J., Aura, T., Montenegro, G., and E.
Nordmark, "Mobile IP Version 6 Route Optimization Security
Design Background", RFC 4225, DOI 10.17487/RFC4225,
December 2005, <http://www.rfc-editor.org/info/rfc4225>.
[RFC4306] Kaufman, C., Ed., "Internet Key Exchange (IKEv2)
Protocol", RFC 4306, DOI 10.17487/RFC4306, December 2005,
<http://www.rfc-editor.org/info/rfc4306>.
[RFC4423] Moskowitz, R. and P. Nikander, "Host Identity Protocol
(HIP) Architecture", RFC 4423, DOI 10.17487/RFC4423, May
2006, <http://www.rfc-editor.org/info/rfc4423>.
[RFC5218] Thaler, D. and B. Aboba, "What Makes For a Successful
Protocol?", RFC 5218, DOI 10.17487/RFC5218, July 2008,
<http://www.rfc-editor.org/info/rfc5218>.
[RFC5338] Henderson, T., Nikander, P., and M. Komu, "Using the Host
Identity Protocol with Legacy Applications", RFC 5338, DOI
10.17487/RFC5338, September 2008,
<http://www.rfc-editor.org/info/rfc5338>.
[RFC5887] Carpenter, B., Atkinson, R., and H. Flinck, "Renumbering
Still Needs Work", RFC 5887, DOI 10.17487/RFC5887, May
2010, <http://www.rfc-editor.org/info/rfc5887>.
[RFC6078] Camarillo, G. and J. Melen, "Host Identity Protocol (HIP)
Immediate Carriage and Conveyance of Upper-Layer Protocol
Signaling (HICCUPS)", RFC 6078, DOI 10.17487/RFC6078,
January 2011, <http://www.rfc-editor.org/info/rfc6078>.
[RFC6250] Thaler, D., "Evolution of the IP Model", RFC 6250, DOI
10.17487/RFC6250, May 2011,
<http://www.rfc-editor.org/info/rfc6250>.
[RFC6281] Cheshire, S., Zhu, Z., Wakikawa, R., and L. Zhang,
"Understanding Apple's Back to My Mac (BTMM) Service", RFC
6281, DOI 10.17487/RFC6281, June 2011,
<http://www.rfc-editor.org/info/rfc6281>.
[RFC6317] Komu, M. and T. Henderson, "Basic Socket Interface [RFC8004] Laganier, J. and L. Eggert, "Host Identity Protocol (HIP)
Extensions for the Host Identity Protocol (HIP)", RFC Rendezvous Extension", RFC 8004, DOI 10.17487/RFC8004,
6317, DOI 10.17487/RFC6317, July 2011, October 2016, <http://www.rfc-editor.org/info/rfc8004>.
<http://www.rfc-editor.org/info/rfc6317>.
[RFC6537] Ahrenholz, J., "Host Identity Protocol Distributed Hash [RFC8005] Laganier, J., "Host Identity Protocol (HIP) Domain Name
Table Interface", RFC 6537, DOI 10.17487/RFC6537, February System (DNS) Extension", RFC 8005, DOI 10.17487/RFC8005,
2012, <http://www.rfc-editor.org/info/rfc6537>. October 2016, <http://www.rfc-editor.org/info/rfc8005>.
[RFC6538] Henderson, T. and A. Gurtov, "The Host Identity Protocol 16.2. Informative references
(HIP) Experiment Report", RFC 6538, DOI 10.17487/RFC6538,
March 2012, <http://www.rfc-editor.org/info/rfc6538>.
[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
for HIP and HIP Multicast", International Journal of for HIP and HIP Multicast", International Journal of
Dependable and Trustworthy Information Systems (IJDTIS), Dependable and Trustworthy Information Systems (IJDTIS),
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", URL Enhancement to the Internet Architecture",
http://www.chiappa.net/~jnc/tech/endpoints.txt, 1999. URL 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,
skipping to change at page 36, line 33 skipping to change at page 36, line 15
[henderson-vpls] [henderson-vpls]
Henderson, T. and D. Mattes, "HIP-based Virtual Private Henderson, T. and D. Mattes, "HIP-based Virtual Private
LAN Service (HIPLS)", Working draft draft-henderson-hip- LAN Service (HIPLS)", Working draft draft-henderson-hip-
vpls-07, Dec 2013. 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 draft draft- transport format with HIP", Working draft draft-
tschofenig-hiprg-hip-srtp-01, October 2005. tschofenig-hiprg-hip-srtp-01, October 2005.
[hummen] Hummen, R., Hiller, J., Henze, M., and K. Wehrle, "Slimfit
- A HIP DEX Compression Layer for the IP-based Internet of
Things", Wireless and Mobile Computing, Networking and
Communications (WiMob), 2013 IEEE 9th International
Conference on , page 259-266. DOI:
10.1109/WiMOB.2013.6673370, October 2013.
[IEEE.802-15-4.2011]
"Information technology - Telecommunications and
information exchange between systems - Local and
metropolitan area networks - Specific requirements - Part
15.4: Wireless Medium Access Control (MAC) and Physical
Layer (PHY) Specifications for Low-Rate Wireless Personal
Area Networks (WPANs)", IEEE Standard 802.15.4, September
2011, <http://standards.ieee.org/getieee802/
download/802.15.4-2011.pdf>.
[IEEE.802-15-9]
"IEEE Draft Recommended Practice for Transort of Key
Management Protocol (KMP) Datagrams", IEEE P802.15.9/D04,
May 2015.
[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
skipping to change at page 37, line 23 skipping to change at page 37, line 30
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, CA, USA, http://doi.ieeecomputersociety.org/10.1109/
http://doi.ieeecomputersociety.org/10.1109/ICNS.2007.66, ICNS.2007.66, 2007.
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, March Telecommunications Networking, ISSN: 1389-1286, 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-March Handheld Computing Research, 1 (1), 79-94, , January-March
2010. 2010.
[Nik2001] Nikander, P., "Denial-of-Service, Address Ownership, and
Early Authentication in the IPv6 World", in Proceesings
of Security Protocols, 9th International Workshop,
Cambridge, UK, April 25-27 2001, LNCS 2467, pp. 12-26,
Springer, 2002.
[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.
[RFC2136] Vixie, P., Ed., Thomson, S., Rekhter, Y., and J. Bound,
"Dynamic Updates in the Domain Name System (DNS UPDATE)",
RFC 2136, DOI 10.17487/RFC2136, April 1997,
<http://www.rfc-editor.org/info/rfc2136>.
[RFC2535] Eastlake 3rd, D., "Domain Name System Security
Extensions", RFC 2535, DOI 10.17487/RFC2535, March 1999,
<http://www.rfc-editor.org/info/rfc2535>.
[RFC2766] Tsirtsis, G. and P. Srisuresh, "Network Address
Translation - Protocol Translation (NAT-PT)", RFC 2766,
DOI 10.17487/RFC2766, February 2000,
<http://www.rfc-editor.org/info/rfc2766>.
[RFC3022] Srisuresh, P. and K. Egevang, "Traditional IP Network
Address Translator (Traditional NAT)", RFC 3022,
DOI 10.17487/RFC3022, January 2001,
<http://www.rfc-editor.org/info/rfc3022>.
[RFC3102] Borella, M., Lo, J., Grabelsky, D., and G. Montenegro,
"Realm Specific IP: Framework", RFC 3102,
DOI 10.17487/RFC3102, October 2001,
<http://www.rfc-editor.org/info/rfc3102>.
[RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H.
Levkowetz, Ed., "Extensible Authentication Protocol
(EAP)", RFC 3748, DOI 10.17487/RFC3748, June 2004,
<http://www.rfc-editor.org/info/rfc3748>.
[RFC4225] Nikander, P., Arkko, J., Aura, T., Montenegro, G., and E.
Nordmark, "Mobile IP Version 6 Route Optimization Security
Design Background", RFC 4225, DOI 10.17487/RFC4225,
December 2005, <http://www.rfc-editor.org/info/rfc4225>.
[RFC4306] Kaufman, C., Ed., "Internet Key Exchange (IKEv2)
Protocol", RFC 4306, DOI 10.17487/RFC4306, December 2005,
<http://www.rfc-editor.org/info/rfc4306>.
[RFC4423] Moskowitz, R. and P. Nikander, "Host Identity Protocol
(HIP) Architecture", RFC 4423, DOI 10.17487/RFC4423, May
2006, <http://www.rfc-editor.org/info/rfc4423>.
[RFC5218] Thaler, D. and B. Aboba, "What Makes For a Successful
Protocol?", RFC 5218, DOI 10.17487/RFC5218, July 2008,
<http://www.rfc-editor.org/info/rfc5218>.
[RFC5338] Henderson, T., Nikander, P., and M. Komu, "Using the Host
Identity Protocol with Legacy Applications", RFC 5338,
DOI 10.17487/RFC5338, September 2008,
<http://www.rfc-editor.org/info/rfc5338>.
[RFC5887] Carpenter, B., Atkinson, R., and H. Flinck, "Renumbering
Still Needs Work", RFC 5887, DOI 10.17487/RFC5887, May
2010, <http://www.rfc-editor.org/info/rfc5887>.
[RFC6078] Camarillo, G. and J. Melen, "Host Identity Protocol (HIP)
Immediate Carriage and Conveyance of Upper-Layer Protocol
Signaling (HICCUPS)", RFC 6078, DOI 10.17487/RFC6078,
January 2011, <http://www.rfc-editor.org/info/rfc6078>.
[RFC6250] Thaler, D., "Evolution of the IP Model", RFC 6250,
DOI 10.17487/RFC6250, May 2011,
<http://www.rfc-editor.org/info/rfc6250>.
[RFC6281] Cheshire, S., Zhu, Z., Wakikawa, R., and L. Zhang,
"Understanding Apple's Back to My Mac (BTMM) Service",
RFC 6281, DOI 10.17487/RFC6281, June 2011,
<http://www.rfc-editor.org/info/rfc6281>.
[RFC6317] Komu, M. and T. Henderson, "Basic Socket Interface
Extensions for the Host Identity Protocol (HIP)",
RFC 6317, DOI 10.17487/RFC6317, July 2011,
<http://www.rfc-editor.org/info/rfc6317>.
[RFC6537] Ahrenholz, J., "Host Identity Protocol Distributed Hash
Table Interface", RFC 6537, DOI 10.17487/RFC6537, February
2012, <http://www.rfc-editor.org/info/rfc6537>.
[RFC6538] Henderson, T. and A. Gurtov, "The Host Identity Protocol
(HIP) Experiment Report", RFC 6538, DOI 10.17487/RFC6538,
March 2012, <http://www.rfc-editor.org/info/rfc6538>.
[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.
[schuetz-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, , July hosts", SIGCOMM Comput. Commun. Rev., 35(3):5-18, , 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
skipping to change at page 38, line 36 skipping to change at page 40, line 36
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.
 End of changes. 39 change blocks. 
244 lines changed or deleted 311 lines changed or added

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