HIP R. Moskowitz
Internet-Draft X. Xu
Intended status: Standards Track B. Liu
Expires: March 30, 2017 Huawei
September 26, 2016
Fast HIP Host Mobility
draft-moskowitz-hip-fast-mobility-00.txt
Abstract
This document describes mobility scenarios and how to aggressively
support them in HIP. The goal is minimum lag in the mobility event.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on March 30, 2017.
Copyright Notice
Copyright (c) 2016 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Moskowitz, et al. Expires March 30, 2017 [Page 1]
Internet-Draft Fast HIP Mobility September 2016
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terms and Definitions . . . . . . . . . . . . . . . . . . . . 3
2.1. Requirements Terminology . . . . . . . . . . . . . . . . 3
2.2. Definitions . . . . . . . . . . . . . . . . . . . . . . . 3
3. Problem Space . . . . . . . . . . . . . . . . . . . . . . . . 3
3.1. Time to complete move . . . . . . . . . . . . . . . . . . 3
3.2. A Priori move knowledge . . . . . . . . . . . . . . . . . 3
4. Enhanced availability of VIA_RVS . . . . . . . . . . . . . . 4
5. Single move mobility . . . . . . . . . . . . . . . . . . . . 4
5.1. Environment . . . . . . . . . . . . . . . . . . . . . . . 5
5.2. Scenario 1: Neither host has data to transmit . . . . . . 5
5.3. Scenario 2: Host A has data to transmit . . . . . . . . . 5
5.3.1. IPv6 datagram + HIP UPDATE > MTU . . . . . . . . . . 5
5.3.2. IPv6 datagram + HIP UPDATE <= MTU . . . . . . . . . . 5
5.4. Scenario 3: Host B has data to transmit . . . . . . . . . 6
5.4.1. IPv6 datagram + HIP UPDATE > MTU . . . . . . . . . . 6
5.4.2. IPv6 datagram + HIP UPDATE <= MTU . . . . . . . . . . 6
6. Double-Jump mobility . . . . . . . . . . . . . . . . . . . . 6
6.1. Environment . . . . . . . . . . . . . . . . . . . . . . . 6
6.2. Shotgunning UPDATEs . . . . . . . . . . . . . . . . . . . 7
6.3. Neither host has data to transmit . . . . . . . . . . . . 7
6.4. Either host has data to transmit . . . . . . . . . . . . 7
6.4.1. IPv6 datagram + HIP UPDATE > MTU . . . . . . . . . . 7
6.4.2. IPv6 datagram + HIP UPDATE <= MTU . . . . . . . . . . 7
7. Special considerations when used with IPnHIP . . . . . . . . 7
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
9. Security Considerations . . . . . . . . . . . . . . . . . . . 8
10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 8
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 8
11.1. Normative References . . . . . . . . . . . . . . . . . . 8
11.2. Informative References . . . . . . . . . . . . . . . . . 9
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9
1. Introduction
This document expands on HIP Host Mobility [I-D.ietf-hip-rfc5206-bis]
to describe a set of mobility scenarios that can be addressed by
mechanisms that accelerate the basic HIP mobility UPDATE exchange.
One mechanism used here is to piggyback data using Next Header even
while the mobile peer address is flagged UNVERIFIED. This is
practical as the new peer address is authenticated by the HIP_MAC in
UPDATE. The UPDATE can neither be forged nor can it be replayed.
The verification is more to ensure reverse reachability particularly
across NATs and firewalls.
Moskowitz, et al. Expires March 30, 2017 [Page 2]
Internet-Draft Fast HIP Mobility September 2016
Another mechanism expands the use of the VIA_RVS parameter to
"shotgun" mobility UPDATEs. These and other optimizations will be
covered in detail.
2. Terms and Definitions
2.1. Requirements Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119].
2.2. Definitions
MTU: The Maximum Transmit Unit or maximum number of bytes in a
datagram that the Interface supports.s
SPI: The Security Parameter Index.
3. Problem Space
3.1. Time to complete move
Most mobility environments are built with a "break then make" model
for connectivity. Thus there is measurable time between the old
address being unusable and the new address being functional. Adding
mobility convergence times just further aggravates the delay which
negatively impacts the user experience.
The "make then break" model for connectivity is supported via HIP
multihoming and is the subject of a separate recommendation.s
HIP mobility relies on a 3 packet UPDATE exchange which in some cases
can be optimized to 2 packets. This can be further delayed in a
"double-jump" scenario with waiting for the direct connection to fail
before falling over to contacting the peer's RVS. These processes
have resulted in other technologies to be preferred over HIP as they
have faster convergence even if they achieve this while sacrificing
security.
3.2. A Priori move knowledge
A HIP Host that has the potential to 'move' (acquire a new address
for an interface) during the lifetime of a HIP association SHOULD be
registered to an RVS. Such a HIP host SHOULD always inform its peer
of its RVS address, as it may experience a "Double-Jump" move as in
Section 6.
Moskowitz, et al. Expires March 30, 2017 [Page 3]
Internet-Draft Fast HIP Mobility September 2016
In an RVS assisted base exchange, the Responder ensures the Initiator
knows its RVS with the VIA_RVS parameter in the R1 as specified in
HIP Rendezvous Extension [I-D.ietf-hip-rfc5204-bis]. However, the
Responder has no mechanism to learn the Initiator's RVS address.
Additionally, it is possible for an Initiator to directly contact the
Responder and thus not learn about the Responder's RVS in the base
exchange.
A host may not publish its RVS if it does not wish to be easily
discovered. It still should notify its peers of its RVS if it
expects to be found in some move scenarios.
The HIP base exchange needs to include more RVS information.
4. Enhanced availability of VIA_RVS
The VIA_RVS parameter is defined in HIP Rendezvous Extension
[I-D.ietf-hip-rfc5204-bis] for use in R1, but only identifies the
Responder's RVS to the Initiator when the I1 was routed through the
RVS.
Firstly, a Responder SHOULD always provide its VIA_RVS information in
R1 even when the I1 came directly from the Initator. Secondly, the
Initiator SHOULD always provide its VIA_RVS information in I2. The
VIA_RVS address is always maintained as part of the HIT to IP
addressing information. Through these two expansions in the
availability of VIA_RVS, the hosts are assured to possess their
peer's RVS address to "shotgun" UPDATEs and thus accelerate mobility.
5. Single move mobility
Data traffic between host A and B may use ESP with HIP [RFC7402] or
IPnIP [RFC2004] (or other tunneling protocol). If ESP, the
relationship of the ESP SAs with the HIP SA puts a high level of
trust on the following fast mobility. With IPnIP, the risk is
similar to MIPv6. Adding a MAC of the IPnIP into the HIP UPDATE as
in Section 7 adds an additional level of validation during the fast
mobility.
Note: Next step is to develop a draft for IPnIP with HIP that will
have a SPI instead of the encapsulated IP address in the IPnIP
header. This will be called IPnHIP and will have security
characteristic beyond that in IPnIP with MobileIP.
Moskowitz, et al. Expires March 30, 2017 [Page 4]
Internet-Draft Fast HIP Mobility September 2016
5.1. Environment
o Host A is mobile.
o Host B may be mobile, but not changing IP address at this time.
o Only Host A is moving in the network and changing its IP address.
o Host A and B share a HIP Security Association.
o Host A and B are registered to a RVS server, not necessarily the
same and each has the others RVS address.
5.2. Scenario 1: Neither host has data to transmit
Host A triggers a HIP mobility UPDATE with Locator to inform Host B
of new address. Host B, upon validating Host A HIP UPDATE, continues
with Address Verification.
5.3. Scenario 2: Host A has data to transmit
5.3.1. IPv6 datagram + HIP UPDATE > MTU
Host A triggers a HIP mobility UPDATE with Locator to inform Host B
of new address. As the UPDATE + datagram would exceed the MTU, the
datagram is sent separately after receipt of the HIP UPDATE from Host
B.
The HIP UPDATE packets vary in length as follows:
Move notification: 302 bytes - UPDATE(ESP_INFO, LOCATOR, SEQ, HMAC,
HIP_SIGNATURE)
Move verification: 286 bytes - UPDATE(ESP_INFO, SEQ, ACK, HMAC,
HIP_SIGNATURE, ECHO_REQUEST_UNSIGNED)
Verification ack: 262 bytes - UPDATE(ESP_INFO, ACK, HMAC,
HIP_SIGNATURE, ECHO_RESPONSE_UNSIGNED)
5.3.2. IPv6 datagram + HIP UPDATE <= MTU
Host A sends HIP UPDATE with Locator to inform Host B of new address.
Datagram is appended to HIP UPDATE using Next Header. Host B, upon
validating Host A HIP UPDATE, sends next header to proper module and
continues with Address Verification. This datagram is processed even
though the address is UNVERIFIED.
Moskowitz, et al. Expires March 30, 2017 [Page 5]
Internet-Draft Fast HIP Mobility September 2016
The ESP and IPnHIP anti-replay window managed by their envelope
sequence number can protect against replayed UPDATE+ESP packets prior
to address verification.
5.4. Scenario 3: Host B has data to transmit
After Host B receives a HIP mobility UPDATE from A it has data to
send to A. Or Host B may have been sending data to Host A while Host
A was moving. The old data may have been lost; for example the data
is over UDP with no keepalives during the move time. The old data
may be in a retransmission state; for example the data is over TCP.
Or the data reached the interface from the higher layer at the same
time that the HIP UPDATE with new locator was successfully processed.
5.4.1. IPv6 datagram + HIP UPDATE > MTU
Host B sends the HIP UPDATE validation followed by the IPv6 datagram.
Host B may place the address in ACTIVE state or wait from HIP UPDATE
confirmation from Host A.
5.4.2. IPv6 datagram + HIP UPDATE <= MTU
Host B sends the HIP UPDATE validation within the IPv6 datagram.
Host B may place the address in ACTIVE state or wait from HIP UPDATE
confirmation from Host A.
6. Double-Jump mobility
The HIP mobility UPDATE will fail without the use of RVS. In fact
both RVS are needed for both UPDATEs to find its peer. This is why
the "shotgun" acceleration SHOULD always be used when the peer's RVS
is known.
6.1. Environment
o Both host A and B are mobile.
o Host A and B share a HIP Security Association.
o Both hosts move in the network and change their IP addresses.
Before either receives the others HIP mobility UPDATE.
o Host A and B are registered to a RVS server, not necessarily the
same and each has the others RVS address.
Moskowitz, et al. Expires March 30, 2017 [Page 6]
Internet-Draft Fast HIP Mobility September 2016
6.2. Shotgunning UPDATEs
Shotgunning is the process of sending the same UPDATE to more than
one LOCATOR. In particular it refers to sending the UPDATE to at
least the peer's last known IP address and to its RVS address learned
from the VIA_RVS for either the R1 or I2 packet.
A host MUST be prepared to receive and discard multiple HIP mobility
UPDATEs. The duplicates will be readily identified as having the
same SEQ (UPDATE sequence umber).
Shotgunning SHOULD always be used when an RVS is known. A peer never
knows of a "double-jump" event until after it receives its peer's
UPDATE.
6.3. Neither host has data to transmit
Host A triggers a HIP mobility UPDATE with Locator to inform Host B
of new address. Host B, upon validating Host A HIP UPDATE, continues
with Address Verification.
No attempt should be made to piggyback the two UPDATE processes.
They may run simultaneously but not in the same IP datagrams.
6.4. Either host has data to transmit
The following acceleration advice presents a number of challenges.
The best rule of thumb is to send the data as soon as possible.
6.4.1. IPv6 datagram + HIP UPDATE > MTU
Same process as Section 6.3
6.4.2. IPv6 datagram + HIP UPDATE <= MTU
Host A sends HIP UPDATE with Locator to inform Host B of new address.
Datagram is appended to HIP UPDATE using Next Header. Host B, may
have already sent a datagram with its original HIP UPDATE. If since
then a receipt of Host A's UPDATE it has more data to transmit, upon
validating Host A HIP UPDATE, sends next header to proper module and
continues with Address Verification. This datagram is processed even
though the address is UNVERIFIED.
7. Special considerations when used with IPnHIP
IPnHIP has superior resiliency to attack over IPnIP [RFC2004] as it
uses an ESP-styled sequence number and the HIP SPI rather than the
encapsulated IP addresses. Still a host SHOULD use the PAYLOAD_MIC
Moskowitz, et al. Expires March 30, 2017 [Page 7]
Internet-Draft Fast HIP Mobility September 2016
from HICCUPS [RFC6078] whenever an IPnHIP datagram is appended to a
HIP mobility UPDATE. This effectively blocks any substitution
attack. It also lengthens the HIP UPDATE by 24 bytes which may
result in NOT being able to append the IPnHIP datagram and stay
within the MTU.
Use of the PAYLOAD_MIC is a recommendation and not a requirement.
The risk of bloating the UPDATE packet such that the IPnHIP payload
cannot be carried in the same datagram may be reason enough not to
use it.
8. IANA Considerations
The following change to the "Host Identity Protocol (HIP) Parameters"
registries has been made:
The PAYLOAD_MIC parameter used here is defined in HICCUPS which is an
Experimental RFC. Here it is being used in a Standards Track
document.
9. Security Considerations
HIP fast mobility does not introduce any new security considerations
beyond that in HIP Host Mobility [I-D.ietf-hip-rfc5206-bis]. If
anything its requirement to know and use the RVS for a peer improve
the frequency of a successful mobility notification.
10. Acknowledgments
The term "shotgun" for fast mobility comes from the InfraHIP project.
The HIP UPDATE lengths were supplied by Jeff Ahrenholz.
Sue Hares of Huawei and Jeff Ahrenholz of Tempered Networks
contributed to the clarity in this document.
11. References
11.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>.
Moskowitz, et al. Expires March 30, 2017 [Page 8]
Internet-Draft Fast HIP Mobility September 2016
11.2. Informative References
[I-D.ietf-hip-rfc5203-bis]
Laganier, J. and L. Eggert, "Host Identity Protocol (HIP)
Registration Extension", draft-ietf-hip-rfc5203-bis-11
(work in progress), August 2016.
[I-D.ietf-hip-rfc5204-bis]
Laganier, J. and L. Eggert, "Host Identity Protocol (HIP)
Rendezvous Extension", draft-ietf-hip-rfc5204-bis-08 (work
in progress), August 2016.
[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-13
(work in progress), September 2016.
[RFC2004] Perkins, C., "Minimal Encapsulation within IP", RFC 2004,
DOI 10.17487/RFC2004, October 1996,
<http://www.rfc-editor.org/info/rfc2004>.
[RFC6078] Camarillo, G. and J. Melen, "Host Identity Protocol (HIP)
Immediate Carriage and Conveyance of Upper-Layer Protocol
Signaling (HICCUPS)", RFC 6078, DOI 10.17487/RFC6078,
January 2011, <http://www.rfc-editor.org/info/rfc6078>.
[RFC7343] Laganier, J. and F. Dupont, "An IPv6 Prefix for Overlay
Routable Cryptographic Hash Identifiers Version 2
(ORCHIDv2)", RFC 7343, DOI 10.17487/RFC7343, September
2014, <http://www.rfc-editor.org/info/rfc7343>.
[RFC7401] Moskowitz, R., Ed., Heer, T., Jokela, P., and T.
Henderson, "Host Identity Protocol Version 2 (HIPv2)",
RFC 7401, DOI 10.17487/RFC7401, April 2015,
<http://www.rfc-editor.org/info/rfc7401>.
[RFC7402] Jokela, P., Moskowitz, R., and J. Melen, "Using the
Encapsulating Security Payload (ESP) Transport Format with
the Host Identity Protocol (HIP)", RFC 7402,
DOI 10.17487/RFC7402, April 2015,
<http://www.rfc-editor.org/info/rfc7402>.
Authors' Addresses
Moskowitz, et al. Expires March 30, 2017 [Page 9]
Internet-Draft Fast HIP Mobility September 2016
Robert Moskowitz
Huawei
Oak Park, MI 48237
USA
Email: rgm@htt-consult.com
Xiaohu Xu
Huawei
Huawei Bld, No.156 Beiqing Rd.
Beijing, Hai-Dian District 100095
China
Email: xuxiaohu@huawei.com
Bingyang Liu
Huawei
Huawei Bld, No.156 Beiqing Rd.
Beijing, Hai-Dian District 100095
China
Email: xuxiaohu@huawei.com
Moskowitz, et al. Expires March 30, 2017 [Page 10]