Fast HIP Host Mobility
HTT Consulting
Oak Park
MI
48237
USA
rgm@labs.htt-consult.com
AX Enterprize
4947 Commercial Drive
Yorkville
NY
13495
USA
stu.card@axenterprize.com
AX Enterprize
4947 Commercial Drive
Yorkville
NY
13495
USA
adam.wiethuechter@axenterprize.com
Internet
HIP
RFC
Request for Comments
I-D
Internet-Draft
HIP
This document describes mobility scenarios and how to aggressively
support them in HIP. The goal is minimum lag in the mobility
event.
Introduction
This document expands on HIP Host Mobility to
describe a set of mobility scenarios that can be addressed by
mechanisms that accelerate the basic HIP mobility UPDATE exchange.
HIP Host Mobility
performs a return address validation to ensure that the UPDATE
address is reachable by the peer. Two reasons are given for this
approach: middleboxes blocking return reachability and malicious
peers providing false address updates to flood a target.
The approach here is to start using the new address while it is
being validated. Worst case is a few packets are lost or sent to a
wrong target. These are acceptable risks while gaining a fast
address update that works in most cases.
One mechanism used 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.
Another mechanism expands the use of the VIA_RVS parameter to
"shotgun" mobility UPDATEs. These and other optimizations will be
covered in detail.
Terms and Definitions
Requirements Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY",
and "OPTIONAL" in this document are to be interpreted as described
in BCP 14 when, and only when, they
appear in all capitals, as shown here.
Definitions
- MTU:
-
The Maximum Transmit Unit or maximum number of bytes in a
datagram that the Interface supports.
- SPI:
-
The Security Parameter Index.
Problem Space
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.
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.
Apriori 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 .
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. 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.
Enhanced availability of VIA_RVS
The VIA_RVS parameter is defined in HIP Rendezvous Extension 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 Initiator. 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.
Single move mobility
Data traffic between host A and B may use ESP with HIP or any other tunneling
protocol. In ESP the relationship of the tunnel SAs with the HIP
SA puts a high level of trust on the following fast mobility.
Piggybacking impact on transport window size
The following sections define the operation of a HIP UPDATE payload
followed by some transport (e.g. TCP or UDP) payload in a single IP
datagram. This multicontent IP datagram works best with a smaller
window size for the higher layer. The normal operation is to
compare the size of the transport datagram plus HIP UPDATE payload
and ensure it is less than the MTU. An implementation may be able
to adjust the transport window size downward so that the higher
layer could still fill it and the whole piece then still fit within
the MTU.
Environment
-
Host A is mobile.
-
Host B may be mobile, but not changing IP address at this time.
-
Only Host A is moving in the network and changing its IP address.
-
Host A and B share a HIP Security Association.
-
Host A and B are registered to a RVS server, not
necessarily the same and each has the others RVS address.
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.
Scenario 2: Host A has data to transmit
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)
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.
The ESP anti-replay window managed by its envelope sequence number
can protect against replayed UPDATE+ESP packets prior to address
verification.
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.
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.
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.
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.
Environment
-
Both host A and B are mobile.
-
Host A and B share a HIP Security Association.
-
Both hosts move in the network and change their IP
addresses. Before either receives the others HIP mobility
UPDATE.
-
Host A and B are registered to a RVS server, not
necessarily the same and each has the others RVS address.
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.
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.
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.
IPv6 datagram + HIP UPDATE > MTU
Same process as
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.
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.
Security Considerations
HIP fast mobility does not introduce any new security
considerations beyond that in HIP Host Mobility. If anything its
requirement to know and use the RVS for a peer improve the
frequency of a successful mobility notification.
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.
References
Normative References
Informative References