draft-ietf-hip-rfc4423-bis-15.txt   draft-ietf-hip-rfc4423-bis-16.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 18, 2017 November 14, 2016 Expires: August 19, 2017 February 15, 2017
Host Identity Protocol Architecture Host Identity Protocol Architecture
draft-ietf-hip-rfc4423-bis-15 draft-ietf-hip-rfc4423-bis-16
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 18, 2017. This Internet-Draft will expire on August 19, 2017.
Copyright Notice Copyright Notice
Copyright (c) 2016 IETF Trust and the persons identified as the Copyright (c) 2017 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 16, line 23 skipping to change at page 16, line 23
under steady-state DDoS attacks [beal-dos], on multiple adversary under steady-state DDoS attacks [beal-dos], on multiple adversary
models with varying puzzle difficulties [tritilanunt-dos] and with models with varying puzzle difficulties [tritilanunt-dos] and with
ephemeral Host Identities [komu-mitigation]. ephemeral Host Identities [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 [RFC8046] and multihoming [RFC8047] extensions.
[I-D.ietf-hip-multihoming] extensions. Consequently, HIP can provide Consequently, HIP can provide for a degree of internetworking
for a degree of internetworking mobility and multi-homing at a low mobility and multi-homing at a low infrastructure cost. HIP mobility
infrastructure cost. HIP mobility includes IP address changes (via includes IP address changes (via any method) to either party. Thus,
any method) to either party. Thus, a system is considered mobile if a system is considered mobile if its IP address can change
its IP address can change dynamically for any reason like PPP, DHCP, dynamically for any reason like PPP, DHCP, IPv6 prefix reassignments,
IPv6 prefix reassignments, or a NAT device remapping its translation. or a NAT device remapping its translation. Likewise, a system is
Likewise, a system is considered multi-homed if it has more than one considered multi-homed if it has more than one globally routable IP
globally routable IP address at the same time. HIP links IP address at the same time. HIP links IP addresses together, when
addresses together, when multiple IP addresses correspond to the same multiple IP addresses correspond to the same Host Identity. If one
Host Identity. If one address becomes unusable, or a more preferred address becomes unusable, or a more preferred address becomes
address becomes available, existing transport associations can easily available, existing transport associations can easily be moved to
be moved to another address. another address.
When a node moves while communication is already on-going, address When a node moves while communication is already on-going, address
changes are rather straightforward. The peer of the mobile node can changes are rather straightforward. The peer of the mobile node can
just accept a HIP or an integrity protected ESP packet from any just accept a HIP or an integrity protected ESP packet from any
address and ignore the source address. However, as discussed in address and ignore the source address. However, as discussed in
Section 12.2 below, a mobile node must send a HIP UPDATE packet to Section 12.2 below, a mobile node must send a HIP UPDATE packet to
inform the peer of the new address(es), and the peer must verify that inform the peer of the new address(es), and the peer must verify that
the mobile node is reachable through these addresses. This is the mobile node is reachable through these addresses. This is
especially helpful for those situations where the peer node is especially helpful for those situations where the peer node is
sending data periodically to the mobile node (that is, re-starting a sending data periodically to the mobile node (that is, re-starting a
skipping to change at page 31, line 6 skipping to change at page 31, line 6
connections with a large number of hosts (using unpublished HIs), and connections with a large number of hosts (using unpublished HIs), and
then claims to all of these hosts that it has moved to a target then claims to all of these hosts that it has moved to a target
node's IP address. If the peer hosts were to simply accept the move, node's IP address. If the peer hosts were to simply accept the move,
the result would be a packet flood to the target node's address. To the result would be a packet flood to the target node's address. To
prevent this type of attack, HIP mobility extensions include a return prevent this type of attack, HIP mobility extensions include a return
routability check procedure where the reachability of a node is routability check procedure where the reachability of a node is
separately checked at each address before using the address for separately checked at each address before using the address for
larger amounts of traffic. larger amounts of traffic.
A credit-based authorization approach for host mobility with the Host A credit-based authorization approach for host mobility with the Host
Identity Protocol [I-D.ietf-hip-rfc5206-bis] can be used between Identity Protocol [RFC8046] can be used between hosts for sending
hosts for sending data prior to completing the address tests. data prior to completing the address tests. Otherwise, if HIP is
Otherwise, if HIP is used between two hosts that fully trust each used between two hosts that fully trust each other, the hosts may
other, the hosts may optionally decide to skip the address tests. optionally decide to skip the address tests. However, such
However, such performance optimization must be restricted to peers performance optimization must be restricted to peers that are known
that are known to be trustworthy and capable of protecting themselves to be trustworthy and capable of protecting themselves from malicious
from malicious software. software.
12.3. HITs used in ACLs 12.3. HITs used in ACLs
At end-hosts, HITs can be used in IP-based access control lists at At end-hosts, HITs can be used in IP-based access control lists at
the application and network layers. At middleboxes, HIP-aware the application and network layers. At middleboxes, HIP-aware
firewalls [lindqvist-enterprise] can use HITs or public keys to firewalls [lindqvist-enterprise] can use HITs or public keys to
control both ingress and egress access to networks or individual control both ingress and egress access to networks or individual
hosts, even in the presence of mobile devices because the HITs and hosts, even in the presence of mobile devices because the HITs and
public keys are topologically independent. As discussed earlier in public keys are topologically independent. As discussed earlier in
Section 7, once a HIP session has been established, the SPI value in Section 7, once a HIP session has been established, the SPI value in
skipping to change at page 34, line 11 skipping to change at page 34, line 11
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-04 (work in progress), October 2016. draft-ietf-hip-dex-05 (work in progress), February 2017.
[I-D.ietf-hip-multihoming]
Henderson, T., Vogt, C., and J. Arkko, "Host Multihoming
with the Host Identity Protocol", draft-ietf-hip-
multihoming-12 (work in progress), October 2016.
[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-13 (work in progress), July 2016. native-nat-traversal-16 (work in progress), February 2017.
[I-D.ietf-hip-rfc5206-bis]
Henderson, T., Vogt, C., and J. Arkko, "Host Mobility with
the Host Identity Protocol", draft-ietf-hip-rfc5206-bis-14
(work in progress), October 2016.
[I-D.ietf-hip-rfc6253-bis] [I-D.ietf-hip-rfc6253-bis]
Heer, T. and S. Varjonen, "Host Identity Protocol Heer, T. and S. Varjonen, "Host Identity Protocol
Certificates", draft-ietf-hip-rfc6253-bis-09 (work in Certificates", draft-ietf-hip-rfc6253-bis-09 (work in
progress), July 2016. progress), July 2016.
[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,
<http://www.rfc-editor.org/info/rfc5482>. <http://www.rfc-editor.org/info/rfc5482>.
skipping to change at page 35, line 17 skipping to change at page 35, line 9
October 2016, <http://www.rfc-editor.org/info/rfc8003>. October 2016, <http://www.rfc-editor.org/info/rfc8003>.
[RFC8004] Laganier, J. and L. Eggert, "Host Identity Protocol (HIP) [RFC8004] Laganier, J. and L. Eggert, "Host Identity Protocol (HIP)
Rendezvous Extension", RFC 8004, DOI 10.17487/RFC8004, Rendezvous Extension", RFC 8004, DOI 10.17487/RFC8004,
October 2016, <http://www.rfc-editor.org/info/rfc8004>. October 2016, <http://www.rfc-editor.org/info/rfc8004>.
[RFC8005] Laganier, J., "Host Identity Protocol (HIP) Domain Name [RFC8005] Laganier, J., "Host Identity Protocol (HIP) Domain Name
System (DNS) Extension", RFC 8005, DOI 10.17487/RFC8005, System (DNS) Extension", RFC 8005, DOI 10.17487/RFC8005,
October 2016, <http://www.rfc-editor.org/info/rfc8005>. October 2016, <http://www.rfc-editor.org/info/rfc8005>.
[RFC8046] Henderson, T., Ed., Vogt, C., and J. Arkko, "Host Mobility
with the Host Identity Protocol", RFC 8046,
DOI 10.17487/RFC8046, February 2017,
<http://www.rfc-editor.org/info/rfc8046>.
[RFC8047] Henderson, T., Ed., Vogt, C., and J. Arkko, "Host
Multihoming with the Host Identity Protocol", RFC 8047,
DOI 10.17487/RFC8047, February 2017,
<http://www.rfc-editor.org/info/rfc8047>.
16.2. Informative references 16.2. Informative references
[amir-hip] [amir-hip]
Amir, K., Forsgren, H., Grahn, K., Karvi, T., and G. Amir, K., Forsgren, H., Grahn, K., Karvi, T., and G.
Pulkkis, "Security and Trust of Public Key Cryptography Pulkkis, "Security and Trust of Public Key Cryptography
for HIP and HIP Multicast", International Journal of for HIP and HIP Multicast", International Journal of
Dependable and Trustworthy Information Systems (IJDTIS), Dependable and Trustworthy Information Systems (IJDTIS),
2(3), 17-35, DOI: 10.4018/jdtis.2011070102, 2013. 2(3), 17-35, DOI: 10.4018/jdtis.2011070102, 2013.
[aura-dos] [aura-dos]
 End of changes. 9 change blocks. 
36 lines changed or deleted 36 lines changed or added

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