draft-ietf-hip-rfc4423-bis-18.txt   draft-ietf-hip-rfc4423-bis-19.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: May 27, 2018 November 23, 2017 Expires: August 31, 2018 February 27, 2018
Host Identity Protocol Architecture Host Identity Protocol Architecture
draft-ietf-hip-rfc4423-bis-18 draft-ietf-hip-rfc4423-bis-19
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 May 27, 2018. This Internet-Draft will expire on August 31, 2018.
Copyright Notice Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the Copyright (c) 2018 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 41 skipping to change at page 2, line 41
3.1. A desire for a namespace for computing platforms . . . . . 7 3.1. A desire for a namespace for computing platforms . . . . . 7
4. Host Identity namespace . . . . . . . . . . . . . . . . . . . 9 4. Host Identity namespace . . . . . . . . . . . . . . . . . . . 9
4.1. Host Identifiers . . . . . . . . . . . . . . . . . . . . . 10 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) . . . . . . . . . . . . . . . . . . 11 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 . . . . . . . . . . . . . . . . . . . 13 5. New stack architecture . . . . . . . . . . . . . . . . . . . 13
5.1. On the multiplicity of identities . . . . . . . . . . . . . 14 5.1. On the multiplicity of identities . . . . . . . . . . . . . 14
6. Control plane . . . . . . . . . . . . . . . . . . . . . . . . 15 6. Control plane . . . . . . . . . . . . . . . . . . . . . . . . 15
6.1. Base exchange . . . . . . . . . . . . . . . . . . . . . . . 15 6.1. Base exchange . . . . . . . . . . . . . . . . . . . . . . . 16
6.2. End-host mobility and multi-homing . . . . . . . . . . . . 16 6.2. End-host mobility and multi-homing . . . . . . . . . . . . 16
6.3. Rendezvous mechanism . . . . . . . . . . . . . . . . . . . 16 6.3. Rendezvous mechanism . . . . . . . . . . . . . . . . . . . 17
6.4. Relay mechanism . . . . . . . . . . . . . . . . . . . . . . 17 6.4. Relay mechanism . . . . . . . . . . . . . . . . . . . . . . 17
6.5. Termination of the control plane . . . . . . . . . . . . . 17 6.5. Termination of the control plane . . . . . . . . . . . . . 18
7. Data plane . . . . . . . . . . . . . . . . . . . . . . . . . 17 7. Data plane . . . . . . . . . . . . . . . . . . . . . . . . . 18
8. HIP and NATs . . . . . . . . . . . . . . . . . . . . . . . . 18 8. HIP and NATs . . . . . . . . . . . . . . . . . . . . . . . . 19
8.1. HIP and Upper-layer checksums . . . . . . . . . . . . . . . 19 8.1. HIP and Upper-layer checksums . . . . . . . . . . . . . . . 19
9. Multicast . . . . . . . . . . . . . . . . . . . . . . . . . . 19 9. Multicast . . . . . . . . . . . . . . . . . . . . . . . . . . 20
10. HIP policies . . . . . . . . . . . . . . . . . . . . . . . . 19 10. HIP policies . . . . . . . . . . . . . . . . . . . . . . . . 20
11. Design considerations . . . . . . . . . . . . . . . . . . . . 20 11. Design considerations . . . . . . . . . . . . . . . . . . . . 21
11.1. Benefits of HIP . . . . . . . . . . . . . . . . . . . . . 20 11.1. Benefits of HIP . . . . . . . . . . . . . . . . . . . . . 21
11.2. Drawbacks of HIP . . . . . . . . . . . . . . . . . . . . . 23 11.2. Drawbacks of HIP . . . . . . . . . . . . . . . . . . . . . 24
11.3. Deployment and adoption considerations . . . . . . . . . . 24 11.3. Deployment and adoption considerations . . . . . . . . . . 25
11.3.1. Deployment analysis . . . . . . . . . . . . . . . . . . 24 11.3.1. Deployment analysis . . . . . . . . . . . . . . . . . . 25
11.3.2. HIP in 802.15.4 networks . . . . . . . . . . . . . . . . 25 11.3.2. HIP in 802.15.4 networks . . . . . . . . . . . . . . . . 26
11.3.3. HIP and Internet of Things . . . . . . . . . . . . . . . 26 11.3.3. HIP and Internet of Things . . . . . . . . . . . . . . . 26
11.4. Answers to NSRG questions . . . . . . . . . . . . . . . . 27 11.4. Answers to NSRG questions . . . . . . . . . . . . . . . . 28
12. Security considerations . . . . . . . . . . . . . . . . . . . 29 12. Security considerations . . . . . . . . . . . . . . . . . . . 29
12.1. MiTM Attacks . . . . . . . . . . . . . . . . . . . . . . . 29 12.1. MiTM Attacks . . . . . . . . . . . . . . . . . . . . . . . 29
12.2. Protection against flooding attacks . . . . . . . . . . . 30 12.2. Protection against flooding attacks . . . . . . . . . . . 31
12.3. HITs used in ACLs . . . . . . . . . . . . . . . . . . . . 31 12.3. HITs used in ACLs . . . . . . . . . . . . . . . . . . . . 31
12.4. Alternative HI considerations . . . . . . . . . . . . . . 32 12.4. Alternative HI considerations . . . . . . . . . . . . . . 33
13. IANA considerations . . . . . . . . . . . . . . . . . . . . . 33 13. IANA considerations . . . . . . . . . . . . . . . . . . . . . 33
14. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 33 14. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 33
15. Changes from RFC 4423 . . . . . . . . . . . . . . . . . . . . 33 15. Changes from RFC 4423 . . . . . . . . . . . . . . . . . . . . 34
16. References . . . . . . . . . . . . . . . . . . . . . . . . . 34 16. References . . . . . . . . . . . . . . . . . . . . . . . . . 34
16.1. Normative References . . . . . . . . . . . . . . . . . . . 34 16.1. Normative References . . . . . . . . . . . . . . . . . . . 34
16.2. Informative references . . . . . . . . . . . . . . . . . . 35 16.2. Informative references . . . . . . . . . . . . . . . . . . 35
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 42 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
skipping to change at page 6, line 17 skipping to change at page 6, line 17
+---------------+---------------------------------------------------+ +---------------+---------------------------------------------------+
| Computing | An entity capable of communicating and computing, | | Computing | An entity capable of communicating and computing, |
| platform | for example, a computer. See the definition of | | platform | for example, a computer. See the definition of |
| | 'End-point', above. | | | 'End-point', above. |
| HIP base | A cryptographic protocol; see also Section 6. | | HIP base | A cryptographic protocol; see also Section 6. |
| exchange | | | exchange | |
| HIP packet | An IP packet that carries a 'Host Identity | | HIP packet | An IP packet that carries a 'Host Identity |
| | Protocol' message. | | | Protocol' message. |
| Host Identity | An abstract concept assigned to a 'computing | | Host Identity | An abstract concept assigned to a 'computing |
| | platform'. See 'Host Identifier', below. | | | platform'. See 'Host Identifier', below. |
| Host | A public key used as a name for a Host Identity. |
| Identifier | |
| Host Identity | A name space formed by all possible Host | | Host Identity | A name space formed by all possible Host |
| namespace | Identifiers. | | namespace | Identifiers. |
| Host Identity | A protocol used to carry and authenticate Host | | Host Identity | A protocol used to carry and authenticate Host |
| Protocol | Identifiers and other information. | | Protocol | Identifiers and other information. |
| Host Identity | The cryptographic hash used in creating the Host | | Host Identity | The cryptographic hash used in creating the Host |
| Hash | Identity Tag from the Host Identity. | | Hash | Identity Tag from the Host Identifier. |
| Host Identity | A 128-bit datum created by taking a cryptographic | | Host Identity | A 128-bit datum created by taking a cryptographic |
| Tag | hash over a Host Identifier plus bits to identify | | Tag | hash over a Host Identifier plus bits to identify |
| | which hash used. | | | which hash used. |
| Host | A public key used as a name for a Host Identity. |
| Identifier | |
| Local Scope | A 32-bit datum denoting a Host Identity. | | Local Scope | A 32-bit datum denoting a Host Identity. |
| Identifier | | | Identifier | |
| Public Host | A published or publicly known Host Identifier | | Public Host | A published or publicly known Host Identifier |
| Identifier | used as a public name for a Host Identity, and | | Identifier | used as a public name for a Host Identity, and |
| and Identity | the corresponding Identity. | | and Identity | the corresponding Identity. |
| Unpublished | A Host Identifier that is not placed in any | | Unpublished | A Host Identifier that is not placed in any |
| Host | public directory, and the corresponding Host | | Host | public directory, and the corresponding Host |
| Identifier | Identity. Unpublished Host Identities are | | Identifier | Identity. Unpublished Host Identities are |
| and Identity | typically short lived in nature, being often | | and Identity | typically short lived in nature, being often |
| | replaced and possibly used just once. | | | replaced and possibly used just once. |
skipping to change at page 10, line 15 skipping to change at page 10, line 15
4.1. Host Identifiers 4.1. Host Identifiers
Host Identity adds two main features to Internet protocols. The Host Identity adds two main features to Internet protocols. The
first is a decoupling of the internetworking and transport layers; first is a decoupling of the internetworking and transport layers;
see Section 5. This decoupling will allow for independent evolution see Section 5. This decoupling will allow for independent evolution
of the two layers. Additionally, it can provide end-to-end services of the two layers. Additionally, it can provide end-to-end services
over multiple internetworking realms. The second feature is host over multiple internetworking realms. The second feature is host
authentication. Because the Host Identifier is a public key, this authentication. Because the Host Identifier is a public key, this
key can be used for authentication in security protocols like ESP. key can be used for authentication in security protocols like ESP.
The only completely defined structure of the Host Identity is that of An identity is based on public-private key cryptography in HIP. The
a public/private key pair. In this case, the Host Identity is Host Identity is referred to by its public component, the public key.
referred to by its public component, the public key. Thus, the name Thus, the name representing a Host Identity in the Host Identity
representing a Host Identity in the Host Identity namespace, i.e., namespace, i.e., the Host Identifier, is the public key. In a way,
the Host Identifier, is the public key. In a way, the possession of the possession of the private key defines the Identity itself. If
the private key defines the Identity itself. If the private key is the private key is possessed by more than one node, the Identity can
possessed by more than one node, the Identity can be considered to be be considered to be a distributed one.
a distributed one.
Architecturally, any other Internet naming convention might form a Architecturally, any other Internet naming convention might form a
usable base for Host Identifiers. However, non-cryptographic names usable base for Host Identifiers. However, non-cryptographic names
should only be used in situations of high trust - low risk. That is should only be used in situations of high trust - low risk. That is
any place where host authentication is not needed (no risk of host any place where host authentication is not needed (no risk of host
spoofing) and no use of ESP. However, at least for interconnected spoofing) and no use of ESP. However, at least for interconnected
networks spanning several operational domains, the set of networks spanning several operational domains, the set of
environments where the risk of host spoofing allowed by non- environments where the risk of host spoofing allowed by non-
cryptographic Host Identifiers is acceptable is the null set. Hence, cryptographic Host Identifiers is acceptable is the null set. Hence,
the current HIP documents do not specify how to use any other types the current HIP documents do not specify how to use any other types
skipping to change at page 10, line 50 skipping to change at page 10, line 49
elsewhere in this document, and they are passed in the HIP base elsewhere in this document, and they are passed in the HIP base
exchange. A Host Identity Tag (HIT) is used in other protocols to exchange. A Host Identity Tag (HIT) is used in other protocols to
represent the Host Identity. Another representation of the Host represent the Host Identity. Another representation of the Host
Identities, the Local Scope Identifier (LSI), can also be used in Identities, the Local Scope Identifier (LSI), can also be used in
protocols and APIs. protocols and APIs.
4.2. Host Identity Hash (HIH) 4.2. Host Identity Hash (HIH)
The Host Identity Hash is the cryptographic hash algorithm used in The Host Identity Hash is the cryptographic hash algorithm used in
producing the HIT from the HI. It is also the hash used 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 for
for the two hosts in the HIP exchange to use different hash 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 [RFC7401]. downgrade attack that is mitigated in the HIP protocol [RFC7401].
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, an IPv6 prefix [RFC7343] and a hash Due to its size, it is suitable to be used in the existing sockets
identifier. There are two advantages of using the HIT over using the API in the place of IPv6 addresses (e.g. in sockaddr_in6 structure,
Host Identifier in protocols. Firstly, its fixed length makes for sin6_addr member) without modifying applications. It is created from
easier protocol coding and also better manages the packet size cost an HIH, an IPv6 prefix [RFC7343] and a hash identifier. There are
of this technology. Secondly, it presents the identity in a two advantages of using the HIT over using the Host Identifier in
consistent format to the protocol independent of the cryptographic protocols. Firstly, its fixed length makes for easier protocol
algorithms used. coding and also better manages the packet size cost of this
technology. Secondly, it presents the identity in a consistent
format to the protocol independent of the cryptographic algorithms
used.
In essence, the HIT is a hash over the public key. As such, two In essence, the HIT is a hash over the public key. As such, two
algorithms affect the generation of a HIT: the public-key algorithm algorithms affect the generation of a HIT: the public-key algorithm
of the HI and the used HIH. The two algorithms are encoded in the of the HI and the used HIH. The two algorithms are encoded in the
bit presentation of the HIT. As the two communicating parties may bit presentation of the HIT. As the two communicating parties may
support different algorithms, [RFC7401] defines the minimum set for support different algorithms, [RFC7401] defines the minimum set for
interoperability. For further interoperability, the responder may interoperability. For further interoperability, the responder may
store its keys in DNS records, and thus the initiator may have to store its keys in DNS records, and thus the initiator may have to
couple destination HITs with appropriate source HITs according to couple destination HITs with appropriate source HITs according to
matching HIH. matching HIH.
skipping to change at page 11, line 41 skipping to change at page 11, line 44
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)
An LSI is a 32-bit localized representation for a Host Identity. The An LSI is a 32-bit localized representation for a Host Identity. Due
purpose of an LSI is to facilitate using Host Identities in existing to its size, it is suitable to be used in the existing sockets API in
APIs for IPv4-based applications. Besides facilitating HIP-based the place of IPv4 addresses (e.g. in sockaddr_in structure, sin_addr
member) without modifying applications. The purpose of an LSI is to
facilitate using Host Identities in existing APIs for IPv4-based
applications. LSIs are never transmitted on the wire; when an
application sends data using a pair of LSIs, the HIP layer (or
sockets handler) translates the LSIs to the corresponding HITs, and
vice versa for receiving of data. Besides facilitating HIP-based
connectivity for legacy IPv4 applications, the LSIs are beneficial in connectivity for legacy IPv4 applications, the LSIs are beneficial in
two other scenarios [RFC6538]. two other scenarios [RFC6538].
In the first scenario, two IPv4-only applications are residing on two In the first scenario, two IPv4-only applications are residing on two
separate hosts connected by IPv6-only network. With HIP-based separate hosts connected by IPv6-only network. With HIP-based
connectivity, the two applications are able to communicate despite of connectivity, the two applications are able to communicate despite of
the mismatch in the protocol families of the applications and the the mismatch in the protocol families of the applications and the
underlying network. The reason is that the HIP layer translates the underlying network. The reason is that the HIP layer translates the
LSIs originating from the upper layers into routable IPv6 locators LSIs originating from the upper layers into routable IPv6 locators
before delivering the packets on the wire. before delivering the packets on the wire.
skipping to change at page 14, line 27 skipping to change at page 14, line 27
Figure 1 Figure 1
Architecturally, HIP provides for a different binding of transport- Architecturally, HIP provides for a different binding of transport-
layer protocols. That is, the transport-layer associations, i.e., layer protocols. That is, the transport-layer associations, i.e.,
TCP connections and UDP associations, are no longer bound to IP TCP connections and UDP associations, are no longer bound to IP
addresses but rather to Host Identities. In practice, the Host addresses but rather to Host Identities. In practice, the Host
Identities are exposed as LSIs and HITs for legacy applications and Identities are exposed as LSIs and HITs for legacy applications and
the transport layer to facilitate backward compatibility with the transport layer to facilitate backward compatibility with
existing networking APIs and stacks. existing networking APIs and stacks.
HIP layer is logically located at layer 3.5, between the transport
and network layers, in the networking stack. It acts as shim layer
for transport data utilizing LSIs or HITs, but leaves other data
intact. HIP layer translates between the two forms of HIP
identifiers originating from the transport layer into routable IPv4/
IPv6 addresses for the network layer, and vice versa for the reverse
direction.
5.1. On the multiplicity of identities 5.1. On the multiplicity of identities
A host may have multiple identities both at the client and server A host may have multiple identities both at the client and server
side. This raises some additional concerns that are addressed in side. This raises some additional concerns that are addressed in
this section. this section.
For security reasons, it may be a bad idea to duplicate the same Host For security reasons, it may be a bad idea to duplicate the same Host
Identity on multiple hosts because the compromise of a single host Identity on multiple hosts because the compromise of a single host
taints the identities of the other hosts. Management of machines taints the identities of the other hosts. Management of machines
with identical Host Identities may also present other challenges and, with identical Host Identities may also present other challenges and,
therefore, it is advisable to have a unique identity for each host. therefore, it is advisable to have a unique identity for each host.
At the server side, utilizing DNS is a better alternative than a
shared Host Identity to implement load balancing. A single FQDN
entry can be configured to refer to multiple Host Identities. Each
of the FQDN entries can be associated with the related locators, or a
single shared locator in the case the servers are using the same HIP
rendezvous server Section 6.3 or HIP relay server Section 6.4.
Instead of duplicating identities, HIP opportunistic mode can be Instead of duplicating identities, HIP opportunistic mode can be
employed, where the initiator leaves out the identifier of the employed, where the initiator leaves out the identifier of the
responder when initiating the key exchange and learns it upon the responder when initiating the key exchange and learns it upon the
completion of the exchange. The tradeoffs are related to lowered completion of the exchange. The tradeoffs are related to lowered
security guarantees, but a benefit of the approach is to avoid security guarantees, but a benefit of the approach is to avoid
publishing of Host Identifiers in any directories [komu-leap]. The publishing of Host Identifiers in any directories [komu-leap]. Since
approach could also be used for load balancing purposes at the HIP many public servers already employ DNS as their directory,
layer because the identity of the responder can be decided opportunistic mode may be more suitable for, e.g, peer-to-peer
dynamically during the key exchange. Thus, the approach has the connectivity.
potential to be used as a HIP-layer "anycast", either directly
between two hosts or indirectly through the rendezvous service HIP opportunistic mode could be utilized in association with HIP
[komu-diss]. rendezvous servers or HIP relay servers [komu-diss]. In such a
scenario, the Initiator sends an I1 message with a wildcard
destination HIT to the locator of a HIP rendezvous/relay server.
When the receiving rendezvous/relay server is serving multiple
registered Responders, the server can choose the ultimate destination
HIT, thus acting as a HIP based load balancer. However, this
approach is still experimental and requires further investigation.
At the client side, a host may have multiple Host Identities, for At the client side, a host may have multiple Host Identities, for
instance, for privacy purposes. Another reason can be that the instance, for privacy purposes. Another reason can be that the
person utilizing the host employs different identities for different person utilizing the host employs different identities for different
administrative domains as an extra security measure. If a HIP-aware administrative domains as an extra security measure. If a HIP-aware
middlebox, such as a HIP-based firewall, is on the path between the middlebox, such as a HIP-based firewall, is on the path between the
client and server, the user or the underlying system should carefully client and server, the user or the underlying system should carefully
choose the correct identity to avoid the firewall to unnecessarily choose the correct identity to avoid the firewall to unnecessarily
drop HIP-base connectivity [komu-diss]. drop HIP-based connectivity [komu-diss].
Similarly, a server may have multiple Host Identities. For instance, Similarly, a server may have multiple Host Identities. For instance,
a single web server may serve multiple different administrative a single web server may serve multiple different administrative
domains. Typically, the distinction is accomplished based on the DNS domains. Typically, the distinction is accomplished based on the DNS
name, but also the Host Identity could be used for this purpose. name, but also the Host Identity could be used for this purpose.
However, a more compelling reason to employ multiple identities are However, a more compelling reason to employ multiple identities are
HIP-aware firewalls that are unable see the HTTP traffic inside the HIP-aware firewalls that are unable see the HTTP traffic inside the
encrypted IPsec tunnel. In such a case, each service could be encrypted IPsec tunnel. In such a case, each service could be
configured with a separate identity, thus allowing the firewall to configured with a separate identity, thus allowing the firewall to
segregate the different services of the single web server from each segregate the different services of the single web server from each
skipping to change at page 34, line 11 skipping to change at page 34, line 41
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, HIP for IoT scenarios, deployment 802.15.4 and MAC security, HIP for IoT scenarios, deployment
considerations and description 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] [I-D.ietf-hip-dex]
Moskowitz, R. and R. Hummen, "HIP Diet EXchange (DEX)", Moskowitz, R. and R. Hummen, "HIP Diet EXchange (DEX)",
draft-ietf-hip-dex-05 (work in progress), February 2017. draft-ietf-hip-dex-06 (work in progress), December 2017.
[I-D.ietf-hip-native-nat-traversal] [I-D.ietf-hip-native-nat-traversal]
Keranen, A., Melen, J., and M. Komu, "Native NAT Traversal Keranen, A., Melen, J., and M. Komu, "Native NAT Traversal
Mode for the Host Identity Protocol", draft-ietf-hip- Mode for the Host Identity Protocol", draft-ietf-hip-
native-nat-traversal-23 (work in progress), November 2017. native-nat-traversal-27 (work in progress), December 2017.
[RFC5482] Eggert, L. and F. Gont, "TCP User Timeout Option", [RFC5482] Eggert, L. and F. Gont, "TCP User Timeout Option",
RFC 5482, DOI 10.17487/RFC5482, March 2009, RFC 5482, DOI 10.17487/RFC5482, March 2009,
<https://www.rfc-editor.org/info/rfc5482>. <https://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, <https://www.rfc-editor.org/info/rfc7343>. 2014, <https://www.rfc-editor.org/info/rfc7343>.
 End of changes. 25 change blocks. 
55 lines changed or deleted 83 lines changed or added

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