rfc9063v3.txt   rfc9063.txt 
Internet Engineering Task Force (IETF) R. Moskowitz, Ed. Internet Engineering Task Force (IETF) R. Moskowitz, Ed.
Request for Comments: 9063 HTT Consulting Request for Comments: 9063 HTT Consulting
Obsoletes: 4423 M. Komu Obsoletes: 4423 M. Komu
Category: Informational Ericsson Category: Informational Ericsson
ISSN: 2070-1721 June 2021 ISSN: 2070-1721 July 2021
Host Identity Protocol Architecture Host Identity Protocol Architecture
Abstract Abstract
This memo describes the Host Identity (HI) namespace, which provides This memo describes the Host Identity (HI) namespace, which provides
a cryptographic namespace to applications, and the associated a cryptographic namespace to applications, and the associated
protocol layer, the Host Identity Protocol, located between the protocol layer, the Host Identity Protocol, located between the
internetworking and transport layers, that supports end-host internetworking and transport layers, that supports end-host
mobility, multihoming, and NAT traversal. Herein are presented the mobility, multihoming, and NAT traversal. Herein are presented the
skipping to change at line 932 skipping to change at line 932
upper-layer checksums in the NAT/NAT-PT system, since the traffic is upper-layer checksums in the NAT/NAT-PT system, since the traffic is
ESP protected. Consequently, the TCP and UDP checksums are ESP protected. Consequently, the TCP and UDP checksums are
calculated using the HITs in the place of the IP addresses in the calculated using the HITs in the place of the IP addresses in the
pseudo header. Furthermore, only the IPv6 pseudo header format is pseudo header. Furthermore, only the IPv6 pseudo header format is
used. This provides for IPv4 / IPv6 protocol translation. used. This provides for IPv4 / IPv6 protocol translation.
9. Multicast 9. Multicast
A number of studies investigating HIP-based multicast have been A number of studies investigating HIP-based multicast have been
published (including [shields-hip], [zhu-hip], [amir-hip], published (including [shields-hip], [zhu-hip], [amir-hip],
[kovacshazi-host], and [xueyong-secure]). In particular, so-called [kovacshazi-host], and [zhu-secure]). In particular, so-called Bloom
Bloom filters, which allow the compression of multiple labels into filters, which allow the compression of multiple labels into small
small data structures, may be a promising way forward [sarela-bloom]. data structures, may be a promising way forward [sarela-bloom].
However, the different schemes have not been adopted by the HIP However, the different schemes have not been adopted by the HIP
working group (nor the HIP research group in the IRTF), so the working group (nor the HIP research group in the IRTF), so the
details are not further elaborated here. details are not further elaborated here.
10. HIP Policies 10. HIP Policies
There are a number of variables that influence the HIP exchange that There are a number of variables that influence the HIP exchange that
each host must support. All HIP implementations should support at each host must support. All HIP implementations should support at
least two HIs, one to publish in DNS or a similar directory service least two HIs, one to publish in DNS or a similar directory service
and an unpublished one for anonymous usage (that should expect to be and an unpublished one for anonymous usage (that should expect to be
skipping to change at line 1395 skipping to change at line 1395
[RFC8046] Henderson, T., Ed., Vogt, C., and J. Arkko, "Host Mobility [RFC8046] Henderson, T., Ed., Vogt, C., and J. Arkko, "Host Mobility
with the Host Identity Protocol", RFC 8046, with the Host Identity Protocol", RFC 8046,
DOI 10.17487/RFC8046, February 2017, DOI 10.17487/RFC8046, February 2017,
<https://www.rfc-editor.org/info/rfc8046>. <https://www.rfc-editor.org/info/rfc8046>.
[RFC8047] Henderson, T., Ed., Vogt, C., and J. Arkko, "Host [RFC8047] Henderson, T., Ed., Vogt, C., and J. Arkko, "Host
Multihoming with the Host Identity Protocol", RFC 8047, Multihoming with the Host Identity Protocol", RFC 8047,
DOI 10.17487/RFC8047, February 2017, DOI 10.17487/RFC8047, February 2017,
<https://www.rfc-editor.org/info/rfc8047>. <https://www.rfc-editor.org/info/rfc8047>.
[RFC9028] Keranen, A., Melen, J., and M. Komu, Ed., "Native NAT [RFC9028] Keränen, A., Melén, J., and M. Komu, Ed., "Native NAT
Traversal Mode for the Host Identity Protocol", RFC 9028, Traversal Mode for the Host Identity Protocol", RFC 9028,
DOI 10.17487/RFC9028, June 2021, DOI 10.17487/RFC9028, July 2021,
<https://www.rfc-editor.org/info/rfc9028>. <https://www.rfc-editor.org/info/rfc9028>.
14.2. Informative References 14.2. Informative References
[amir-hip] Amir, K., Forsgren, H., Grahn, K., Karvi, T., and G. [amir-hip] Amir, K., Forsgren, H., Grahn, K., Karvi, T., and G.
Pulkkis, "Security and Trust of Public Key Cryptography Pulkkis, "Security and Trust of Public Key Cryptography
for HIP and HIP Multicast", International Journal of for HIP and HIP Multicast", International Journal of
Dependable and Trustworthy Information Systems (IJDTIS), Dependable and Trustworthy Information Systems (IJDTIS),
Vol. 2, Issue 3, pp. 17-35, DOI 10.4018/jdtis.2011070102, Vol. 2, Issue 3, pp. 17-35, DOI 10.4018/jdtis.2011070102,
2013, <https://doi.org/10.4018/jdtis.2011070102>. 2013, <https://doi.org/10.4018/jdtis.2011070102>.
skipping to change at line 1454 skipping to change at line 1454
31 October 2011, <https://datatracker.ietf.org/doc/html/ 31 October 2011, <https://datatracker.ietf.org/doc/html/
draft-heer-hip-middle-auth-04>. draft-heer-hip-middle-auth-04>.
[henderson-vpls] [henderson-vpls]
Henderson, T. R., Venema, S. C., and D. Mattes, "HIP-based Henderson, T. R., Venema, S. C., and D. Mattes, "HIP-based
Virtual Private LAN Service (HIPLS)", Work in Progress, Virtual Private LAN Service (HIPLS)", Work in Progress,
Internet-Draft, draft-henderson-hip-vpls-11, 3 August Internet-Draft, draft-henderson-hip-vpls-11, 3 August
2016, <https://datatracker.ietf.org/doc/html/draft- 2016, <https://datatracker.ietf.org/doc/html/draft-
henderson-hip-vpls-11>. henderson-hip-vpls-11>.
[HIP-DEX] Moskowitz, R., Ed., Hummen, R., and M. Komu, "HIP Diet [hip-dex] Moskowitz, R., Ed., Hummen, R., and M. Komu, "HIP Diet
EXchange (DEX)", Work in Progress, Internet-Draft, draft- EXchange (DEX)", Work in Progress, Internet-Draft, draft-
ietf-hip-dex-24, 19 January 2021, ietf-hip-dex-24, 19 January 2021,
<https://datatracker.ietf.org/doc/html/draft-ietf-hip-dex- <https://datatracker.ietf.org/doc/html/draft-ietf-hip-dex-
24>. 24>.
[hip-lte] Liyanage, M., Kumar, P., Ylianttila, M., and A. Gurtov, [hip-lte] Liyanage, M., Kumar, P., Ylianttila, M., and A. Gurtov,
"Novel secure VPN architectures for LTE backhaul "Novel secure VPN architectures for LTE backhaul
networks", Security and Communication Networks, Vol. 9, networks", Security and Communication Networks, Vol. 9,
pp. 1198-1215, DOI 10.1002/sec.1411, January 2016, pp. 1198-1215, DOI 10.1002/sec.1411, January 2016,
<https://doi.org/10.1002/sec.1411>. <https://doi.org/10.1002/sec.1411>.
skipping to change at line 1750 skipping to change at line 1750
Efficient IPv4/IPv6 Handovers Using Host-Based Identifier- Efficient IPv4/IPv6 Handovers Using Host-Based Identifier-
Location Split", Journal of Communications Software and Location Split", Journal of Communications Software and
Systems, Vol. 6, Issue 1, ISSN 18456421, Systems, Vol. 6, Issue 1, ISSN 18456421,
DOI 10.24138/jcomss.v6i1.193, 2010, DOI 10.24138/jcomss.v6i1.193, 2010,
<https://doi.org/10.24138/jcomss.v6i1.193>. <https://doi.org/10.24138/jcomss.v6i1.193>.
[xin-hip-lib] [xin-hip-lib]
Xin, G., "Host Identity Protocol Version 2.5", Master's Xin, G., "Host Identity Protocol Version 2.5", Master's
Thesis, Aalto University, Espoo, Finland, June 2012. Thesis, Aalto University, Espoo, Finland, June 2012.
[xueyong-secure]
Zhu, X. and J. W. Atwood, "A Secure Multicast Model for
Peer-to-Peer and Access Networks Using the Host Identity
Protocol", 2007 4th IEEE Consumer Communications and
Networking Conference, Las Vegas, NV, USA, pages
1098-1102, DOI 10.1109/CCNC.2007.221, 2007,
<https://doi.org/10.1109/CCNC.2007.221>.
[ylitalo-diss] [ylitalo-diss]
Ylitalo, J., "Secure Mobility at Multiple Granularity Ylitalo, J., "Secure Mobility at Multiple Granularity
Levels over Heterogeneous Datacom Networks", Dissertation, Levels over Heterogeneous Datacom Networks", Dissertation,
Helsinki University of Technology, Espoo, Finland, Helsinki University of Technology, Espoo, Finland,
ISBN 978-951-22-9531-9, 2008. ISBN 978-951-22-9531-9, 2008.
[ylitalo-spinat] [ylitalo-spinat]
Ylitalo, J., Salmela, P., and H. Tschofenig, "SPINAT: Ylitalo, J., Salmela, P., and H. Tschofenig, "SPINAT:
Integrating IPsec into Overlay Routing", First Integrating IPsec into Overlay Routing", First
International Conference on Security and Privacy for International Conference on Security and Privacy for
skipping to change at line 1787 skipping to change at line 1779
<https://datatracker.ietf.org/doc/html/draft-irtf-hiprg- <https://datatracker.ietf.org/doc/html/draft-irtf-hiprg-
revocation-05>. revocation-05>.
[zhu-hip] Zhu, X., Ding, Z., and X. Wang, "A Multicast Routing [zhu-hip] Zhu, X., Ding, Z., and X. Wang, "A Multicast Routing
Algorithm Applied to HIP-Multicast Model", 2011 Algorithm Applied to HIP-Multicast Model", 2011
International Conference on Network Computing and International Conference on Network Computing and
Information Security, Guilin, China, pp. 169-174, Information Security, Guilin, China, pp. 169-174,
DOI 10.1109/NCIS.2011.42, 2011, DOI 10.1109/NCIS.2011.42, 2011,
<https://doi.org/10.1109/NCIS.2011.42>. <https://doi.org/10.1109/NCIS.2011.42>.
[zhu-secure]
Zhu, X. and J. W. Atwood, "A Secure Multicast Model for
Peer-to-Peer and Access Networks Using the Host Identity
Protocol", 2007 4th IEEE Consumer Communications and
Networking Conference, Las Vegas, NV, USA, pages
1098-1102, DOI 10.1109/CCNC.2007.221, 2007,
<https://doi.org/10.1109/CCNC.2007.221>.
Appendix A. Design Considerations Appendix A. Design Considerations
A.1. Benefits of HIP A.1. Benefits of HIP
In the beginning, the network layer protocol (i.e., IP) had the In the beginning, the network layer protocol (i.e., IP) had the
following four "classic" invariants: following four "classic" invariants:
1. Non-mutable: The address sent is the address received. 1. Non-mutable: The address sent is the address received.
2. Non-mobile: The address doesn't change during the course of an 2. Non-mobile: The address doesn't change during the course of an
skipping to change at line 2101 skipping to change at line 2101
system-on-chip devices (such as Raspberry Pis, Intel Edison), but system-on-chip devices (such as Raspberry Pis, Intel Edison), but
small sensors operating with small batteries have remained small sensors operating with small batteries have remained
problematic. Different extensions to the HIP have been developed to problematic. Different extensions to the HIP have been developed to
scale HIP down to smaller devices, typically with different security scale HIP down to smaller devices, typically with different security
trade-offs. For example, the non-cryptographic identifiers have been trade-offs. For example, the non-cryptographic identifiers have been
proposed in RFID scenarios. The Slimfit approach [hummen] proposes a proposed in RFID scenarios. The Slimfit approach [hummen] proposes a
compression layer for HIP to make it more suitable for constrained compression layer for HIP to make it more suitable for constrained
networks. The approach is applied to a lightweight version of HIP networks. The approach is applied to a lightweight version of HIP
(i.e., "Diet HIP") in order to scale down to small sensors. (i.e., "Diet HIP") in order to scale down to small sensors.
The HIP Diet EXchange (DEX) [HIP-DEX] design aims to reduce the The HIP Diet EXchange (DEX) [hip-dex] design aims to reduce the
overhead of the employed cryptographic primitives by omitting public- overhead of the employed cryptographic primitives by omitting public-
key signatures and hash functions. In doing so, the main goal is to key signatures and hash functions. In doing so, the main goal is to
still deliver security properties similar to the Base Exchange (BEX). still deliver security properties similar to the Base Exchange (BEX).
DEX is primarily designed for computation- or memory-constrained DEX is primarily designed for computation- or memory-constrained
sensor/actuator devices. Like BEX, it is expected to be used sensor/actuator devices. Like BEX, it is expected to be used
together with a suitable security protocol such as the ESP for the together with a suitable security protocol such as the ESP for the
protection of upper-layer protocol data. In addition, DEX can also protection of upper-layer protocol data. In addition, DEX can also
be used as a keying mechanism for security primitives at the MAC be used as a keying mechanism for security primitives at the MAC
layer, e.g., for IEEE 802.15.9 networks [IEEE.802.15.9]. layer, e.g., for IEEE 802.15.9 networks [IEEE.802.15.9].
 End of changes. 8 change blocks. 
16 lines changed or deleted 16 lines changed or added

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