draft-ietf-hip-rfc5206-bis-10.txt   draft-ietf-hip-rfc5206-bis-11.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 J. Arkko Intended status: Standards Track J. Arkko
Expires: July 26, 2016 Ericsson Research NomadicLab Expires: November 6, 2016 Ericsson Research NomadicLab
January 23, 2016 May 5, 2016
Host Mobility with the Host Identity Protocol Host Mobility with the Host Identity Protocol
draft-ietf-hip-rfc5206-bis-10 draft-ietf-hip-rfc5206-bis-11
Abstract Abstract
This document defines mobility extensions to the Host Identity This document defines mobility extensions to the Host Identity
Protocol (HIP). Specifically, this document defines a general Protocol (HIP). Specifically, this document defines a general
"LOCATOR_SET" parameter for HIP messages that allows for a HIP host "LOCATOR_SET" parameter for HIP messages that allows for a HIP host
to notify peers about alternate addresses at which it may be reached. to notify peers about alternate addresses at which it may be reached.
This document also defines elements of procedure for mobility of a This document also defines elements of procedure for mobility of a
HIP host -- the process by which a host dynamically changes the HIP host -- the process by which a host dynamically changes the
primary locator that it uses to receive packets. While the same primary locator that it uses to receive packets. While the same
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 July 26, 2016. This Internet-Draft will expire on November 6, 2016.
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 37 skipping to change at page 2, line 37
2. Terminology and Conventions . . . . . . . . . . . . . . . . . 4 2. Terminology and Conventions . . . . . . . . . . . . . . . . . 4
3. Protocol Model . . . . . . . . . . . . . . . . . . . . . . . 5 3. Protocol Model . . . . . . . . . . . . . . . . . . . . . . . 5
3.1. Operating Environment . . . . . . . . . . . . . . . . . . 5 3.1. Operating Environment . . . . . . . . . . . . . . . . . . 5
3.1.1. Locator . . . . . . . . . . . . . . . . . . . . . . . 8 3.1.1. Locator . . . . . . . . . . . . . . . . . . . . . . . 8
3.1.2. Mobility Overview . . . . . . . . . . . . . . . . . . 8 3.1.2. Mobility Overview . . . . . . . . . . . . . . . . . . 8
3.2. Protocol Overview . . . . . . . . . . . . . . . . . . . . 9 3.2. Protocol Overview . . . . . . . . . . . . . . . . . . . . 9
3.2.1. Mobility with a Single SA Pair (No Rekeying) . . . . 9 3.2.1. Mobility with a Single SA Pair (No Rekeying) . . . . 9
3.2.2. Mobility with a Single SA Pair (Mobile-Initiated 3.2.2. Mobility with a Single SA Pair (Mobile-Initiated
Rekey) . . . . . . . . . . . . . . . . . . . . . . . 11 Rekey) . . . . . . . . . . . . . . . . . . . . . . . 11
3.2.3. Mobility messaging through rendezvous server . . . . 11 3.2.3. Mobility messaging through rendezvous server . . . . 11
3.2.4. Network Renumbering . . . . . . . . . . . . . . . . . 12 3.2.4. Network Renumbering . . . . . . . . . . . . . . . . . 13
3.3. Other Considerations . . . . . . . . . . . . . . . . . . 13 3.3. Other Considerations . . . . . . . . . . . . . . . . . . 13
3.3.1. Address Verification . . . . . . . . . . . . . . . . 13 3.3.1. Address Verification . . . . . . . . . . . . . . . . 13
3.3.2. Credit-Based Authorization . . . . . . . . . . . . . 13 3.3.2. Credit-Based Authorization . . . . . . . . . . . . . 13
3.3.3. Preferred Locator . . . . . . . . . . . . . . . . . . 14 3.3.3. Preferred Locator . . . . . . . . . . . . . . . . . . 15
4. LOCATOR_SET Parameter Format . . . . . . . . . . . . . . . . 15 4. LOCATOR_SET Parameter Format . . . . . . . . . . . . . . . . 15
4.1. Traffic Type and Preferred Locator . . . . . . . . . . . 16 4.1. Traffic Type and Preferred Locator . . . . . . . . . . . 16
4.2. Locator Type and Locator . . . . . . . . . . . . . . . . 17 4.2. Locator Type and Locator . . . . . . . . . . . . . . . . 17
4.3. UPDATE Packet with Included LOCATOR_SET . . . . . . . . . 17 4.3. UPDATE Packet with Included LOCATOR_SET . . . . . . . . . 17
5. Processing Rules . . . . . . . . . . . . . . . . . . . . . . 17 5. Processing Rules . . . . . . . . . . . . . . . . . . . . . . 17
5.1. Locator Data Structure and Status . . . . . . . . . . . . 17 5.1. Locator Data Structure and Status . . . . . . . . . . . . 18
5.2. Sending LOCATOR_SETs . . . . . . . . . . . . . . . . . . 19 5.2. Sending LOCATOR_SETs . . . . . . . . . . . . . . . . . . 19
5.3. Handling Received LOCATOR_SETs . . . . . . . . . . . . . 20 5.3. Handling Received LOCATOR_SETs . . . . . . . . . . . . . 20
5.4. Verifying Address Reachability . . . . . . . . . . . . . 22 5.4. Verifying Address Reachability . . . . . . . . . . . . . 22
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 . . . . . . . . . . . . . . . 24
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 . . . . . . . . . . . . . . . . . . . . 26
6. Security Considerations . . . . . . . . . . . . . . . . . . . 26 6. Security Considerations . . . . . . . . . . . . . . . . . . . 27
6.1. Impersonation Attacks . . . . . . . . . . . . . . . . . . 27 6.1. Impersonation Attacks . . . . . . . . . . . . . . . . . . 28
6.2. Denial-of-Service Attacks . . . . . . . . . . . . . . . . 28 6.2. Denial-of-Service Attacks . . . . . . . . . . . . . . . . 29
6.2.1. Flooding Attacks . . . . . . . . . . . . . . . . . . 28 6.2.1. Flooding Attacks . . . . . . . . . . . . . . . . . . 29
6.2.2. Memory/Computational-Exhaustion DoS Attacks . . . . . 28 6.2.2. Memory/Computational-Exhaustion DoS Attacks . . . . . 29
6.3. Mixed Deployment Environment . . . . . . . . . . . . . . 29 6.3. Mixed Deployment Environment . . . . . . . . . . . . . . 30
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 29 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 30
8. Authors and Acknowledgments . . . . . . . . . . . . . . . . . 30 8. Authors and Acknowledgments . . . . . . . . . . . . . . . . . 31
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 30 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 31
9.1. Normative references . . . . . . . . . . . . . . . . . . 30 9.1. Normative references . . . . . . . . . . . . . . . . . . 31
9.2. Informative references . . . . . . . . . . . . . . . . . 31 9.2. Informative references . . . . . . . . . . . . . . . . . 32
Appendix A. Document Revision History . . . . . . . . . . . . . 32 Appendix A. Document Revision History . . . . . . . . . . . . . 33
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 33 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 34
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
that decouples the transport layer (TCP, UDP, etc.) from the that decouples the transport layer (TCP, UDP, etc.) from the
internetworking layer (IPv4 and IPv6) by using public/private key internetworking layer (IPv4 and IPv6) by using public/private key
pairs, instead of IP addresses, as host identities. When a host uses pairs, instead of IP addresses, as host identities. When a host uses
HIP, the overlying protocol sublayers (e.g., transport layer sockets HIP, the overlying protocol sublayers (e.g., transport layer sockets
and Encapsulating Security Payload (ESP) Security Associations (SAs)) and Encapsulating Security Payload (ESP) Security Associations (SAs))
are instead bound to representations of these host identities, and are instead bound to representations of these host identities, and
skipping to change at page 7, line 49 skipping to change at page 7, line 49
SPI is all that is required to find the right host context. ESP SPI is all that is required to find the right host context. ESP
rekeying events change the mapping between the HIT pair and SPI, but rekeying events change the mapping between the HIT pair and SPI, but
do not change the IP addresses. do not change the IP addresses.
Consider next a mobility event, in which a host moves to another IP Consider next a mobility event, in which a host moves to another IP
address. Two things must occur in this case. First, the peer must address. Two things must occur in this case. First, the peer must
be notified of the address change using a HIP UPDATE message. be notified of the address change using a HIP UPDATE message.
Second, each host must change its local bindings at the HIP sublayer Second, each host must change its local bindings at the HIP sublayer
(new IP addresses). It may be that both the SPIs and IP addresses (new IP addresses). It may be that both the SPIs and IP addresses
are changed simultaneously in a single UPDATE; the protocol described are changed simultaneously in a single UPDATE; the protocol described
herein supports this. However, elements of procedure to recover from herein supports this. Although internal notification of transport
simultaneous movement of both hosts are not specified herein. In layer protocols regarding the path change (e.g. to reset congestion
addition, internal notification of transport layer protocols of the control variables) may be desired, this specification does not
path change (e.g. to reset congestion control variables), and address such internal notification. In addition, elements of
elements of procedure for traversing middleboxes including network procedure for traversing middleboxes, including network address
address translators are not covered by this document. translators, may complicate the above basic scenario and are not
covered by this document.
3.1.1. Locator 3.1.1. Locator
This document defines a generalization of an address called a This document defines a generalization of an address called a
"locator". A locator specifies a point-of-attachment to the network "locator". A locator specifies a point-of-attachment to the network
but may also include additional end-to-end tunneling or per-host but may also include additional end-to-end tunneling or per-host
demultiplexing context that affects how packets are handled below the demultiplexing context that affects how packets are handled below the
logical HIP sublayer of the stack. This generalization is useful logical HIP sublayer of the stack. This generalization is useful
because IP addresses alone may not be sufficient to describe how because IP addresses alone may not be sufficient to describe how
packets should be handled below HIP. For example, in a host packets should be handled below HIP. For example, in a host
skipping to change at page 12, line 34 skipping to change at page 12, line 34
modifies the I1 packet before forwarding. Specifically, it MUST modifies the I1 packet before forwarding. Specifically, it MUST
rewrite the IP header source and destination addresses, recompute rewrite the IP header source and destination addresses, recompute
the IP header checksum, and include the FROM and RVS_HMAC the IP header checksum, and include the FROM and RVS_HMAC
parameters. parameters.
3. A host receiving an UPDATE packet MUST be prepared to process the 3. A host receiving an UPDATE packet MUST be prepared to process the
FROM and RVS_HMAC parameters, and MUST include a VIA_RVS FROM and RVS_HMAC parameters, and MUST include a VIA_RVS
parameter in the UPDATE reply that contains the ACK of the UPDATE parameter in the UPDATE reply that contains the ACK of the UPDATE
SEQ. SEQ.
4. This scenario requires that hosts using rendezvous servers also 4. An initiator receiving a VIA_RVS in the UPDATE reply should
take steps to update their current address bindings with their initiate address reachability tests (described later in this
rendezvous server upon a mobility event. document) towards the end host's address and not towards the
[I-D.ietf-hip-rfc5204-bis] does not specify how to update the address included in the VIA_RVS.
rendezvous server with a client host's new address.
[I-D.ietf-hip-rfc5203-bis] Section 3.2 describes how a host may This scenario requires that hosts using rendezvous servers also take
send a REG_REQUEST in either an I2 packet (if there is no active steps to update their current address bindings with their rendezvous
association) or an UPDATE packet (if such association exists). server upon a mobility event. [I-D.ietf-hip-rfc5204-bis] does not
The procedures described in [I-D.ietf-hip-rfc5203-bis] for specify how to update the rendezvous server with a client host's new
sending a REG_REQUEST and REG_RESPONSE to the rendezvous server address. [I-D.ietf-hip-rfc5203-bis] Section 3.2 describes how a host
apply also to this mobility scenario. may send a REG_REQUEST in either an I2 packet (if there is no active
association) or an UPDATE packet (if such association exists).
According to procedures described in [I-D.ietf-hip-rfc5203-bis], if a
mobile host has an active registration, it may use mobility updates
specified herein, within the context of that association, to
readdress the association.
3.2.4. Network Renumbering 3.2.4. Network Renumbering
It is expected that IPv6 networks will be renumbered much more often It is expected that IPv6 networks will be renumbered much more often
than most IPv4 networks. From an end-host point of view, network than most IPv4 networks. From an end-host point of view, network
renumbering is similar to mobility. renumbering is similar to mobility, and procedures described herein
also apply to notify a peer of a changed address.
3.3. Other Considerations 3.3. Other Considerations
3.3.1. Address Verification 3.3.1. Address Verification
When a HIP host receives a set of locators from another HIP host in a When a HIP host receives a set of locators from another HIP host in a
LOCATOR_SET, it does not necessarily know whether the other host is LOCATOR_SET, it does not necessarily know whether the other host is
actually reachable at the claimed addresses. In fact, a malicious actually reachable at the claimed addresses. In fact, a malicious
peer host may be intentionally giving bogus addresses in order to peer host may be intentionally giving bogus addresses in order to
cause a packet flood towards the target addresses [RFC4225]. cause a packet flood towards the target addresses [RFC4225].
Therefore, the HIP host must first check that the peer is reachable Therefore, the HIP host must first check that the peer is reachable
at the new address. at the new address.
An additional potential benefit of performing address verification is
to allow middleboxes in the network along the new path to obtain the
peer host's inbound SPI.
Address verification is implemented by the challenger sending some Address verification is implemented by the challenger sending some
piece of unguessable information to the new address, and waiting for piece of unguessable information to the new address, and waiting for
some acknowledgment from the Responder that indicates reception of some acknowledgment from the Responder that indicates reception of
the information at the new address. This may include the exchange of the information at the new address. This may include the exchange of
a nonce, or the generation of a new SPI and observation of data a nonce, or the generation of a new SPI and observation of data
arriving on the new SPI. arriving on the new SPI.
An additional potential benefit of performing address verification is
to allow middleboxes in the network along the new path to obtain the
peer host's inbound SPI.
3.3.2. Credit-Based Authorization 3.3.2. Credit-Based Authorization
Credit-Based Authorization (CBA) allows a host to securely use a new Credit-Based Authorization (CBA) allows a host to securely use a new
locator even though the peer's reachability at the address embedded locator even though the peer's reachability at the address embedded
in the locator has not yet been verified. This is accomplished based in the locator has not yet been verified. This is accomplished based
on the following three hypotheses: on the following three hypotheses:
1. A flooding attacker typically seeks to somehow multiply the 1. A flooding attacker typically seeks to somehow multiply the
packets it generates for the purpose of its attack because packets it generates for the purpose of its attack because
bandwidth is an ample resource for many victims. bandwidth is an ample resource for many victims.
skipping to change at page 17, line 24 skipping to change at page 17, line 31
1: The concatenation of an ESP SPI (first 32 bits) followed by an 1: The concatenation of an ESP SPI (first 32 bits) followed by an
IPv6 address or an IPv4-in-IPv6 format IPv4 address (an additional IPv6 address or an IPv4-in-IPv6 format IPv4 address (an additional
128 bits). This IP address is defined primarily for ESP-based 128 bits). This IP address is defined primarily for ESP-based
usage. usage.
4.3. UPDATE Packet with Included LOCATOR_SET 4.3. UPDATE Packet with Included LOCATOR_SET
A number of combinations of parameters in an UPDATE packet are A number of combinations of parameters in an UPDATE packet are
possible (e.g., see Section 3.2). In this document, procedures are possible (e.g., see Section 3.2). In this document, procedures are
defined only for the case in which one LOCATOR_SET and one ESP_INFO defined only for the case in which one LOCATOR_SET and one ESP_INFO
parameter is used in any HIP packet. Furthermore, the LOCATOR_SET parameter is used in any HIP packet. Any UPDATE packet that includes
SHOULD list all of the locators that are active on the HIP a LOCATOR_SET parameter SHOULD include both an HMAC and a
association (including those on SAs not covered by the ESP_INFO HIP_SIGNATURE parameter.
parameter). Any UPDATE packet that includes a LOCATOR_SET parameter
SHOULD include both an HMAC and a HIP_SIGNATURE parameter. The The UPDATE MAY also include a HOST_ID parameter (which may be useful
UPDATE MAY also include a HOST_ID parameter (which may be useful for for middleboxes inspecting the HIP messages for the first time). If
middleboxes inspecting the HIP messages for the first time). If the the UPDATE includes the HOST_ID parameter, the receiving host MUST
UPDATE includes the HOST_ID parameter, the receiving host MUST verify verify that the HOST_ID corresponds to the HOST_ID that was used to
that the HOST_ID corresponds to the HOST_ID that was used to
establish the HIP association, and the HIP_SIGNATURE must verify with establish the HIP association, and the HIP_SIGNATURE must verify with
the public key assodiated with this HOST_ID parameter. The the public key associated with this HOST_ID parameter.
relationship between the announced Locators and any ESP_INFO
The relationship between the announced Locators and any ESP_INFO
parameters present in the packet is defined in Section 5.2. This parameters present in the packet is defined in Section 5.2. This
draft does not support any elements of procedure for sending more document does not support any elements of procedure for sending more
than one LOCATOR_SET or ESP_INFO parameter in a single UPDATE. than one LOCATOR_SET or ESP_INFO parameter in a single UPDATE.
5. Processing Rules 5. Processing Rules
This section describes rules for sending and receiving the This section describes rules for sending and receiving the
LOCATOR_SET parameter, testing address reachability, and using LOCATOR_SET parameter, testing address reachability, and using
Credit-Based Authorization (CBA) on UNVERIFIED locators. Credit-Based Authorization (CBA) on UNVERIFIED locators.
5.1. Locator Data Structure and Status 5.1. Locator Data Structure and Status
skipping to change at page 22, line 21 skipping to change at page 22, line 30
A host MUST verify the reachability of an UNVERIFIED address. The A host MUST verify the reachability of an UNVERIFIED address. The
status of a newly learned address MUST initially be set to UNVERIFIED status of a newly learned address MUST initially be set to UNVERIFIED
unless the new address is advertised in a R1 packet as a new unless the new address is advertised in a R1 packet as a new
Preferred locator. A host MAY also want to verify the reachability Preferred locator. A host MAY also want to verify the reachability
of an ACTIVE address again after some time, in which case it would of an ACTIVE address again after some time, in which case it would
set the status of the address to UNVERIFIED and reinitiate address set the status of the address to UNVERIFIED and reinitiate address
verification. verification.
A host typically starts the address-verification procedure by sending A host typically starts the address-verification procedure by sending
a nonce to the new address. For example, when the host is changing a nonce to the new address. A host MAY choose from different message
its SPI and sending an ESP_INFO to the peer, the NEW SPI value SHOULD exchanges or different nonce values so long as it establishes that
be random and the value MAY be copied into an ECHO_REQUEST sent in the peer has received and replied to the nonce at the new address.
the rekeying UPDATE. However, if the host is not changing its SPI, For example, when the host is changing its SPI and sending an
it MAY still use the ECHO_REQUEST parameter in an UPDATE message sent ESP_INFO to the peer, the NEW SPI value SHOULD be random and the
to the new address. A host MAY also use other message exchanges as random value MAY be copied into an ECHO_REQUEST sent in the rekeying
UPDATE. However, if the host is not changing its SPI, it MAY still
use the ECHO_REQUEST parameter for verification but with some other
random value. A host MAY also use other message exchanges as
confirmation of the address reachability. confirmation of the address reachability.
In some cases, it MAY be sufficient to use the arrival of data on a In some cases, it MAY be sufficient to use the arrival of data on a
newly advertised SA as implicit address reachability verification as newly advertised SA as implicit address reachability verification as
depicted in Figure 7, instead of waiting for the confirmation via a depicted in Figure 7, instead of waiting for the confirmation via a
HIP packet. In this case, a host advertising a new SPI as part of HIP packet. In this case, a host advertising a new SPI as part of
its address reachability check SHOULD be prepared to receive traffic its address reachability check SHOULD be prepared to receive traffic
on the new SA. on the new SA.
Mobile host Peer host Mobile host Peer host
skipping to change at page 23, line 34 skipping to change at page 23, line 52
different locator listed as ACTIVE until address verification different locator listed as ACTIVE until address verification
completes if one such locator is available. Alternatively, the completes if one such locator is available. Alternatively, the
host MAY use the new Preferred locator, even though in UNVERIFIED host MAY use the new Preferred locator, even though in UNVERIFIED
status, to the extent Credit-Based Authorization permits. Once status, to the extent Credit-Based Authorization permits. Once
address verification succeeds, the status of the new Preferred address verification succeeds, the status of the new Preferred
locator changes to ACTIVE and its use is no longer governed by locator changes to ACTIVE and its use is no longer governed by
Credit-Based Authorization. Credit-Based Authorization.
3. If the peer host has not indicated a preference for any address, 3. If the peer host has not indicated a preference for any address,
then the host picks one of the peer's ACTIVE addresses randomly then the host picks one of the peer's ACTIVE addresses randomly
or according to policy. This case may arise if, for example, or according to local policy. This case may arise if, for
ICMP error messages that deprecate the Preferred locator arrive, example, ICMP error messages that deprecate the Preferred locator
but the peer has not yet indicated a new Preferred locator. arrive, but the peer has not yet indicated a new Preferred
locator.
4. If the new Preferred locator has DEPRECATED status and there is 4. If the new Preferred locator has DEPRECATED status and there is
at least one non-deprecated address, the host selects one of the at least one non-deprecated address, the host selects one of the
non-deprecated addresses as a new Preferred locator and non-deprecated addresses as a new Preferred locator and
continues. If the selected address is UNVERIFIED, the address continues. If the selected address is UNVERIFIED, the address
verification procedure described above will apply. verification procedure described above will apply.
5.6. Credit-Based Authorization 5.6. Credit-Based Authorization
To prevent redirection-based flooding attacks, the use of a Credit- To prevent redirection-based flooding attacks, the use of a Credit-
Based Authorization (CBA) approach is mandatory when a host sends Based Authorization (CBA) approach MUST be used when a host sends
data to an UNVERIFIED locator. The following algorithm meets the data to an UNVERIFIED locator. The following algorithm meets the
security considerations for prevention of amplification and time- security considerations for prevention of amplification and time-
shifting attacks. Other forms of credit aging, and other values for shifting attacks. Other forms of credit aging, and other values for
the CreditAgingFactor and CreditAgingInterval parameters in the CreditAgingFactor and CreditAgingInterval parameters in
particular, are for further study, and so are the advanced CBA particular, are for further study, and so are the advanced CBA
techniques specified in [CBA-MIPv6]. techniques specified in [CBA-MIPv6].
5.6.1. Handling Payload Packets 5.6.1. Handling Payload Packets
A host maintains a "credit counter" for each of its peers. Whenever A host maintains a "credit counter" for each of its peers. Whenever
skipping to change at page 25, line 30 skipping to change at page 26, line 30
| destination address |-------------> | to ACTIVE | | destination address |-------------> | to ACTIVE |
\ exist? / | address | \ exist? / | address |
\_________________/ +---------------+ \_________________/ +---------------+
| |
| No | No
| |
v v
_________________ _________________
/ \ +---------------+ / \ +---------------+
/ Credit counter \ No | | / Credit counter \ No | |
| >= |-------------> | Drop packet | | >= |-------------> | Drop or |
\ packet size? / | | \ packet size? / | buffer packet |
\_________________/ +---------------+ \_________________/ +---------------+
| |
| Yes | Yes
| |
v v
+---------------+ +---------------+ +---------------+ +---------------+
| Reduce credit | | Send packet | | Reduce credit | | Send packet |
| counter by |----------------> | to preferred | | counter by |----------------> | to preferred |
| packet size | | address | | packet size | | address |
+---------------+ +---------------+ +---------------+ +---------------+
skipping to change at page 26, line 49 skipping to change at page 27, line 49
- direct conversation with the misled victim - direct conversation with the misled victim
- man-in-the-middle attack - man-in-the-middle attack
DoS attacks DoS attacks
- flooding attacks (== bandwidth-exhaustion attacks) - flooding attacks (== bandwidth-exhaustion attacks)
* tool 1: direct flooding * tool 1: direct flooding
* tool 2: flooding by zombies * tool 2: flooding by botnets
* 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 users. Security considerations for Credit- have both HIP and non-HIP hosts. Security considerations for Credit-
Based Authorization are discussed in [SIMPLE-CBA]. 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, both attack desired communication peer. Without mobility support, such attacks
types are possible only if the attacker resides on the routing path are possible only if the attacker resides on the routing path between
between its victim and the victim's desired communication peer, or if its victim and the victim's desired communication peer, or if the
the attacker tricks its victim into initiating the connection over an attacker tricks its victim into initiating the connection over an
incorrect routing path (e.g., by acting as a router or using spoofed incorrect routing path (e.g., by acting as a router or using spoofed
DNS entries). DNS entries).
The HIP extensions defined in this specification change the situation The HIP extensions defined in this specification change the situation
in that they introduce an ability to redirect a connection (like in that they introduce an ability to redirect a connection, both
IPv6), both before and after establishment. If no precautionary before and after establishment. If no precautionary measures are
measures are taken, an attacker could misuse the redirection feature taken, an attacker could potentially misuse the redirection feature
to impersonate a victim's peer from any arbitrary location. The to impersonate a victim's peer from any arbitrary location. However,
authentication and authorization mechanisms of the HIP base exchange the authentication and authorization mechanisms of the HIP base
[RFC7401] and the signatures in the UPDATE message prevent this exchange [RFC7401] and the signatures in the UPDATE message prevent
attack. Furthermore, ownership of a HIP association is securely this attack. Furthermore, ownership of a HIP association is securely
linked to a HIP HI/HIT. If an attacker somehow uses a bug in the linked to a HIP HI/HIT. If an attacker somehow uses a bug in the
implementation or weakness in some protocol to redirect a HIP implementation to redirect a HIP connection, the original owner can
connection, the original owner can always reclaim their connection always reclaim their connection (they can always prove ownership of
(they can always prove ownership of the private key associated with the private key associated with their public HI).
their public HI).
MitM attacks are always possible if the attacker is present during MitM attacks are possible if an on-path attacker is present during
the initial HIP base exchange and if the hosts do not authenticate the initial HIP base exchange and if the hosts do not authenticate
each other's identities. However, once the opportunistic base each other's identities. However, once such an opportunistic base
exchange has taken place, even a MitM cannot steal the HIP connection exchange has taken place, a MitM attacker that comes later to the
anymore because it is very difficult for an attacker to create an path cannot steal the HIP connection because it is very difficult for
UPDATE packet (or any HIP packet) that will be accepted as a an attacker to create an UPDATE packet (or any HIP packet) that will
legitimate update. UPDATE packets use HMAC and are signed. Even be accepted as a legitimate update. UPDATE packets use HMAC and are
when an attacker can snoop packets to obtain the SPI and HIT/HI, they signed. Even when an attacker can snoop packets to obtain the SPI
still cannot forge an UPDATE packet without knowledge of the secret and HIT/HI, they still cannot forge an UPDATE packet without
keys. knowledge of the secret keys. Also, replay attacks on the UPDATE
packet are prevented as described in [RFC7401].
6.2. Denial-of-Service Attacks 6.2. Denial-of-Service Attacks
6.2.1. Flooding Attacks 6.2.1. Flooding Attacks
The purpose of a denial-of-service attack is to exhaust some resource The purpose of a denial-of-service attack is to exhaust some resource
of the victim such that the victim ceases to operate correctly. A of the victim such that the victim ceases to operate correctly. A
denial-of-service attack can aim at the victim's network attachment denial-of-service attack can aim at the victim's network attachment
(flooding attack), its memory, or its processing capacity. In a (flooding attack), its memory, or its processing capacity. In a
flooding attack, the attacker causes an excessive number of bogus or flooding attack, the attacker causes an excessive number of bogus or
unwanted packets to be sent to the victim, which fills their unwanted packets to be sent to the victim, which fills their
available bandwidth. Note that the victim does not necessarily need available bandwidth. Note that the victim does not necessarily need
to be a node; it can also be an entire network. The attack basically to be a node; it can also be an entire network. The attack basically
functions the same way in either case. functions the same way in either case.
An effective DoS strategy is distributed denial of service (DDoS). An effective DoS strategy is distributed denial of service (DDoS).
Here, the attacker conventionally distributes some viral software to Here, the attacker conventionally distributes some viral software to
as many nodes as possible. Under the control of the attacker, the as many nodes as possible. Under the control of the attacker, the
infected nodes, or "zombies", jointly send packets to the victim. infected nodes (e.g. nodes in a botnet), jointly send packets to the
With such an 'army', an attacker can take down even very high victim. With such an 'army', an attacker can take down even very
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
redirects this download to its victim. The attacker can repeat this uses the HIP mobility mechanism to redirect this download to its
with multiple servers. This threat is mitigated through reachability victim. The attacker can repeat this with multiple servers. This
checks and credit-based authorization. Both strategies do not threat is mitigated through reachability checks and credit-based
eliminate flooding attacks per se, but they preclude: (i) their use authorization. Both strategies do not eliminate flooding attacks per
from a location off the path towards the flooded victim; and (ii) any se, but they preclude: (i) their use from a location off the path
amplification in the number and size of the redirected packets. As a towards the flooded victim; and (ii) any amplification in the number
result, the combination of a reachability check and credit-based and size of the redirected packets. As a result, the combination of
authorization lowers a HIP redirection-based flooding attack to the a reachability check and credit-based authorization lowers a HIP
level of a direct flooding attack in which the attacker itself sends redirection-based flooding attack to the level of a direct flooding
the flooding traffic to the victim. 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, there SHOULD be a limit to the number crashes the system. Therefore, a HIP association SHOULD limit the
of IP addresses that can be associated with any HI. Other forms of number of IP addresses that can be associated with any HI. Other
memory/computationally exhausting attacks via the HIP UPDATE packet forms of memory/computationally exhausting attacks via the HIP UPDATE
are handled in the base HIP document [RFC7401]. packet are handled in the base HIP document [RFC7401].
A central server that has to deal with a large number of mobile A central server that has to deal with a large number of mobile
clients may consider increasing the SA lifetimes to try to slow down clients MAY consider increasing the SA lifetimes to try to slow down
the rate of rekeying UPDATEs or increasing the cookie difficulty to the rate of rekeying UPDATEs or increasing the cookie difficulty to
slow down the rate of attack-oriented connections. slow down the rate of attack-oriented connections.
6.3. Mixed Deployment Environment 6.3. Mixed Deployment Environment
We now assume an environment with both HIP and non-HIP aware hosts. We now assume an environment with both HIP and non-HIP aware hosts.
Four cases exist. Four cases exist.
1. A HIP host redirects its connection onto a non-HIP host. The 1. A HIP host redirects its connection onto a non-HIP host. The
non-HIP host will drop the reachability packet, so this is not a non-HIP host will drop the reachability packet, so this is not a
skipping to change at page 29, line 36 skipping to change at page 30, line 36
The non-HIP host contacts the service that a HIP host has a The non-HIP host contacts the service that a HIP host has a
connection with and then attempts to change its IP address to connection with and then attempts to change its IP address to
steal the HIP host's connection. What will happen in this case steal the HIP host's connection. What will happen in this case
is implementation dependent but such a request should fail by is implementation dependent but such a request should fail by
being ignored or dropped. Even if the attack were successful, being ignored or dropped. Even if the attack were successful,
the HIP host could reclaim its connection via HIP. the HIP host could reclaim its connection via HIP.
4. A HIP host attempts to steal a non-HIP host's session. A HIP 4. A HIP host attempts to steal a non-HIP host's session. A HIP
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 simple address via an UPDATE. Other possibilities exist, but a solution
solution is to prevent the use of HIP address check information is to prevent the local redirection of sessions that were
to influence non-HIP sessions. previously using an unverified address, but outside of the
existing HIP context, into the HIP SAs until the address change
can be verified.
7. IANA Considerations 7. IANA Considerations
The following changes to the "Host Identity Protocol (HIP) The following changes to the "Host Identity Protocol (HIP)
Parameters" registries are requested. Parameters" registries are requested.
The existing Parameter Type of 'LOCATOR' (value 193) should be The existing Parameter Type of 'LOCATOR' (value 193) should be
renamed to 'LOCATOR_SET' and the reference should be updated from renamed to 'LOCATOR_SET' and the reference should be updated from
RFC5206 to this specification. RFC5206 to this specification.
skipping to change at page 30, line 22 skipping to change at page 31, line 26
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-09 Registration Extension", draft-ietf-hip-rfc5203-bis-10
(work in progress), June 2015. (work in progress), January 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-07 (work
in progress), December 2015. in progress), December 2015.
[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>.
skipping to change at page 33, line 11 skipping to change at page 34, line 11
| | changed one informative reference from RFC 4423-bis to | | | changed one informative reference from RFC 4423-bis to |
| | RFC 7401 | | | RFC 7401 |
| | | | | |
| | removed discussion about possible multiple LOCATOR_SET | | | removed discussion about possible multiple LOCATOR_SET |
| | and ESP_INFO parameters in an UPDATE (per previous | | | and ESP_INFO parameters in an UPDATE (per previous |
| | 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 |
+----------+--------------------------------------------------------+ +----------+--------------------------------------------------------+
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. 34 change blocks. 
117 lines changed or deleted 133 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/