draft-ietf-hip-rfc5206-bis-12.txt   draft-ietf-hip-rfc5206-bis-13.txt 
Network Working Group T. Henderson, Ed. Network Working Group T. Henderson, Ed.
Internet-Draft University of Washington Internet-Draft University of Washington
Obsoletes: 5206 (if approved) C. Vogt Obsoletes: 5206 (if approved) C. Vogt
Intended status: Standards Track Independent Intended status: Standards Track Independent
Expires: December 2, 2016 J. Arkko Expires: March 13, 2017 J. Arkko
Ericsson Ericsson
May 31, 2016 September 9, 2016
Host Mobility with the Host Identity Protocol Host Mobility with the Host Identity Protocol
draft-ietf-hip-rfc5206-bis-12 draft-ietf-hip-rfc5206-bis-13
Abstract Abstract
This document defines mobility extensions to the Host Identity This document defines a mobility extension to the Host Identity
Protocol (HIP). Specifically, this document defines a general Protocol (HIP). Specifically, this document defines a "LOCATOR_SET"
"LOCATOR_SET" parameter for HIP messages that allows for a HIP host parameter for HIP messages that allows for a HIP host to notify peers
to notify peers about alternate addresses at which it may be reached. about alternate addresses at which it may be reached. This document
This document also defines elements of procedure for mobility of a also defines how the parameter can be used to preserve communications
HIP host -- the process by which a host dynamically changes the across a change to the IP address used by one or both peer hosts.
primary locator that it uses to receive packets. While the same The same LOCATOR_SET parameter can also be used to support end-host
LOCATOR_SET parameter can also be used to support end-host multihoming, but the procedures are out of scope for this document
multihoming, detailed procedures are out of scope for this document. and are specified elsewhere. This document obsoletes RFC 5206.
This document obsoletes RFC 5206.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
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 December 2, 2016. This Internet-Draft will expire on March 13, 2017.
Copyright Notice Copyright Notice
Copyright (c) 2016 IETF Trust and the persons identified as the Copyright (c) 2016 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
skipping to change at page 2, line 52 skipping to change at page 2, line 49
5.5. Changing the Preferred Locator . . . . . . . . . . . . . 23 5.5. Changing the Preferred Locator . . . . . . . . . . . . . 23
5.6. Credit-Based Authorization . . . . . . . . . . . . . . . 23 5.6. Credit-Based Authorization . . . . . . . . . . . . . . . 23
5.6.1. Handling Payload Packets . . . . . . . . . . . . . . 24 5.6.1. Handling Payload Packets . . . . . . . . . . . . . . 24
5.6.2. Credit Aging . . . . . . . . . . . . . . . . . . . . 25 5.6.2. Credit Aging . . . . . . . . . . . . . . . . . . . . 25
6. Security Considerations . . . . . . . . . . . . . . . . . . . 26 6. Security Considerations . . . . . . . . . . . . . . . . . . . 26
6.1. Impersonation Attacks . . . . . . . . . . . . . . . . . . 27 6.1. Impersonation Attacks . . . . . . . . . . . . . . . . . . 27
6.2. Denial-of-Service Attacks . . . . . . . . . . . . . . . . 28 6.2. Denial-of-Service Attacks . . . . . . . . . . . . . . . . 28
6.2.1. Flooding Attacks . . . . . . . . . . . . . . . . . . 28 6.2.1. Flooding Attacks . . . . . . . . . . . . . . . . . . 28
6.2.2. Memory/Computational-Exhaustion DoS Attacks . . . . . 28 6.2.2. Memory/Computational-Exhaustion DoS Attacks . . . . . 28
6.3. Mixed Deployment Environment . . . . . . . . . . . . . . 29 6.3. Mixed Deployment Environment . . . . . . . . . . . . . . 29
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 29 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 30
8. Authors and Acknowledgments . . . . . . . . . . . . . . . . . 30 8. Authors and Acknowledgments . . . . . . . . . . . . . . . . . 30
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 30 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 30
9.1. Normative references . . . . . . . . . . . . . . . . . . 30 9.1. Normative references . . . . . . . . . . . . . . . . . . 30
9.2. Informative references . . . . . . . . . . . . . . . . . 31 9.2. Informative references . . . . . . . . . . . . . . . . . 31
Appendix A. Document Revision History . . . . . . . . . . . . . 32 Appendix A. Document Revision History . . . . . . . . . . . . . 32
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 33 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 33
1. Introduction and Scope 1. Introduction and Scope
The Host Identity Protocol [RFC7401] (HIP) supports an architecture The Host Identity Protocol [RFC7401] (HIP) supports an architecture
skipping to change at page 3, line 31 skipping to change at page 3, line 29
host must also know at least one IP address at which its peers are host must also know at least one IP address at which its peers are
reachable. Initially, these IP addresses are the ones used during reachable. Initially, these IP addresses are the ones used during
the HIP base exchange. the HIP base exchange.
One consequence of such a decoupling is that new solutions to One consequence of such a decoupling is that new solutions to
network-layer mobility and host multihoming are possible. There are network-layer mobility and host multihoming are possible. There are
potentially many variations of mobility and multihoming possible. potentially many variations of mobility and multihoming possible.
The scope of this document encompasses messaging and elements of The scope of this document encompasses messaging and elements of
procedure for basic network-level host mobility, leaving more procedure for basic network-level host mobility, leaving more
complicated mobility scenarios, multihoming, and other variations for complicated mobility scenarios, multihoming, and other variations for
further study. More specifically: further study. More specifically, the following are in scope:
This document defines a generalized LOCATOR_SET parameter for use This document defines a LOCATOR_SET parameter for use in HIP
in HIP messages. The LOCATOR_SET parameter allows a HIP host to messages. The LOCATOR_SET parameter allows a HIP host to notify a
notify a peer about alternate locators at which it is reachable. peer about alternate locators at which it is reachable. The
The locators may be merely IP addresses, or they may have locators may be merely IP addresses, or they may have additional
additional multiplexing and demultiplexing context to aid with the multiplexing and demultiplexing context to aid with the packet
packet handling in the lower layers. For instance, an IP address handling in the lower layers. For instance, an IP address may
may need to be paired with an ESP Security Parameter Index (SPI) need to be paired with an ESP Security Parameter Index (SPI) so
so that packets are sent on the correct SA for a given address. that packets are sent on the correct SA for a given address.
This document also specifies the messaging and elements of This document also specifies the messaging and elements of
procedure for end-host mobility of a HIP host -- the sequential procedure for end-host mobility of a HIP host. In particular,
change in the preferred IP address used to reach a host. In message flows to enable successful host mobility, including
particular, message flows to enable successful host mobility, address verification methods, are defined herein.
including address verification methods, are defined herein.
However, while the same LOCATOR_SET parameter is intended to The HIP rendezvous server [I-D.ietf-hip-rfc5204-bis] can be used
support host multihoming (simultaneous use of a number of to manage simultaneous mobility of both hosts, initial
addresses), detailed elements of procedure for host multihoming reacahability of a mobile host, location privacy, and some modes
are out of scope. of NAT traversal. Use of the HIP rendezvous server to manage the
simultaneous mobility of both hosts is specified herein.
While HIP can potentially be used with transports other than the ESP The following topics are out of scope:
transport format [RFC7402], this document largely assumes the use of
ESP and leaves other transport formats for further study.
There are a number of situations where the simple end-to-end While the same LOCATOR_SET parameter supports host multihoming
readdressing functionality is not sufficient. These include the (simultaneous use of a number of addresses), procedures for host
initial reachability of a mobile host, location privacy, simultaneous multihoming are out of scope, and are specified in
mobility of both hosts, and some modes of NAT traversal. In these [I-D.ietf-hip-multihoming].
situations, there is a need for some helper functionality in the
network, such as a HIP rendezvous server [I-D.ietf-hip-rfc5204-bis]. While HIP can potentially be used with transports other than the
Use of the HIP rendezvous server to manage the simultaneous mobility ESP transport format [RFC7402], this document largely assumes the
of both hosts is specified herein, but other such scenarios are out use of ESP and leaves other transport formats for further study.
of scope for this document. We also do not consider localized
mobility management extensions (i.e., mobility management techniques We do not consider localized mobility management extensions (i.e.,
that do not involve directly signaling the correspondent node); this mobility management techniques that do not involve directly
document is concerned with end-to-end mobility. Making underlying IP signaling the correspondent node); this document is concerned with
mobility transparent to the transport layer has implications on the end-to-end mobility.
proper response of transport congestion control, path MTU selection,
and Quality of Service (QoS). Transport-layer mobility triggers, and Finally, making underlying IP mobility transparent to the
the proper transport response to a HIP mobility or multihoming transport layer has implications on the proper response of
address change, are outside the scope of this document. transport congestion control, path MTU selection, and Quality of
Service (QoS). Transport-layer mobility triggers, and the proper
transport response to a HIP mobility or multihoming address
change, are outside the scope of this document.
2. Terminology and Conventions 2. Terminology and Conventions
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119]. document are to be interpreted as described in RFC 2119 [RFC2119].
LOCATOR_SET. The name of a HIP parameter containing zero or more LOCATOR_SET. A HIP parameter containing zero or more Locator fields.
Locator fields.
Locator. A name that controls how the packet is routed through the Locator. A name that controls how the packet is routed through the
network and demultiplexed by the end host. It may include a network and demultiplexed by the end host. It may include a
concatenation of traditional network addresses such as an IPv6 concatenation of traditional network addresses such as an IPv6
address and end-to-end identifiers such as an ESP SPI. It may address and end-to-end identifiers such as an ESP SPI. It may
also include transport port numbers or IPv6 Flow Labels as also include transport port numbers or IPv6 Flow Labels as
demultiplexing context, or it may simply be a network address. demultiplexing context, or it may simply be a network address.
Address. A name that denotes a point-of-attachment to the network. Address. A name that denotes a point-of-attachment to the network.
The two most common examples are an IPv4 address and an IPv6 The two most common examples are an IPv4 address and an IPv6
address. The set of possible addresses is a subset of the set of address. The set of possible addresses is a subset of the set of
possible locators. possible locators.
Preferred locator. A locator on which a host prefers to receive Preferred locator. A locator on which a host prefers to receive
data. With respect to a given peer, a host always has one active data. Certain locators are labelled as preferred when a host
Preferred locator, unless there are no active locators. By advertises its locator set to its peer. By default, the locators
default, the locators used in the HIP base exchange are the used in the HIP base exchange are the preferred locators. The use
Preferred locators. of preferred locators, including the scenario where multiple
address scopes and families may be in use, is defined more in
[I-D.ietf-hip-multihoming] than in this document.
Credit Based Authorization. A host must verify a peer host's Credit Based Authorization. A mechanism allowing a host to send a
reachability at a new locator. Credit-Based Authorization certain amount of data to a peer's newly announced locator before
authorizes the peer to receive a certain amount of data at the new the result of mandatory address verification is known.
locator before the result of such verification is known.
3. Protocol Model 3. Protocol Model
This section is an overview; more detailed specification follows this This section is an overview; more detailed specification follows this
section. section.
3.1. Operating Environment 3.1. Operating Environment
The Host Identity Protocol (HIP) [RFC7401] is a key establishment and The Host Identity Protocol (HIP) [RFC7401] is a key establishment and
parameter negotiation protocol. Its primary applications are for parameter negotiation protocol. Its primary applications are for
skipping to change at page 5, line 46 skipping to change at page 5, line 45
| | | | | | | | | | | | | | | |
| +------------+ | | +------------+ | | +------------+ | | +------------+ |
| | | | | | | |
| | | | | | | |
| Initiator | | Responder | | Initiator | | Responder |
+--------------------+ +--------------------+ +--------------------+ +--------------------+
Figure 1: HIP Deployment Model Figure 1: HIP Deployment Model
The general deployment model for HIP is shown above, assuming The general deployment model for HIP is shown above, assuming
operation in an end-to-end fashion. This document specifies operation in an end-to-end fashion. This document specifies an
extensions to the HIP protocol to enable end-host mobility and extension to the HIP protocol to enable end-host mobility. In
multihoming. In summary, these extensions to the HIP base protocol summary, these extensions to the HIP base protocol enable the
enable the signaling of new addressing information to the peer in HIP signaling of new addressing information to the peer in HIP messages.
messages. The messages are authenticated via a signature or keyed The messages are authenticated via a signature or keyed hash message
hash message authentication code (HMAC) based on its Host Identity. authentication code (HMAC) based on its Host Identity. This document
This document specifies the format of this new addressing specifies the format of this new addressing (LOCATOR_SET) parameter,
(LOCATOR_SET) parameter, the procedures for sending and processing the procedures for sending and processing this parameter to enable
this parameter to enable basic host mobility, and procedures for a basic host mobility, and procedures for a concurrent address
concurrent address verification mechanism. verification mechanism.
--------- ---------
| TCP | (sockets bound to HITs) | TCP | (sockets bound to HITs)
--------- ---------
| |
--------- ---------
----> | ESP | {HIT_s, HIT_d} <-> SPI ----> | ESP | {HIT_s, HIT_d} <-> SPI
| --------- | ---------
| | | |
---- --------- ---- ---------
skipping to change at page 7, line 31 skipping to change at page 7, line 30
multihoming context, certain IP addresses may need to be associated multihoming context, certain IP addresses may need to be associated
with certain ESP SPIs to avoid violating the ESP anti-replay window. with certain ESP SPIs to avoid violating the ESP anti-replay window.
Addresses may also be affiliated with transport ports in certain Addresses may also be affiliated with transport ports in certain
tunneling scenarios. Locators may simply be traditional network tunneling scenarios. Locators may simply be traditional network
addresses. The format of the locator fields in the LOCATOR_SET addresses. The format of the locator fields in the LOCATOR_SET
parameter is defined in Section 4. parameter is defined in Section 4.
3.1.2. Mobility Overview 3.1.2. Mobility Overview
When a host moves to another address, it notifies its peer of the new When a host moves to another address, it notifies its peer of the new
address by sending a HIP UPDATE packet containing a LOCATOR_SET address by sending a HIP UPDATE packet containing a single
parameter. This UPDATE packet is acknowledged by the peer. For LOCATOR_SET parameter and a single ESP_INFO parameter. This UPDATE
reliability in the presence of packet loss, the UPDATE packet is packet is acknowledged by the peer. For reliability in the presence
retransmitted as defined in the HIP protocol specification [RFC7401]. of packet loss, the UPDATE packet is retransmitted as defined in the
The peer can authenticate the contents of the UPDATE packet based on HIP protocol specification [RFC7401]. The peer can authenticate the
the signature and keyed hash of the packet. contents of the UPDATE packet based on the signature and keyed hash
of the packet.
When using ESP Transport Format [RFC7402], the host may at the same When using ESP Transport Format [RFC7402], the host may at the same
time decide to rekey its security association and possibly generate a time decide to rekey its security association and possibly generate a
new Diffie-Hellman key; all of these actions are triggered by new Diffie-Hellman key; all of these actions are triggered by
including additional parameters in the UPDATE packet, as defined in including additional parameters in the UPDATE packet, as defined in
the base protocol specification [RFC7401] and ESP extension the base protocol specification [RFC7401] and ESP extension
[RFC7402]. [RFC7402].
When using ESP (and possibly other transport modes in the future), When using ESP (and possibly other transport modes in the future),
the host is able to receive packets that are protected using a HIP the host is able to receive packets that are protected using a HIP
skipping to change at page 8, line 15 skipping to change at page 8, line 15
reordering occurs and packets fall outside the ESP anti-replay window reordering occurs and packets fall outside the ESP anti-replay window
for the SA, thereby requiring rekeying. for the SA, thereby requiring rekeying.
3.2. Protocol Overview 3.2. Protocol Overview
In this section, we briefly introduce a number of usage scenarios for In this section, we briefly introduce a number of usage scenarios for
HIP host mobility. These scenarios assume that HIP is being used HIP host mobility. These scenarios assume that HIP is being used
with the ESP transform [RFC7402], although other scenarios may be with the ESP transform [RFC7402], although other scenarios may be
defined in the future. To understand these usage scenarios, the defined in the future. To understand these usage scenarios, the
reader should be at least minimally familiar with the HIP protocol reader should be at least minimally familiar with the HIP protocol
specification [RFC7401]. However, for the (relatively) uninitiated specification [RFC7401] and with the use of ESP with HIP [RFC7402].
reader, it is most important to keep in mind that in HIP the actual According to these specifications, the data traffic in a HIP session
payload traffic is protected with ESP, and that the ESP SPI acts as is protected with ESP, and the ESP SPI acts as an index to the right
an index to the right host-to-host context. More specification host-to-host context. More specification details are found later in
details are found later in Section 4 and Section 5. Section 4 and Section 5.
The scenarios below assume that the two hosts have completed a single The scenarios below assume that the two hosts have completed a single
HIP base exchange with each other. Both of the hosts therefore have HIP base exchange with each other. Both of the hosts therefore have
one incoming and one outgoing SA. Further, each SA uses the same one incoming and one outgoing SA. Further, each SA uses the same
pair of IP addresses, which are the ones used in the base exchange. pair of IP addresses, which are the ones used in the base exchange.
The readdressing protocol is an asymmetric protocol where a mobile The readdressing protocol is an asymmetric protocol where a mobile
host informs a peer host about changes of IP addresses on affected host informs a peer host about changes of IP addresses on affected
SPIs. The readdressing exchange is designed to be piggybacked on SPIs. The readdressing exchange is designed to be piggybacked on
existing HIP exchanges. The majority of the packets on which the existing HIP exchanges. In support of mobility, the LOCATOR_SET
LOCATOR_SET parameters are expected to be carried are UPDATE packets. parameter is carried in UPDATE packets.
The scenarios below at times describe addresses as being in either an The scenarios below at times describe addresses as being in either an
ACTIVE, UNVERIFIED, or DEPRECATED state. From the perspective of a ACTIVE, UNVERIFIED, or DEPRECATED state. From the perspective of a
host, newly-learned addresses of the peer must be verified before put host, newly-learned addresses of the peer must be verified before put
into active service, and addresses removed by the peer are put into a into active service, and addresses removed by the peer are put into a
deprecated state. Under limited conditions described below deprecated state. Under limited conditions described below
(Section 5.6), an UNVERIFIED address may be used. The addressing (Section 5.6), an UNVERIFIED address may be used. The addressing
states are defined more formally in Section 5.1. states are defined more formally in Section 5.1.
Hosts that use link-local addresses as source addresses in their HIP Hosts that use link-local addresses as source addresses in their HIP
skipping to change at page 9, line 9 skipping to change at page 9, line 9
A mobile host must sometimes change an IP address bound to an A mobile host must sometimes change an IP address bound to an
interface. The change of an IP address might be needed due to a interface. The change of an IP address might be needed due to a
change in the advertised IPv6 prefixes on the link, a reconnected PPP change in the advertised IPv6 prefixes on the link, a reconnected PPP
link, a new DHCP lease, or an actual movement to another subnet. In link, a new DHCP lease, or an actual movement to another subnet. In
order to maintain its communication context, the host must inform its order to maintain its communication context, the host must inform its
peers about the new IP address. This first example considers the peers about the new IP address. This first example considers the
case in which the mobile host has only one interface, one IP address case in which the mobile host has only one interface, one IP address
in use within the HIP session, a single pair of SAs (one inbound, one in use within the HIP session, a single pair of SAs (one inbound, one
outbound), and no rekeying occurs on the SAs. We also assume that outbound), and no rekeying occurs on the SAs. We also assume that
the new IP addresses are within the same address family (IPv4 or the new IP addresses are within the same address family (IPv4 or
IPv6) as the first address. This is the simplest scenario, depicted IPv6) as the previous address. This is the simplest scenario,
in Figure 3. depicted in Figure 3.
Mobile Host Peer Host Mobile Host Peer Host
UPDATE(ESP_INFO, LOCATOR_SET, SEQ) UPDATE(ESP_INFO, LOCATOR_SET, SEQ)
-----------------------------------> ----------------------------------->
UPDATE(ESP_INFO, SEQ, ACK, ECHO_REQUEST) UPDATE(ESP_INFO, SEQ, ACK, ECHO_REQUEST)
<----------------------------------- <-----------------------------------
UPDATE(ACK, ECHO_RESPONSE) UPDATE(ACK, ECHO_RESPONSE)
-----------------------------------> ----------------------------------->
skipping to change at page 27, line 13 skipping to change at page 27, line 13
* tool 3: redirection-based flooding * tool 3: redirection-based flooding
- memory-exhaustion attacks - memory-exhaustion attacks
- computational-exhaustion attacks - computational-exhaustion attacks
We consider these in more detail in the following sections. We consider these in more detail in the following sections.
In Section 6.1 and Section 6.2, we assume that all users are using In Section 6.1 and Section 6.2, we assume that all users are using
HIP. In Section 6.3 we consider the security ramifications when we HIP. In Section 6.3 we consider the security ramifications when we
have both HIP and non-HIP hosts. Security considerations for Credit- have both HIP and non-HIP hosts.
Based Authorization are discussed in [SIMPLE-CBA].
6.1. Impersonation Attacks 6.1. Impersonation Attacks
An attacker wishing to impersonate another host will try to mislead An attacker wishing to impersonate another host will try to mislead
its victim into directly communicating with them, or carry out a man- its victim into directly communicating with them, or carry out a man-
in-the-middle (MitM) attack between the victim and the victim's in-the-middle (MitM) attack between the victim and the victim's
desired communication peer. Without mobility support, such attacks desired communication peer. Without mobility support, such attacks
are possible only if the attacker resides on the routing path between are possible only if the attacker resides on the routing path between
its victim and the victim's desired communication peer, or if the its victim and the victim's desired communication peer, or if the
attacker tricks its victim into initiating the connection over an attacker tricks its victim into initiating the connection over an
skipping to change at page 28, line 32 skipping to change at page 28, line 32
infected nodes (e.g. nodes in a botnet), jointly send packets to the infected nodes (e.g. nodes in a botnet), jointly send packets to the
victim. With such an 'army', an attacker can take down even very victim. With such an 'army', an attacker can take down even very
high bandwidth networks/victims. high bandwidth networks/victims.
With the ability to redirect connections, an attacker could realize a With the ability to redirect connections, an attacker could realize a
DDoS attack without having to distribute viral code. Here, the DDoS attack without having to distribute viral code. Here, the
attacker initiates a large download from a server, and subsequently attacker initiates a large download from a server, and subsequently
uses the HIP mobility mechanism to redirect this download to its uses the HIP mobility mechanism to redirect this download to its
victim. The attacker can repeat this with multiple servers. This victim. The attacker can repeat this with multiple servers. This
threat is mitigated through reachability checks and credit-based threat is mitigated through reachability checks and credit-based
authorization. Both strategies do not eliminate flooding attacks per authorization. Reachability checks, which when conducted using HIP
se, but they preclude: (i) their use from a location off the path can leverage the built-in authentication properties of HIP, can
towards the flooded victim; and (ii) any amplification in the number prevent redirection-based flooding attacks. However, the delay of
and size of the redirected packets. As a result, the combination of such a check can have a noticeable impact on application performance.
a reachability check and credit-based authorization lowers a HIP To reduce the impact of the delay, credit-based authorization can be
redirection-based flooding attack to the level of a direct flooding used to send a limited number of packets to the new address while the
attack in which the attacker itself sends the flooding traffic to the validity of the IP address is still in question. Both strategies do
victim. not eliminate flooding attacks per se, but they preclude: (i) their
use from a location off the path towards the flooded victim; and (ii)
any amplification in the number and size of the redirected packets.
As a result, the combination of a reachability check and credit-based
authorization lowers a HIP redirection-based flooding attack to the
level of a direct flooding attack in which the attacker itself sends
the flooding traffic to the victim.
6.2.2. Memory/Computational-Exhaustion DoS Attacks 6.2.2. Memory/Computational-Exhaustion DoS Attacks
We now consider whether or not the proposed extensions to HIP add any We now consider whether or not the proposed extensions to HIP add any
new DoS attacks (consideration of DoS attacks using the base HIP new DoS attacks (consideration of DoS attacks using the base HIP
exchange and updates is discussed in [RFC7401]). A simple attack is exchange and updates is discussed in [RFC7401]). A simple attack is
to send many UPDATE packets containing many IP addresses that are not to send many UPDATE packets containing many IP addresses that are not
flagged as preferred. The attacker continues to send such packets flagged as preferred. The attacker continues to send such packets
until the number of IP addresses associated with the attacker's HI until the number of IP addresses associated with the attacker's HI
crashes the system. Therefore, a HIP association SHOULD limit the crashes the system. Therefore, a HIP association SHOULD limit the
skipping to change at page 29, line 44 skipping to change at page 30, line 7
host could spoof the non-HIP host's IP address during the base host could spoof the non-HIP host's IP address during the base
exchange or set the non-HIP host's IP address as its preferred exchange or set the non-HIP host's IP address as its preferred
address via an UPDATE. Other possibilities exist, but a solution address via an UPDATE. Other possibilities exist, but a solution
is to prevent the local redirection of sessions that were is to prevent the local redirection of sessions that were
previously using an unverified address, but outside of the previously using an unverified address, but outside of the
existing HIP context, into the HIP SAs until the address change existing HIP context, into the HIP SAs until the address change
can be verified. can be verified.
7. IANA Considerations 7. IANA Considerations
The following changes to the "Host Identity Protocol (HIP) RFC5206, obsoleted by this document, specified an allocation for a
Parameters" registries are requested. LOCATOR parameter in the HIP Parameters registry. This document
requests IANA to rename the parameter to 'LOCATOR_SET' and to update
The existing Parameter Type of 'LOCATOR' (value 193) should be the reference from RFC5206 to this specification.
renamed to 'LOCATOR_SET' and the reference should be updated from
RFC5206 to this specification.
The existing Notify Message Type of 'LOCATOR_TYPE_UNSUPPORTED' (value RFC5206, obsoleted by this document, specified an allocation a
46) should have its reference updated from RFC5206 to this LOCATOR_TYPE_UNSUPPORTED type in the Notify Message Type registry.
specification. This document requests IANA to update the reference from RFC5206 to
this specification.
8. Authors and Acknowledgments 8. Authors and Acknowledgments
Pekka Nikander and Jari Arkko originated this document, and Christian Pekka Nikander and Jari Arkko originated this document, and Christian
Vogt and Thomas Henderson (editor) later joined as co-authors. Greg Vogt and Thomas Henderson (editor) later joined as co-authors. Greg
Perkins contributed the initial draft of the security section. Petri Perkins contributed the initial draft of the security section. Petri
Jokela was a co-author of the initial individual submission. Jokela was a co-author of the initial individual submission.
Credit-Based Authorization was originally introduced in [SIMPLE-CBA],
and portions of this document have been adopted from that earlier
draft.
The authors thank Jeff Ahrenholz, Baris Boyvat, Rene Hummen, Miika The authors thank Jeff Ahrenholz, Baris Boyvat, Rene Hummen, Miika
Komu, Mika Kousa, Jan Melen, and Samu Varjonen for improvements to Komu, Mika Kousa, Jan Melen, and Samu Varjonen for improvements to
the document. the document.
9. References 9. References
9.1. Normative references 9.1. Normative references
[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-10 Registration Extension", draft-ietf-hip-rfc5203-bis-11
(work in progress), January 2016. (work in progress), August 2016.
[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-07 (work Rendezvous Extension", draft-ietf-hip-rfc5204-bis-08 (work
in progress), December 2015. in progress), August 2016.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>. <http://www.rfc-editor.org/info/rfc2119>.
[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing
Architecture", RFC 4291, DOI 10.17487/RFC4291, February Architecture", RFC 4291, DOI 10.17487/RFC4291, February
2006, <http://www.rfc-editor.org/info/rfc4291>. 2006, <http://www.rfc-editor.org/info/rfc4291>.
skipping to change at page 31, line 11 skipping to change at page 31, line 26
the Host Identity Protocol (HIP)", RFC 7402, the Host Identity Protocol (HIP)", RFC 7402,
DOI 10.17487/RFC7402, April 2015, DOI 10.17487/RFC7402, April 2015,
<http://www.rfc-editor.org/info/rfc7402>. <http://www.rfc-editor.org/info/rfc7402>.
9.2. Informative references 9.2. Informative references
[CBA-MIPv6] [CBA-MIPv6]
Vogt, C. and J. Arkko, "Credit-Based Authorization for Vogt, C. and J. Arkko, "Credit-Based Authorization for
Mobile IPv6 Early Binding Updates", February 2005. Mobile IPv6 Early Binding Updates", February 2005.
[I-D.ietf-hip-multihoming]
Henderson, T., Vogt, C., and J. Arkko, "Host Multihoming
with the Host Identity Protocol", draft-ietf-hip-
multihoming-10 (work in progress), July 2016.
[RFC4225] Nikander, P., Arkko, J., Aura, T., Montenegro, G., and E. [RFC4225] Nikander, P., Arkko, J., Aura, T., Montenegro, G., and E.
Nordmark, "Mobile IP Version 6 Route Optimization Security Nordmark, "Mobile IP Version 6 Route Optimization Security
Design Background", RFC 4225, DOI 10.17487/RFC4225, Design Background", RFC 4225, DOI 10.17487/RFC4225,
December 2005, <http://www.rfc-editor.org/info/rfc4225>. December 2005, <http://www.rfc-editor.org/info/rfc4225>.
[SIMPLE-CBA] [SIMPLE-CBA]
Vogt, C. and J. Arkko, "Credit-Based Authorization for Vogt, C. and J. Arkko, "Credit-Based Authorization for
Concurrent Reachability Verification", February 2006. Concurrent Reachability Verification", February 2006.
Appendix A. Document Revision History Appendix A. Document Revision History
skipping to change at page 33, line 16 skipping to change at page 33, line 16
| | mailing list discussion) | | | mailing list discussion) |
| | | | | |
| | removed discussion about handling LOCATOR_SET | | | removed discussion about handling LOCATOR_SET |
| | parameters in packets other than UPDATE (per previous | | | parameters in packets other than UPDATE (per previous |
| | mailing list discussion) | | | mailing list discussion) |
| | | | | |
| draft-11 | Editorial improvements from WGLC | | draft-11 | Editorial improvements from WGLC |
| | | | | |
| draft-12 | Update author affiliations and IPR boilerplate to | | draft-12 | Update author affiliations and IPR boilerplate to |
| | trust200902 | | | trust200902 |
| | |
| draft-13 | Editorial improvements to IANA considerations section. |
| | |
| | Moved citation of [SIMPLE-CBA] to Section 8 and |
| | slightly updated text for redirection-based flooding |
| | attacks in the Security Considerations section. |
| | |
| | Editorial improvements based on last call comments. |
+----------+--------------------------------------------------------+ +----------+--------------------------------------------------------+
Authors' Addresses Authors' Addresses
Thomas R. Henderson (editor) Thomas R. Henderson (editor)
University of Washington University of Washington
Campus Box 352500 Campus Box 352500
Seattle, WA Seattle, WA
USA USA
 End of changes. 29 change blocks. 
110 lines changed or deleted 132 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/