draft-ietf-hip-rfc4423-bis-09.txt   draft-ietf-hip-rfc4423-bis-10.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 Ericsson
Expires: April 23, 2015 October 20, 2014 Expires: October 14, 2015 April 12, 2015
Host Identity Protocol Architecture Host Identity Protocol Architecture
draft-ietf-hip-rfc4423-bis-09 draft-ietf-hip-rfc4423-bis-10
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 April 23, 2015. This Internet-Draft will expire on October 14, 2015.
Copyright Notice Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the Copyright (c) 2015 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 2, line 50 skipping to change at page 2, line 50
6. Control plane . . . . . . . . . . . . . . . . . . . . . . . . 14 6. Control plane . . . . . . . . . . . . . . . . . . . . . . . . 14
6.1. Base exchange . . . . . . . . . . . . . . . . . . . . . . . 14 6.1. Base exchange . . . . . . . . . . . . . . . . . . . . . . . 14
6.2. End-host mobility and multi-homing . . . . . . . . . . . . 15 6.2. End-host mobility and multi-homing . . . . . . . . . . . . 15
6.3. Rendezvous mechanism . . . . . . . . . . . . . . . . . . . 16 6.3. Rendezvous mechanism . . . . . . . . . . . . . . . . . . . 16
6.4. Relay mechanism . . . . . . . . . . . . . . . . . . . . . . 16 6.4. Relay mechanism . . . . . . . . . . . . . . . . . . . . . . 16
6.5. Termination of the control plane . . . . . . . . . . . . . 16 6.5. Termination of the control plane . . . . . . . . . . . . . 16
7. Data plane . . . . . . . . . . . . . . . . . . . . . . . . . 16 7. Data plane . . . . . . . . . . . . . . . . . . . . . . . . . 16
8. HIP and NATs . . . . . . . . . . . . . . . . . . . . . . . . 17 8. HIP and NATs . . . . . . . . . . . . . . . . . . . . . . . . 17
8.1. HIP and Upper-layer checksums . . . . . . . . . . . . . . . 18 8.1. HIP and Upper-layer checksums . . . . . . . . . . . . . . . 18
9. Multicast . . . . . . . . . . . . . . . . . . . . . . . . . . 18 9. Multicast . . . . . . . . . . . . . . . . . . . . . . . . . . 18
10. HIP policies . . . . . . . . . . . . . . . . . . . . . . . . 18 10. HIP policies . . . . . . . . . . . . . . . . . . . . . . . . 19
11. Design considerations . . . . . . . . . . . . . . . . . . . . 19 11. Design considerations . . . . . . . . . . . . . . . . . . . . 20
11.1. Benefits of HIP . . . . . . . . . . . . . . . . . . . . . 19 11.1. Benefits of HIP . . . . . . . . . . . . . . . . . . . . . 20
11.2. Drawbacks of HIP . . . . . . . . . . . . . . . . . . . . . 22 11.2. Drawbacks of HIP . . . . . . . . . . . . . . . . . . . . . 22
11.3. Deployment and adoption considerations . . . . . . . . . . 23 11.3. Deployment and adoption considerations . . . . . . . . . . 23
11.3.1. Deployment analysis . . . . . . . . . . . . . . . . . . 23 11.3.1. Deployment analysis . . . . . . . . . . . . . . . . . . 24
11.3.2. HIP in 802.15.4 networks . . . . . . . . . . . . . . . . 24 11.3.2. HIP in 802.15.4 networks . . . . . . . . . . . . . . . . 25
11.4. Answers to NSRG questions . . . . . . . . . . . . . . . . 25 11.4. Answers to NSRG questions . . . . . . . . . . . . . . . . 25
12. Security considerations . . . . . . . . . . . . . . . . . . . 27 12. Security considerations . . . . . . . . . . . . . . . . . . . 27
12.1. MiTM Attacks . . . . . . . . . . . . . . . . . . . . . . . 27 12.1. MiTM Attacks . . . . . . . . . . . . . . . . . . . . . . . 27
12.2. Protection against flooding attacks . . . . . . . . . . . 28 12.2. Protection against flooding attacks . . . . . . . . . . . 28
12.3. HITs used in ACLs . . . . . . . . . . . . . . . . . . . . 29 12.3. HITs used in ACLs . . . . . . . . . . . . . . . . . . . . 29
12.4. Alternative HI considerations . . . . . . . . . . . . . . 30 12.4. Alternative HI considerations . . . . . . . . . . . . . . 31
13. IANA considerations . . . . . . . . . . . . . . . . . . . . . 31 13. IANA considerations . . . . . . . . . . . . . . . . . . . . . 31
14. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 31 14. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 31
15. Changes from RFC 4423 . . . . . . . . . . . . . . . . . . . . 31 15. Changes from RFC 4423 . . . . . . . . . . . . . . . . . . . . 32
16. References . . . . . . . . . . . . . . . . . . . . . . . . . 31 16. References . . . . . . . . . . . . . . . . . . . . . . . . . 32
16.1. Normative References . . . . . . . . . . . . . . . . . . . 32 16.1. Normative References . . . . . . . . . . . . . . . . . . . 32
16.2. Informative references . . . . . . . . . . . . . . . . . . 33 16.2. Informative references . . . . . . . . . . . . . . . . . . 33
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 39 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
skipping to change at page 4, line 20 skipping to change at page 4, line 20
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 6. 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 typically, but not necessarily, protected with ESP [RFC7402]. The
[I-D.ietf-hip-rfc5202-bis]. The Host Identities are used to create Host Identities are used to create the needed ESP Security
the needed ESP Security Associations (SAs) and to authenticate the Associations (SAs) and to authenticate the hosts. When ESP is used,
hosts. When ESP is used, the actual payload IP packets do not differ the actual payload IP packets do not differ in any way from standard
in any way from standard ESP protected IP packets. 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
skipping to change at page 4, line 52 skipping to change at page 4, line 52
| | cryptographic identity authentication. Public is a | | | 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 public |
| | key. Used by the identified party to authenticate | | | key. Used by the identified party to authenticate |
| | its identity to other parties. | | | its identity to other parties. |
| Public key | An asymmetric cryptographic key pair consisting of | | Public key | An asymmetric cryptographic key pair consisting of |
| pair | public and private keys. For example, Rivest- | | pair | public and private keys. For example, Rivest- |
| | Shamir-Adelman (RSA), Digital Signature Algorithm | | | Shamir-Adleman (RSA), Digital Signature Algorithm |
| | (DSA) and Elliptic Curve DSA (ECDSA) key pairs are | | | (DSA) and Elliptic Curve DSA (ECDSA) key pairs 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 in RFC 5201 definitions. See the text elsewhere in this document and the base
[I-D.ietf-hip-rfc5201-bis] 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 |
| platform | computing, for example, a computer. See the | | platform | computing, for example, a computer. See the |
| | definition of 'End-point', above. | | | definition of 'End-point', above. |
| HIP base exchange | A cryptographic protocol; see also Section 6. | | HIP base exchange | A cryptographic protocol; see also Section 6. |
| HIP packet | An IP packet that carries a 'Host Identity | | HIP packet | An IP packet that carries a 'Host Identity |
| | Protocol' message. | | | Protocol' message. |
skipping to change at page 8, line 46 skipping to change at page 8, line 46
DNSSEC [RFC2535], PGP, or X.509 to 'notarize' the identity assertion DNSSEC [RFC2535], PGP, or X.509 to 'notarize' the identity assertion
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 [RFC7401] specification, a public-key-based HI can authenticate the
authenticate the HIP packets and protect them from man-in-the-middle HIP packets and protect them from man-in-the-middle attacks. Since
attacks. Since authenticated datagrams are mandatory to provide much authenticated datagrams are mandatory to provide much of HIP's
of HIP's denial-of-service protection, the Diffie-Hellman exchange in denial-of-service protection, the Diffie-Hellman exchange in HIP base
HIP base exchange has to be authenticated. Thus, only public-key HI exchange has to be authenticated. Thus, only public-key HI and
and authenticated HIP messages are supported in practice. 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 10, line 25 skipping to change at page 10, line 25
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 throughout 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 [RFC7401].
[I-D.ietf-hip-rfc5201-bis].
4.3. Host Identity Tag (HIT) 4.3. Host Identity Tag (HIT)
A Host Identity Tag is a 128-bit representation for a Host Identity. A Host Identity Tag is a 128-bit representation for a Host Identity.
It is created from an HIH and other information, like an IPv6 prefix It is created from an HIH, an IPv6 prefix [RFC7343] and a hash
and a hash identifier. There are two advantages of using the HIT identifier. There are two advantages of using the HIT over using the
over using the Host Identifier in protocols. Firstly, its fixed Host Identifier in protocols. Firstly, its fixed length makes for
length makes for easier protocol coding and also better manages the easier protocol coding and also better manages the packet size cost
packet size cost of this technology. Secondly, it presents the of this technology. Secondly, it presents the identity in a
identity in a consistent format to the protocol independent of the consistent format to the protocol independent of the cryptographic
cryptographic algorithms used. 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, [RFC7401] defines the minimum set for
minimum set for interoperability. For further interoperability, the interoperability. For further interoperability, the responder may
responder may store its keys in DNS records, and thus the initiator store its keys in DNS records, and thus the initiator may have to
may have to couple destination HITs with appropriate source HITs couple destination HITs with appropriate source HITs according to
according to matching HIH. 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.
4.4. Local Scope Identifier (LSI) 4.4. Local Scope Identifier (LSI)
skipping to change at page 14, line 51 skipping to change at page 14, line 51
The base exchange is a key exchange procedure that authenticates the The base exchange is a key exchange procedure that authenticates the
initiator and responder to each other using their public keys. initiator and responder to each other using their public keys.
Typically, the initiator is the client-side host and the responder is Typically, the initiator is the client-side host and the responder is
the server-side host. The roles are used by the state machine of a the server-side host. The roles are used by the state machine of a
HIP implementation, but discarded upon successful completion. HIP implementation, but discarded upon successful completion.
The exchange consists of four messages during which the hosts also The exchange consists of four messages during which the hosts also
create symmetric keys to protect the control plane with Hash-based create symmetric keys to protect the control plane with Hash-based
message authentication codes (HMACs). The keys can be also used to message authentication codes (HMACs). The keys can be also used to
protect the data plane, and IPsec ESP [I-D.ietf-hip-rfc5202-bis] is protect the data plane, and IPsec ESP [RFC7402] is typically used as
typically used as the data-plane protocol, albeit HIP can also the data-plane protocol, albeit HIP can also accommodate others.
accommodate others. Both the control and data plane are terminated Both the control and data plane are terminated using a closing
using a closing procedure consisting of two messages. procedure consisting of two messages.
In addition, the base exchange also includes a computational puzzle In addition, the base exchange also includes a computational puzzle
[I-D.ietf-hip-rfc5201-bis] that the initiator must solve. The [RFC7401] that the initiator must solve. The responder chooses the
responder chooses the difficulty of the puzzle which permits the difficulty of the puzzle which permits the responder to delay new
responder to delay new incoming initiators according to local incoming initiators according to local policies, for instance, when
policies, for instance, when the responder is under heavy load. The the responder is under heavy load. The puzzle can offer some
puzzle can offer some resiliency against DoS attacks because the resiliency against DoS attacks because the design of the puzzle
design of the puzzle mechanism allows the responder to remain mechanism allows the responder to remain stateless until the very end
stateless until the very end of the base exchange [aura-dos]. HIP of the base exchange [aura-dos]. HIP puzzles have also been studied
puzzles have also been studied under steady-state DDoS attacks under steady-state DDoS attacks [beal-dos], on multiple adversary
[beal-dos], on multiple adversary models with varying puzzle models with varying puzzle difficulties [tritilanunt-dos] and with
difficulties [tritilanunt-dos] and with ephemeral Host Identities ephemeral Host Identities [komu-mitigation].
[komu-mitigation].
6.2. End-host mobility and multi-homing 6.2. End-host mobility and multi-homing
HIP decouples the transport from the internetworking layer, and binds HIP decouples the transport from the internetworking layer, and binds
the transport associations to the Host Identities (actually through the transport associations to the Host Identities (actually through
either the HIT or LSI). After the initial key exchange, the HIP either the HIT or LSI). After the initial key exchange, the HIP
layer maintains transport-layer connectivity and data flows using its layer maintains transport-layer connectivity and data flows using its
mobility [I-D.ietf-hip-rfc5206-bis] and multihoming mobility [I-D.ietf-hip-rfc5206-bis] and multihoming
[I-D.ietf-hip-multihoming] extensions. Consequently, HIP can provide [I-D.ietf-hip-multihoming] extensions. Consequently, HIP can provide
for a degree of internetworking mobility and multi-homing at a low for a degree of internetworking mobility and multi-homing at a low
skipping to change at page 16, line 37 skipping to change at page 16, line 37
The HIP relay mechanism [I-D.ietf-hip-native-nat-traversal] is an The HIP relay mechanism [I-D.ietf-hip-native-nat-traversal] is an
alternative to the HIP rendezvous mechanism. The HIP relay mechanism alternative to the HIP rendezvous mechanism. The HIP relay mechanism
is more suitable for IPv4 networks with NATs because a HIP relay can is more suitable for IPv4 networks with NATs because a HIP relay can
forward all control and data plane communications in order to forward all control and data plane communications in order to
guarantee successful NAT traversal. guarantee successful NAT traversal.
6.5. Termination of the control plane 6.5. Termination of the control plane
The control plane between two hosts is terminated using a secure two The control plane between two hosts is terminated using a secure two
message exchange as specified in base exchange specification message exchange as specified in base exchange specification
[I-D.ietf-hip-rfc5201-bis]. The related state (i.e. host [RFC7401]. The related state (i.e. host associations) should be
associations) should be removed upon successful termination. removed upon successful termination.
7. Data plane 7. Data plane
The encapsulation format for the data plane used for carrying the The encapsulation format for the data plane used for carrying the
application-layer traffic can be dynamically negotiated during the application-layer traffic can be dynamically negotiated during the
key exchange. For instance, HICCUPS extensions [RFC6078] define one key exchange. For instance, HICCUPS extensions [RFC6078] define one
way to transport application-layer datagrams directly over the HIP way to transport application-layer datagrams directly over the HIP
control plane, protected by asymmetric key cryptography. Also, S-RTP control plane, protected by asymmetric key cryptography. Also, S-RTP
has been considered as the data encapsulation protocol [hip-srtp]. has been considered as the data encapsulation protocol [hip-srtp].
However, the most widely implemented method is the Encapsulated However, the most widely implemented method is the Encapsulated
Security Payload (ESP) [I-D.ietf-hip-rfc5202-bis] that is protected Security Payload (ESP) [RFC7402] that is protected by symmetric keys
by symmetric keys derived during the key exchange. ESP Security derived during the key exchange. ESP Security Associations (SAs)
Associations (SAs) offer both confidentiality and integrity offer both confidentiality and integrity protection, of which the
protection, of which the former can be disabled during the key former can be disabled during the key exchange. In the future, other
exchange. In the future, other ways of transporting application- ways of transporting application-layer data may be defined.
layer data may be defined.
The ESP SAs are established and terminated between the initiator and The ESP SAs are established and terminated between the initiator and
the responder hosts. Usually, the hosts create at least two SAs, one the responder hosts. Usually, the hosts create at least two SAs, one
in each direction (initiator-to-responder SA and responder-to- in each direction (initiator-to-responder SA and responder-to-
initiator SA). If the IP addresses of either host changes, the HIP initiator SA). If the IP addresses of either host changes, the HIP
mobility extensions can be used to re-negotiate the corresponding mobility extensions can be used to re-negotiate the corresponding
SAs. SAs.
On the wire, the difference in the use of identifiers between the HIP On the wire, the difference in the use of identifiers between the HIP
control and data plane is that the HITs are included in all control control and data plane is that the HITs are included in all control
skipping to change at page 27, line 31 skipping to change at page 27, line 52
cost of setting up a state for a protocol on the responder compared cost of setting up a state for a protocol on the responder compared
to the 'cheapness' on the initiator. HIP allows a responder to to the 'cheapness' on the initiator. HIP allows a responder to
increase the cost of the start of state on the initiator and makes an increase the cost of the start of state on the initiator and makes an
effort to reduce the cost to the responder. This is done by having effort to reduce the cost to the responder. This is done by having
the responder start the authenticated Diffie-Hellman exchange instead the responder start the authenticated Diffie-Hellman exchange instead
of the initiator, making the HIP base exchange 4 packets long. The of the initiator, making the HIP base exchange 4 packets long. The
first packet sent by the responder can be prebuilt to further first packet sent by the responder can be prebuilt to further
mitigate the costs. This packet also includes a computational puzzle mitigate the costs. This packet also includes a computational puzzle
that can optionally be used to further delay the initiator, for that can optionally be used to further delay the initiator, for
instance, when the responder is overloaded. The details are instance, when the responder is overloaded. The details are
explained in the base exchange specification explained in the base exchange specification [RFC7401].
[I-D.ietf-hip-rfc5201-bis].
Man-in-the-middle (MitM) attacks are difficult to defend against, Man-in-the-middle (MitM) attacks are difficult to defend against,
without third-party authentication. A skillful MitM could easily without third-party authentication. A skillful MitM could easily
handle all parts of the HIP base exchange, but HIP indirectly handle all parts of the HIP base exchange, but HIP indirectly
provides the following protection from a MitM attack. If the provides the following protection from a MitM attack. If the
responder's HI is retrieved from a signed DNS zone or securely responder's HI is retrieved from a signed DNS zone or securely
obtained by some other means, the initiator can use this to obtained by some other means, the initiator can use this to
authenticate the signed HIP packets. Likewise, if the initiator's HI authenticate the signed HIP packets. Likewise, if the initiator's HI
is in a secure DNS zone, the responder can retrieve it and validate is in a secure DNS zone, the responder can retrieve it and validate
the signed HIP packets. However, since an initiator may choose to the signed HIP packets. However, since an initiator may choose to
use an unpublished HI, it knowingly risks a MitM attack. The use an unpublished HI, it knowingly risks a MitM attack. The
responder may choose not to accept a HIP exchange with an initiator responder may choose not to accept a HIP exchange with an initiator
using an unknown HI. using an unknown HI.
Other types of MitM attacks against HIP can be mounted using ICMP Other types of MitM attacks against HIP can be mounted using ICMP
messages that can be used to signal about problems. As a overall messages that can be used to signal about problems. As a overall
guideline, the ICMP messages should be considered as unreliable guideline, the ICMP messages should be considered as unreliable
"hints" and should be acted upon only after timeouts. The exact "hints" and should be acted upon only after timeouts. The exact
attack scenarios and countermeasures are described in full detail the attack scenarios and countermeasures are described in full detail the
base exchange specification [I-D.ietf-hip-rfc5201-bis]. base exchange specification [RFC7401].
The need to support multiple hashes for generating the HIT from the The need to support multiple hashes for generating the HIT from the
HI affords the MitM to mount a potentially powerful downgrade attack HI affords the MitM to mount a potentially powerful downgrade attack
due to the a-priori need of the HIT in the HIP base exchange. The due to the a-priori need of the HIT in the HIP base exchange. The
base exchange has been augmented to deal with such an attack by base exchange has been augmented to deal with such an attack by
restarting on detecting the attack. At worst this would only lead to restarting on detecting the attack. At worst this would only lead to
a situation in which the base exchange would never finish (or would a situation in which the base exchange would never finish (or would
be aborted after some retries). As a drawback, this leads to an be aborted after some retries). As a drawback, this leads to an
6-way base exchange which may seem bad at first. However, since this 6-way base exchange which may seem bad at first. However, since this
only occurs in an attack scenario and since the attack can be handled only occurs in an attack scenario and since the attack can be handled
skipping to change at page 32, line 4 skipping to change at page 32, line 24
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, 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", draft-ietf-hip- with the Host Identity Protocol", draft-ietf-hip-
multihoming-03 (work in progress), July 2013. multihoming-05 (work in progress), January 2015.
[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", draft-ietf-hip-native-nat- the Host Identity Protocol", draft-ietf-hip-native-nat-
traversal-07 (work in progress), June 2014. traversal-08 (work in progress), January 2015.
[I-D.ietf-hip-rfc5201-bis]
Moskowitz, R., Heer, T., Jokela, P., and T. Henderson,
"Host Identity Protocol Version 2 (HIPv2)", draft-ietf-
hip-rfc5201-bis-19 (work in progress), September 2014.
[I-D.ietf-hip-rfc5202-bis]
Jokela, P., Moskowitz, R., and J. Melen, "Using the
Encapsulating Security Payload (ESP) Transport Format with
the Host Identity Protocol (HIP)", draft-ietf-hip-
rfc5202-bis-07 (work in progress), September 2014.
[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-06 Registration Extension", draft-ietf-hip-rfc5203-bis-06
(work in progress), September 2014. (work in progress), September 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-04 (work Rendezvous Extension", draft-ietf-hip-rfc5204-bis-04 (work
in progress), June 2014. in progress), June 2014.
skipping to change at page 33, line 8 skipping to change at page 33, line 18
(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", RFC [RFC5482] Eggert, L. and F. Gont, "TCP User Timeout Option", RFC
5482, March 2009. 5482, March 2009.
[RFC7343] Laganier, J. and F. Dupont, "An IPv6 Prefix for Overlay
Routable Cryptographic Hash Identifiers Version 2
(ORCHIDv2)", RFC 7343, September 2014.
[RFC7401] Moskowitz, R., Heer, T., Jokela, P., and T. Henderson,
"Host Identity Protocol Version 2 (HIPv2)", RFC 7401,
April 2015.
[RFC7402] Jokela, P., Moskowitz, R., and J. Melen, "Using the
Encapsulating Security Payload (ESP) Transport Format with
the Host Identity Protocol (HIP)", RFC 7402, April 2015.
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, September Area Networks (WPANs)", IEEE Standard 802.15.4, September
2011, <http://standards.ieee.org/getieee802/download/ 2011, <http://standards.ieee.org/getieee802/download/
skipping to change at page 39, line 16 skipping to change at page 39, line 37
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
Miika Komu Miika Komu
Aalto University Ericsson
Konemiehentie 2 Hirsalantie 11
Espoo 02420 Jorvas
Finland Finland
Email: miika.komu@aalto.fi Email: miika.komu@ericsson.com
 End of changes. 28 change blocks. 
84 lines changed or deleted 81 lines changed or added

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