--- 1/draft-ietf-hip-rfc4423-bis-18.txt 2018-02-27 04:13:55.147855730 -0800 +++ 2/draft-ietf-hip-rfc4423-bis-19.txt 2018-02-27 04:13:55.239857899 -0800 @@ -1,19 +1,19 @@ Network Working Group R. Moskowitz, Ed. Internet-Draft HTT Consulting Obsoletes: 4423 (if approved) M. Komu Intended status: Informational Ericsson -Expires: May 27, 2018 November 23, 2017 +Expires: August 31, 2018 February 27, 2018 Host Identity Protocol Architecture - draft-ietf-hip-rfc4423-bis-18 + draft-ietf-hip-rfc4423-bis-19 Abstract This memo describes a new namespace, the Host Identity namespace, and a new protocol layer, the Host Identity Protocol, between the internetworking and transport layers. Herein are presented the basics of the current namespaces, their strengths and weaknesses, and how a new namespace will add completeness to them. The roles of this new namespace in the protocols are defined. @@ -30,25 +30,25 @@ Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference 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 (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. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as @@ -76,46 +76,46 @@ 3.1. A desire for a namespace for computing platforms . . . . . 7 4. Host Identity namespace . . . . . . . . . . . . . . . . . . . 9 4.1. Host Identifiers . . . . . . . . . . . . . . . . . . . . . 10 4.2. Host Identity Hash (HIH) . . . . . . . . . . . . . . . . . 10 4.3. Host Identity Tag (HIT) . . . . . . . . . . . . . . . . . . 11 4.4. Local Scope Identifier (LSI) . . . . . . . . . . . . . . . 11 4.5. Storing Host Identifiers in directories . . . . . . . . . . 12 5. New stack architecture . . . . . . . . . . . . . . . . . . . 13 5.1. On the multiplicity of identities . . . . . . . . . . . . . 14 6. Control plane . . . . . . . . . . . . . . . . . . . . . . . . 15 - 6.1. Base exchange . . . . . . . . . . . . . . . . . . . . . . . 15 + 6.1. Base exchange . . . . . . . . . . . . . . . . . . . . . . . 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.5. Termination of the control plane . . . . . . . . . . . . . 17 - 7. Data plane . . . . . . . . . . . . . . . . . . . . . . . . . 17 - 8. HIP and NATs . . . . . . . . . . . . . . . . . . . . . . . . 18 + 6.5. Termination of the control plane . . . . . . . . . . . . . 18 + 7. Data plane . . . . . . . . . . . . . . . . . . . . . . . . . 18 + 8. HIP and NATs . . . . . . . . . . . . . . . . . . . . . . . . 19 8.1. HIP and Upper-layer checksums . . . . . . . . . . . . . . . 19 - 9. Multicast . . . . . . . . . . . . . . . . . . . . . . . . . . 19 - 10. HIP policies . . . . . . . . . . . . . . . . . . . . . . . . 19 - 11. Design considerations . . . . . . . . . . . . . . . . . . . . 20 - 11.1. Benefits of HIP . . . . . . . . . . . . . . . . . . . . . 20 - 11.2. Drawbacks of HIP . . . . . . . . . . . . . . . . . . . . . 23 - 11.3. Deployment and adoption considerations . . . . . . . . . . 24 - 11.3.1. Deployment analysis . . . . . . . . . . . . . . . . . . 24 - 11.3.2. HIP in 802.15.4 networks . . . . . . . . . . . . . . . . 25 + 9. Multicast . . . . . . . . . . . . . . . . . . . . . . . . . . 20 + 10. HIP policies . . . . . . . . . . . . . . . . . . . . . . . . 20 + 11. Design considerations . . . . . . . . . . . . . . . . . . . . 21 + 11.1. Benefits of HIP . . . . . . . . . . . . . . . . . . . . . 21 + 11.2. Drawbacks of HIP . . . . . . . . . . . . . . . . . . . . . 24 + 11.3. Deployment and adoption considerations . . . . . . . . . . 25 + 11.3.1. Deployment analysis . . . . . . . . . . . . . . . . . . 25 + 11.3.2. HIP in 802.15.4 networks . . . . . . . . . . . . . . . . 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.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.4. Alternative HI considerations . . . . . . . . . . . . . . 32 + 12.4. Alternative HI considerations . . . . . . . . . . . . . . 33 13. IANA considerations . . . . . . . . . . . . . . . . . . . . . 33 14. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 33 - 15. Changes from RFC 4423 . . . . . . . . . . . . . . . . . . . . 33 + 15. Changes from RFC 4423 . . . . . . . . . . . . . . . . . . . . 34 16. References . . . . . . . . . . . . . . . . . . . . . . . . . 34 16.1. Normative References . . . . . . . . . . . . . . . . . . . 34 16.2. Informative references . . . . . . . . . . . . . . . . . . 35 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 42 1. Introduction The Internet has two important global namespaces: Internet Protocol (IP) addresses and Domain Name Service (DNS) names. These two namespaces have a set of features and abstractions that have powered @@ -210,31 +210,31 @@ +---------------+---------------------------------------------------+ | Computing | An entity capable of communicating and computing, | | platform | for example, a computer. See the definition of | | | 'End-point', above. | | HIP base | A cryptographic protocol; see also Section 6. | | exchange | | | HIP packet | An IP packet that carries a 'Host Identity | | | Protocol' message. | | Host Identity | An abstract concept assigned to a 'computing | | | 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 | | namespace | Identifiers. | | Host Identity | A protocol used to carry and authenticate Host | | Protocol | Identifiers and other information. | | 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 | | Tag | hash over a Host Identifier plus bits to identify | | | 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. | | Identifier | | | Public Host | A published or publicly known Host Identifier | | Identifier | used as a public name for a Host Identity, and | | and Identity | the corresponding Identity. | | Unpublished | A Host Identifier that is not placed in any | | Host | public directory, and the corresponding Host | | Identifier | Identity. Unpublished Host Identities are | | and Identity | typically short lived in nature, being often | | | replaced and possibly used just once. | @@ -395,28 +395,27 @@ 4.1. Host Identifiers Host Identity adds two main features to Internet protocols. The first is a decoupling of the internetworking and transport layers; see Section 5. This decoupling will allow for independent evolution of the two layers. Additionally, it can provide end-to-end services over multiple internetworking realms. The second feature is host authentication. Because the Host Identifier is a public key, this key can be used for authentication in security protocols like ESP. - The only completely defined structure of the Host Identity is that of - a public/private key pair. In this case, the Host Identity is - referred to by its public component, the public key. Thus, the name - representing a Host Identity in the Host Identity namespace, i.e., - the Host Identifier, is the public key. In a way, the possession of - the private key defines the Identity itself. If the private key is - possessed by more than one node, the Identity can be considered to be - a distributed one. + An identity is based on public-private key cryptography in HIP. The + Host Identity is referred to by its public component, the public key. + Thus, the name representing a Host Identity in the Host Identity + namespace, i.e., the Host Identifier, is the public key. In a way, + the possession of the private key defines the Identity itself. If + the private key is possessed by more than one node, the Identity can + be considered to be a distributed one. Architecturally, any other Internet naming convention might form a usable base for Host Identifiers. However, non-cryptographic names 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 spoofing) and no use of ESP. However, at least for interconnected networks spanning several operational domains, the set of environments where the risk of host spoofing allowed by non- cryptographic Host Identifiers is acceptable is the null set. Hence, the current HIP documents do not specify how to use any other types @@ -430,39 +429,41 @@ elsewhere in this document, and they are passed in the HIP base exchange. A Host Identity Tag (HIT) is used in other protocols to represent the Host Identity. Another representation of the Host Identities, the Local Scope Identifier (LSI), can also be used in protocols and APIs. 4.2. Host Identity Hash (HIH) The Host Identity Hash is the cryptographic hash algorithm used in producing the HIT from the HI. It is also the hash used throughout - the HIP protocol for consistency and simplicity. It is possible to - for the two hosts in the HIP exchange to use different hash - algorithms. + the HIP protocol for consistency and simplicity. It is possible for + the two hosts in the HIP exchange to use different hash algorithms. Multiple HIHs within HIP are needed to address the moving target of creation and eventual compromise of cryptographic hashes. This significantly complicates HIP and offers an attacker an additional downgrade attack that is mitigated in the HIP protocol [RFC7401]. 4.3. Host Identity Tag (HIT) 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 - identifier. There are two advantages of using the HIT over using the - Host Identifier in protocols. Firstly, its fixed length makes for - easier protocol 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. + Due to its size, it is suitable to be used in the existing sockets + API in the place of IPv6 addresses (e.g. in sockaddr_in6 structure, + sin6_addr member) without modifying applications. It is created from + an HIH, an IPv6 prefix [RFC7343] and a hash identifier. There are + two advantages of using the HIT over using the Host Identifier in + protocols. Firstly, its fixed length makes for easier protocol + 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 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 bit presentation of the HIT. As the two communicating parties may support different algorithms, [RFC7401] defines the minimum set for interoperability. For further interoperability, the responder may store its keys in DNS records, and thus the initiator may have to couple destination HITs with appropriate source HITs according to matching HIH. @@ -470,23 +471,29 @@ In the HIP packets, the HITs identify the sender and recipient of a 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 a single HIT mapping to more than one Host Identity, the Host 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 for the correct public key to use. 4.4. Local Scope Identifier (LSI) - An LSI is a 32-bit localized representation for a Host Identity. The - purpose of an LSI is to facilitate using Host Identities in existing - APIs for IPv4-based applications. Besides facilitating HIP-based + An LSI is a 32-bit localized representation for a Host Identity. Due + to its size, it is suitable to be used in the existing sockets API in + 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 two other scenarios [RFC6538]. In the first scenario, two IPv4-only applications are residing on two separate hosts connected by IPv6-only network. With HIP-based connectivity, the two applications are able to communicate despite of the mismatch in the protocol families of the applications and the underlying network. The reason is that the HIP layer translates the LSIs originating from the upper layers into routable IPv6 locators before delivering the packets on the wire. @@ -587,53 +594,74 @@ Figure 1 Architecturally, HIP provides for a different binding of transport- layer protocols. That is, the transport-layer associations, i.e., TCP connections and UDP associations, are no longer bound to IP addresses but rather to Host Identities. In practice, the Host Identities are exposed as LSIs and HITs for legacy applications and the transport layer to facilitate backward compatibility with 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 A host may have multiple identities both at the client and server side. This raises some additional concerns that are addressed in this section. 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 taints the identities of the other hosts. Management of machines with identical Host Identities may also present other challenges and, 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 employed, where the initiator leaves out the identifier of the responder when initiating the key exchange and learns it upon the completion of the exchange. The tradeoffs are related to lowered security guarantees, but a benefit of the approach is to avoid - publishing of Host Identifiers in any directories [komu-leap]. The - approach could also be used for load balancing purposes at the HIP - layer because the identity of the responder can be decided - dynamically during the key exchange. Thus, the approach has the - potential to be used as a HIP-layer "anycast", either directly - between two hosts or indirectly through the rendezvous service - [komu-diss]. + publishing of Host Identifiers in any directories [komu-leap]. Since + many public servers already employ DNS as their directory, + opportunistic mode may be more suitable for, e.g, peer-to-peer + connectivity. + + HIP opportunistic mode could be utilized in association with HIP + 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 instance, for privacy purposes. Another reason can be that the person utilizing the host employs different identities for different administrative domains as an extra security measure. If a HIP-aware middlebox, such as a HIP-based firewall, is on the path between the client and server, the user or the underlying system should carefully 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, a single web server may serve multiple different administrative domains. Typically, the distinction is accomplished based on the DNS name, but also the Host Identity could be used for this purpose. However, a more compelling reason to employ multiple identities are HIP-aware firewalls that are unable see the HTTP traffic inside the encrypted IPsec tunnel. In such a case, each service could be configured with a separate identity, thus allowing the firewall to segregate the different services of the single web server from each @@ -1528,26 +1555,26 @@ also added. New topics include the drawbacks of HIP, discussion on 802.15.4 and MAC security, HIP for IoT scenarios, deployment considerations and description of the base exchange. 16. References 16.1. Normative References [I-D.ietf-hip-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] Keranen, A., Melen, J., and M. Komu, "Native NAT Traversal 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", RFC 5482, DOI 10.17487/RFC5482, March 2009, . [RFC7343] Laganier, J. and F. Dupont, "An IPv6 Prefix for Overlay Routable Cryptographic Hash Identifiers Version 2 (ORCHIDv2)", RFC 7343, DOI 10.17487/RFC7343, September 2014, .