💾 Archived View for gemini.bortzmeyer.org › rfc-mirror › rfc4866.txt captured on 2024-05-26 at 16:49:31.
⬅️ Previous capture (2021-11-30)
-=-=-=-=-=-=-
Network Working Group J. Arkko
Request for Comments: 4866 Ericsson Research NomadicLab
Category: Standards Track C. Vogt
Universitaet Karlsruhe (TH)
W. Haddad
Ericsson Research
May 2007
Enhanced Route Optimization for Mobile IPv6
Status of This Memo
This document specifies an Internet standards track protocol for the
Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the "Internet
Official Protocol Standards" (STD 1) for the standardization state
and status of this protocol. Distribution of this memo is unlimited.
Copyright Notice
Copyright (C) The IETF Trust (2007).
Abstract
This document specifies an enhanced version of Mobile IPv6 route
optimization, providing lower handoff delays, increased security, and
reduced signaling overhead.
Table of Contents
1. Introduction ....................................................3
2. Objectives ......................................................4
2.1. Handoff Latency ............................................5
2.2. Security ...................................................5
2.3. Signaling Overhead .........................................7
3. Protocol Design .................................................7
3.1. Cryptographically Generated Home Addresses .................7
3.2. Non-Cryptographic Care-of Addresses ........................8
3.3. Semi-Permanent Security Associations .......................8
3.4. Initial Home Address Tests .................................8
3.5. Concurrent Care-of Address Tests ...........................9
3.6. Credit-Based Authorization .................................9
3.7. Parallel Home and Correspondent Registrations .............10
4. Protocol Operation .............................................10
4.1. Sending Binding Update Messages ...........................10
4.2. Receiving Binding Update Messages .........................18
4.3. Sending Binding Acknowledgment Messages ...................22
Arkko, et al. Standards Track [Page 1]
RFC 4866 Enhanced Route Optimization May 2007
4.4. Receiving Binding Acknowledgment Messages .................23
4.5. Sending CGA Parameters ....................................25
4.6. Receiving CGA Parameters ..................................26
4.7. Sending Permanent Home Keygen Tokens ......................27
4.8. Receiving Permanent Home Keygen Tokens ....................28
4.9. Renewing Permanent Home Keygen Tokens .....................28
4.10. Handling Payload Packets .................................28
4.11. Credit Aging .............................................31
4.12. Simultaneous Movements ...................................32
5. Option Formats and Status Codes ................................32
5.1. CGA Parameters Option .....................................32
5.2. Signature Option ..........................................33
5.3. Permanent Home Keygen Token Option ........................34
5.4. Care-of Test Init Option ..................................35
5.5. Care-of Test Option .......................................35
5.6. CGA Parameters Request Option .............................36
5.7. Status Codes ..............................................36
6. Security Considerations ........................................38
6.1. Home Address Ownership ....................................39
6.2. Care-of Address Ownership .................................41
6.3. Credit-Based Authorization ................................43
6.4. Time Shifting Attacks .....................................46
6.5. Replay Attacks ............................................47
6.6. Resource Exhaustion .......................................47
6.7. IP Address Ownership of Correspondent Node ................47
7. Protocol Constants and Configuration Variables .................49
8. IANA Considerations ............................................50
9. Acknowledgments ................................................50
10. References ....................................................51
10.1. Normative References .....................................51
10.2. Informative References ...................................51
Arkko, et al. Standards Track [Page 2]
RFC 4866 Enhanced Route Optimization May 2007
1. Introduction
Mobile IPv6 route optimization [1] enables mobile and correspondent
nodes to communicate via a direct routing path despite changes in IP
connectivity on the mobile node side. Both end nodes use a stable
"home address" in identifying the mobile node at stack layers above
IP, while payload packets are sent or received via a "care-of
address" that routes to the mobile node's current network attachment.
Mobile IPv6 swaps the home and care-of addresses when a payload
packet traverses the IP layer. The association between a mobile
node's home address and care-of address is called a "binding" for the
mobile node. It is the responsibility of the mobile node to update
its binding at the correspondent node through a "correspondent
registration" when it changes IP connectivity. A correspondent
registration further involves the mobile node's home agent, which
proxies the mobile node at the home address and mainly serves as a
relay for payload packets exchanged with correspondent nodes that do
not support route optimization. The mobile node keeps the home agent
up to date about its current care-of address by means of "home
registrations".
From a security perspective, the establishment of a binding during a
correspondent registration requires the correspondent node to verify
the mobile node's ownership of both the home address and the care-of
address. Unprecedented impersonation and flooding threats [5] would
arise if correspondent nodes took liberties with respect to these
obligations. A correspondent registration hence incorporates a "home
address test" and a "care-of address test", collectively called the
"return routability procedure". These tests allow the correspondent
node to probe the mobile node's reachability at the home and care-of
addresses in an ad hoc, non-cryptographic manner. Successful
reachability verification at both IP addresses indicates (though it
does not guarantee) the mobile node's ownership of the IP addresses,
and hence that a binding between the home address and the care-of
address is legitimate.
The advantage of the return routability procedure is that it is
lightweight and does not depend on a public-key infrastructure or on
a preexisting relationship between the mobile node and the
correspondent node. This facilitates a broad deployment. On the
other hand, the procedure has an adverse impact on handoff delays
since both the home address test and the care-of address test consist
of an end-to-end message exchange between the mobile node and the
correspondent node. The latency of the home address test may be
particularly high because it routes through the home agent. The
return routability procedure is also vulnerable to attackers that are
in a position where they can interpose in the home or care-of address
test. The value of interposing is limited in that the return
Arkko, et al. Standards Track [Page 3]
RFC 4866 Enhanced Route Optimization May 2007
routability procedure must be repeated in intervals of at most 7
minutes, even in the absence of changes in IP connectivity on the
mobile node side. But this comes at the cost of an increased
signaling overhead. Much effort has therefore gone into improvements
for Mobile IPv6 route optimization [6] that mitigate these
disadvantages.
This document specifies Enhanced Route Optimization, an amendment to
route optimization in base Mobile IPv6. Enhanced Route Optimization
secures a mobile node's home address against impersonation through an
interface identifier that is cryptographically and verifiably bound
[2] to the public component of the mobile node's public/private-key
pair. The mobile node proves ownership of the home address by
providing evidence that it knows the corresponding private key. An
initial home address test validates the home address prefix;
subsequent home address tests are unnecessary. Enhanced Route
Optimization further allows mobile and correspondent nodes to resume
bidirectional communications in parallel with pursuing a care-of
address test. The latency of the home and care-of address tests are
therefore eliminated in most cases. The use of cryptographically
generated home addresses also mitigates the threat of impersonators
that can interpose on the home address test and thereby facilitate
longer binding lifetimes. This leads to increased security and a
reduction in signaling overhead. Cryptographically generated home
addresses and concurrent care-of address tests are preferably applied
together, but a mobile node may choose to use only one of these
enhancements.
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 [3].
2. Objectives
The design of route optimization in base Mobile IPv6 is in many ways
conservative, leaving room to optimize handoff delay, security, and
signaling overhead. Enhanced Route Optimization tackles these issues
and thus constitutes a more progressive variant of Mobile IPv6.
Despite any Mobile IPv6 optimizations, it is important to take into
account that mobility-related activities elsewhere in the protocol
stack may have their own impact. For example, attachment procedures,
access control, and authentication at the link layer contribute their
own handoff delays. So do IP layer tasks such as router discovery,
neighbor discovery, movement detection, and IP address configuration.
The handoff delays and signaling overhead of Mobile IPv6 are
Arkko, et al. Standards Track [Page 4]
RFC 4866 Enhanced Route Optimization May 2007
typically small compared to the total delay and overhead. The
improvements of Enhanced Route Optimization hence ought to be seen in
view of the entire protocol stack.
2.1. Handoff Latency
The typical handoff delay in base Mobile IPv6 route optimization is
one round-trip time between the mobile node and the home agent for
the home registration, one round-trip time between the mobile node
and the home agent plus one round-trip time between the home agent
and the correspondent node for the return routability procedure, and
one one-way time from the mobile node to the correspondent node for
the propagation of the Binding Update message. (The assumption here
is that the latency of the return routability procedure is dominated
by the home address test.) The first payload packet sent to the new
care-of address requires one additional one-way time to propagate
from the correspondent node to the mobile node. The mobile node can
resume transmissions right after it has dispatched the Binding Update
message. But if it requests a Binding Acknowledgment message from
the correspondent node, communications are usually delayed until this
is received.
Handoff delays in base Mobile IPv6 route optimization are additive to
other delays at the IP layer or link layer. They can cause
perceptible quality degradations for interactive and real-time
applications. TCP bulk-data transfers are likewise affected since
long handoff latencies may lead to successive retransmission timeouts
and degraded throughput [7]. An objective of Enhanced Route
Optimization is hence a reduction of the handoff latency.
2.2. Security
The return routability procedure was designed with the objective to
provide a level of security that compares to that of today's non-
mobile Internet [5]. As such, it protects against impersonation,
denial-of-service, and flooding threats that do not exist in the non-
mobile Internet, but that the introduction of mobility would
introduce in the absence of appropriate countermeasures. In
particular, the return routability procedure satisfies the following
requirements:
o An attacker off the path from a correspondent node to a victim
should not be able to trick a correspondent node into redirecting
packets, which should normally be delivered to a victim, to
itself, or to a third IP address. The attacker could otherwise
impersonate the victim to the correspondent node or cause denial
of service against the victim. The attacker may launch these
Arkko, et al. Standards Track [Page 5]
RFC 4866 Enhanced Route Optimization May 2007
attacks from an arbitrary position, which would not necessarily
have to be on the path between the victim and the correspondent
node.
o An attacker off the path from a correspondent node to a victim
should not be able to trick the correspondent node into
redirecting packets, which should normally be delivered to the
attacker itself, to the victim. The attacker could otherwise
flood the victim with unrequested packets. Such "redirection-
based flooding" may be appealing to the attacker because the
burden of generating the flooding packets and sending them to the
victim would be on the correspondent node rather than on the
attacker. The attacker could spoof multiple correspondent nodes
into flooding the same victim. This would enable the attacker to
impact the victim much stronger than with a direct flooding
attack, where the attacker itself would generate and send the
flooding packets. Comparable amplification is today only possible
through an army of compromised nodes [8]. One way to cause
redirection-based flooding is this: The attacker could accomplish
the initial TCP handshake for a voluminous file download through
its own IP address, and subsequently bind the victim's IP address
(as a care-of address) to the attacker's own IP address (or home
address). The correspondent node thereby redirects the download
to the victim. The attacker could spoof acknowledgments on behalf
of the victim based on the sequence numbers it learned during the
initial handshake in order to maintain or accelerate the download.
The acknowledgments would be smaller and typically less than the
full-sized segments that the correspondent node generates, hence
facilitating the amplification.
o Attackers should not be able to cause denial of service against
mobile or correspondent nodes through exploiting expensive
computations involved in the mobility protocol.
The return routability procedure precludes impersonation, denial of
service, and redirection-based flooding by attackers that are not on
the path from a correspondent node to a victim, and it is
sufficiently lightweight not to expose expensive operations. But the
return routability procedure fails to protect against attackers that
are located on the path from the correspondent node to the victim.
Applications that require a higher security level are generally
advised to use end-to-end protection such as IP security (IPsec) or
Transport Layer Security (TLS). But even then are they vulnerable to
denial of service or flooding. Furthermore, end-to-end security
mechanisms generally require mobile and correspondent nodes to be
preconfigured with authentication credentials, or they depend on a
public-key infrastructure. Both would hinder a wide deployment of
Mobile IPv6 route optimization if it was a prerequisite for the
Arkko, et al. Standards Track [Page 6]
RFC 4866 Enhanced Route Optimization May 2007
protocol. An objective of Enhanced Route Optimization is hence to
securely authenticate mobile nodes without preconfigured credentials
or a public-key infrastructure, even in the presence of attackers on
the path from the correspondent node to the victim.
2.3. Signaling Overhead
A complete correspondent registration involves six message
transmissions at the mobile node, totaling about 376 bytes [9]. This
signaling overhead may be acceptable if movements are infrequent.
For example, a mobile node that moves once every 30 minutes generates
an average of 1.7 bits/s of signaling traffic. Higher mobility
causes more substantial overhead, however. A cell size of 100 meters
and a speed of 120 km/h yields a change in IP connectivity every 3 s
and about 1,000 bits/s of signaling traffic. This is significant
compared to a highly compressed voice stream with a typical data rate
of 10,000 to 30,000 bits/s.
Furthermore, base Mobile IPv6 requires mobile nodes to renew a
correspondent registration at least every 7 minutes. The signaling
overhead amounts to 7.16 bits/s if the mobile node communicates with
a stationary node [9]. It doubles if both peers are mobile. This
overhead may be negligible when the nodes communicate, but it can be
an issue for mobile nodes that are inactive and stay at the same
location for a while. These nodes typically prefer to go to standby
mode to conserve battery power. Also, the periodic refreshments
consume a fraction of the wireless bandwidth that one could use more
efficiently. These observations lead to the objective of Enhanced
Route Optimization to reduce the signaling overhead of a base Mobile
IPv6 correspondent registrations as much as possible, in particular
when the mobile node does not move for a while.
3. Protocol Design
Enhanced Route Optimization consists of a set of optimizations that
collectively afford the achievement of the objectives discussed in
Section 2. These optimizations are summarized in the following.
3.1. Cryptographically Generated Home Addresses
A Mobile IPv6 binding is conceptually a packet redirection from a
home address to a care-of address. The home address is the source of
the redirection and the care-of address is the destination. The
packets to be redirected can hence be identified based on the home
address. This motivates a cryptographic ownership proof for the home
address. Enhanced Route Optimization applies cryptographically
generated home addresses for this purpose [10][11]. In general, a
Cryptographically Generated Address (CGA) provides a strong,
Arkko, et al. Standards Track [Page 7]
RFC 4866 Enhanced Route Optimization May 2007
cryptographic binding between its interface identifier and the CGA
owner's public key. This facilitates a cryptographic home address
ownership proof without a public-key infrastructure, enabling other
nodes to securely and autonomously authenticate the CGA owner as
such, modulo the correctness of the CGA's subnet prefix.
Cryptographically generated home addresses can supersede home address
tests with the exception of an initial test for validating the home
address prefix. This facilitates lower handoff delays and longer
binding lifetimes, as well as reduced signaling overhead for mobile
nodes that temporarily do not move. Enhanced Route Optimization also
optionally enables the correspondent node to prove ownership of its
IP address.
3.2. Non-Cryptographic Care-of Addresses
In contrast to a home address, a care-of address does not have
identifying functionality. There is hence little benefit in a
cryptographic ownership proof of a care-of address. Given that the
care-of address is the destination of a packet redirection, it is
rather the mobile node's reachability at the care-of address that
matters. Enhanced Route Optimization uses care-of address tests for
this purpose, but allows correspondent nodes to send packets to a new
care-of address before the mobile node has been found to be reachable
there.
3.3. Semi-Permanent Security Associations
CGA-based authentication involves public-key cryptography and is
hence computationally much less efficient than authentication through
a shared secret key. The technique further requires a substantial
amount of supplementary CGA parameters to be piggybacked onto
protected messages. Enhanced Route Optimization mitigates these
disadvantages in that it utilizes an initial CGA-based authentication
to securely exchange a secret permanent home keygen token between a
mobile node and a correspondent node. The permanent home keygen
token is used to authenticate the mobile node more efficiently in
subsequent correspondent registrations. Mobile and correspondent
nodes renew the permanent home keygen token on an infrequent basis.
The token is therefore neither constant nor short-lived, which is why
the security association between the mobile node and the
correspondent node is called "semi-permanent".
3.4. Initial Home Address Tests
An initial home address test is necessary despite a cryptographic
proof of home address ownership to protect against spoofed subnet
prefixes in home addresses. In the complete absence of home address
tests, a malicious node could cryptographically generate a home
Arkko, et al. Standards Track [Page 8]
RFC 4866 Enhanced Route Optimization May 2007
address with the subnet prefix of a victim network, and request a
correspondent node to register a binding between this spoofed home
address and the attacker's own care-of address. The attacker then
tricks the correspondent node into sending a stream of packets to the
care-of address and subsequently deregisters the binding or lets it
expire. The consequence is that the correspondent node redirects the
packet stream "back" to the home address, causing the victim network
to be flooded with unrequested packets. To preclude such misuse, an
initial home address test is required for the mobile node and the
correspondent node to establish a semi-permanent security
association. The home address test is, if possible, executed in
proactive manner so as to save a potentially costly message exchange
via the home agent during the critical handoff period. The home
address test does not need to be repeated upon subsequent movements.
3.5. Concurrent Care-of Address Tests
Enhanced Route Optimization allows a correspondent node to send
payload packets to a mobile node's new care-of address before the
mobile node has been found to be reachable at the care-of address.
When the mobile node changes IP connectivity, it first updates its
binding at the correspondent node to the new care-of address without
providing a proof of reachability. The correspondent node registers
the new care-of address on a tentative basis and sets it to
UNVERIFIED state. Payload packets can then be exchanged
bidirectionally via the new care-of address, while the mobile node's
reachability at the new care-of address is verified concurrently.
The correspondent node moves the care-of address to VERIFIED state
once reachability verification completes.
3.6. Credit-Based Authorization
Concurrent care-of address tests without additional protection would
enable an attacker to trick a correspondent node into temporarily
redirecting payload packets, which would otherwise be addressed to
the attacker itself, to the IP address of a victim. Such
"redirection-based flooding" [5] may be appealing to the attacker
because the correspondent node (not the attacker) generates the
flooding packets and sends them to the victim. This enables the
attacker to amplify the strength of the attack to a significant
degree compared to a direct flooding attack where the attacker itself
would generate the flooding packets.
Enhanced Route Optimization protects against redirection-based
flooding attacks through the use of Credit-Based Authorization.
Credit-Based Authorization manages the effort that a correspondent
node expends in sending payload packets to a care-of address in
UNVERIFIED state so as to ensure that a redirection-based flooding
Arkko, et al. Standards Track [Page 9]
RFC 4866 Enhanced Route Optimization May 2007
attack cannot be more effective than direct flooding. The ability to
send unrequested packets is an inherent property of packet-oriented
networks, and direct flooding is a threat that results from this.
Since direct flooding exists with and without mobility support, and
redirection-based flooding attacks cannot be any more efficient than
this, Credit-Based Authorization increases the security level
provided by Enhanced Route Optimization with respect to flooding to
that of the non-mobile Internet. Enhanced Route Optimization
therefore satisfies the objective to provide a security level
comparable to that of the non-mobile Internet.
The measuring and limiting of effort are technically realized through
the concept of "credit", which a correspondent node maintains to put
its own effort in relation to the effort that a mobile node expends
during regular communications with the correspondent node. The
correspondent node increases the credit for payload packets it
receives from a care-of address of the mobile node in VERIFIED state,
and it reduces the credit in proportion to its own effort for sending
payload packets to a care-of address of the mobile node in UNVERIFIED
state.
3.7. Parallel Home and Correspondent Registrations
Enhanced Route Optimization enables mobile nodes to pursue a
correspondent registration in parallel with the respective home
registration. This reduces handoff delays compared to base Mobile
IPv6, which requires mobile nodes to wait for a Binding
Acknowledgment message indicating a successful home registration
before they initiate a correspondent registration.
4. Protocol Operation
Enhanced Route Optimization allows a mobile node to securely
authenticate to a correspondent node based on the CGA property of its
home address, and to request a concurrent care-of address test for
increased handoff efficiency. Depending on whether the mobile node
wishes to take advantage of either or both of these enhancements, the
messages exchanged during a correspondent registration are different.
This is described in the following.
4.1. Sending Binding Update Messages
A mobile node may initiate a correspondent registration for any of
the following reasons:
o To establish a new binding at a correspondent node while away from
its home link so that subsequent packets will be route-optimized
and no longer be routed through the mobile node's home agent.
Arkko, et al. Standards Track [Page 10]
RFC 4866 Enhanced Route Optimization May 2007
o To update an existing binding at the correspondent node while
moving from one point of IP attachment to another.
o To follow up an early Binding Update message with a complete
Binding Update message after receiving a Binding Acknowledgment
message with a Care-of Test option.
o To refresh an existing binding at the correspondent node without
changing the current point of IP attachment.
o To request the correspondent node to renew an existing permanent
home keygen token shared between the mobile node and the
correspondent node (see Section 4.5).
o To request the correspondent node to deregister an existing
binding.
Mobile node Home agent Correspondent node
| | |
| | |
~ Handoff | |
| | |
|-Binding Update--------->| |
|-early Binding Update + Care-of Test Init option-->|
| | |
| | |
|<------------Binding Ack-| |
|<----------early Binding Ack + Care-of Test option-|
| | |
| | |
|-Binding Update----------------------------------->|
| | |
| | |
|<--------------------------------------Binding Ack-|
| | |
Figure 1: Correspondent registration with authentication by a proof
of the mobile node's knowledge of a permanent home keygen token;
concurrent care-of address test
In any of these cases, the mobile node sends a Binding Update message
to the correspondent node. The Binding Update message is
authenticated by one of the following three authentication methods:
o If the mobile node's home address is a CGA, but the mobile node
does not have a permanent home keygen token in its Binding Update
List entry for the correspondent node, the mobile node SHOULD
Arkko, et al. Standards Track [Page 11]
RFC 4866 Enhanced Route Optimization May 2007
authenticate the Binding Update message based on the CGA property
of its home address. This requires the mobile node to send its
CGA parameters and signature to the correspondent node and to pass
a check of reachability at the home address.
o If the mobile node's home address is a CGA, and the mobile node
has a permanent home keygen token in its Binding Update List entry
for the correspondent node, the mobile node MUST authenticate the
Binding Update message by a proof of its knowledge of the
permanent home keygen token.
o If the mobile node's home address is not a CGA, the mobile node
MUST authenticate the Binding Update message through a proof of
reachability at its home address.
The lifetime requested by the mobile node in the Lifetime field of
the Binding Update message MUST NOT exceed MAX_CGA_BINDING_LIFETIME
(see Section 7) if the Binding Update message is to be authenticated
based on the CGA property of the mobile node's home address or by a
proof of the mobile node's knowledge of a permanent home keygen
token. If the selected authentication method is a proof of the
mobile node's reachability at the home address, the lifetime MUST NOT
exceed MAX_RR_BINDING_LIFETIME [1]. It is RECOMMENDED in all cases
that the mobile node requests the maximum permitted lifetime in order
to avoid unnecessary binding refreshes and thus reduce signaling
overhead. The Lifetime field of a Binding Update message that
requests the deletion of an existing binding at the correspondent
node MUST be set to zero.
If the selected authentication method is by way of the CGA property
of the mobile node's home address, the mobile node includes its CGA
parameters and signature in the Binding Update message by adding one
or more CGA Parameters options (see Section 5.1) directly followed by
a Signature option (see Section 5.2). This is described in
Section 4.5. Once a permanent home keygen token has been obtained
from the correspondent node, the mobile node MUST authenticate all
subsequent Binding Update messages by a proof of its knowledge of
this permanent home keygen token until either the binding lifetime
expires, the permanent home keygen token is renewed, or the mobile
node explicitly deregisters the binding at the correspondent node.
This ensures that an attacker on the path from the correspondent node
to the mobile node's home address cannot downgrade the mobile node's
chosen authentication method to a proof of reachability at the home
address. The mobile node MAY choose to ignore the CGA property of
its home address and authenticate Binding Update messages through a
proof of reachability at the home address. However, this behavior
increases the vulnerability to on-path attackers and is therefore NOT
RECOMMENDED.
Arkko, et al. Standards Track [Page 12]
RFC 4866 Enhanced Route Optimization May 2007
Mobile node Home agent Correspondent node
| | |
| | |
|-Home Test Init--------->|------------------------>|
| | |
|<------------------------|<--------------Home Test-|
| | |
| | |
~ Handoff | |
| | |
|-Binding Update--------->| |
|-early Binding Update + Care-of Test Init option-->|
| | |
| | |
|<------------Binding Ack-| |
|<----------early Binding Ack + Care-of Test option-|
| | |
| | |
|-Binding Update----------------------------------->|
| | |
| | |
|<--------------------------------------Binding Ack-|
| | |
Figure 2: Correspondent registration with authentication based on
reachability verification at the home address; concurrent care-of
address test
The mobile node also includes its CGA parameters in the Binding
Update message when it intends to renew an existing permanent home
keygen token shared with the correspondent node. This is
accomplished, as before, by adding to the message one or more CGA
Parameters options and a Signature option.
The authenticator for the Binding Update message is calculated based
on a permanent or temporary home keygen token. Which type of home
keygen token the mobile node uses in calculating the authenticator
depends on the authentication method:
o If the Binding Update message is to be authenticated based on the
CGA property of the mobile node's home address, the mobile node
MUST use a temporary home keygen token from the correspondent
node. The mobile node may already have a valid temporary home
keygen token in its Binding Update List entry for the
correspondent node, or it may retrieve one through the exchange of
a Home Test Init message and a Home Test message.
Arkko, et al. Standards Track [Page 13]
RFC 4866 Enhanced Route Optimization May 2007
o If the Binding Update message is to be authenticated by a proof of
the mobile node's knowledge of a permanent home keygen token, the
mobile node MUST use the permanent home keygen token that is has
in its Binding Update List entry for the correspondent node.
o If the Binding Update message is to be authenticated through a
proof of reachability at the home address, the mobile node MUST
use a temporary home keygen token from the correspondent node. As
before, the mobile node may already have a valid temporary home
keygen token in its Binding Update List entry for the
correspondent node, or it may retrieve one through the exchange of
a Home Test Init message and a Home Test message.
Unless the purpose of the Binding Update message is to delete an
existing binding at the correspondent node, the authenticator is also
calculated based on a care-of keygen token. The mobile node selects
this as follows:
o If the mobile node has a valid care-of keygen token for the to-be-
registered care-of address in its Binding Update List entry for
the correspondent node, the mobile node MUST use this in
calculating the authenticator for the Binding Update message. The
Binding Update message is in this case "complete".
o If the mobile node does not have a valid care-of keygen token in
its Binding Update List entry for the correspondent node, the
mobile node SHOULD define the care-of keygen token to be zero and
use this in calculating the authenticator for the Binding Update
message. The Binding Update message is in this case "early".
o If the mobile node does not have a valid care-of keygen token in
its Binding Update List entry for the correspondent node, the
mobile node MAY choose to retrieve a care-of keygen token through
the exchange of a Care-of Test Init message and a Care-of Test
message, as defined in [1], without sending an early Binding
Update message. In this case, the mobile node waits for receipt
of the Care-of Test message and uses the care-of
keygen token contained therein in calculating the authenticator
for a complete Binding Update message. This approach increases
the handoff latency, however, and is therefore NOT RECOMMENDED.
For reduced handoff delays, the mobile node SHOULD simultaneously
initiate home and correspondent registrations for a particular
care-of address. The mobile node SHOULD also pursue home and
correspondent deregistrations in parallel if it wishes to discontinue
Mobile IPv6 service while away from its home link. However, when the
mobile node commits home and correspondent deregistrations after
returning back to the home link after a period of roaming, the mobile
Arkko, et al. Standards Track [Page 14]
RFC 4866 Enhanced Route Optimization May 2007
node MUST initiate the home deregistration first, and it MUST wait
for a Binding Acknowledgment message indicating a successful home
deregistration before it initiates the correspondent deregistration.
This behavior ensures that the home agent does not proxy the mobile
node's home address while the mobile node is on the home link, hence
preventing interference between the mobile node and the home agent
during Duplicate Address Detection. Since a home deregistration
consumes only a link-local round-trip time when the mobile node
pursues it from the home link, the cost of not parallelizing it with
a correspondent deregistration, in terms of increased handoff delay,
is typically negligible.
Moreover, when the Binding Update message for the correspondent
registration is to be authenticated based on the CGA property of the
mobile node's home address or through a proof of reachability at the
home address, the mobile node SHOULD initiate the exchange of Home
Test Init and Home Test messages prior to handoff in order to
proactively elicit a fresh home keygen token from the correspondent
node. This reduces handoff delays further. A Home Test Init message
may be sent periodically whenever the home keygen token previously
acquired from the correspondent node is about to expire. Tokens are
valid for 3.5 minutes [1], so the interval between successive Home
Test Init messages should be a little less. Alternatively, the
mobile node may be able to send the Home Test Init message right in
time if its link layer provides a trigger announcing imminent
handoff. Proactive home address tests are technically feasible
because a home address does not change across handoffs.
If the mobile node initiates the home address test from the home
link, it MUST address the Home Test Init message directly to the
correspondent node. The Home Test message will then be received
directly from the correspondent node. If the home address test is
initiated from a visited link, the mobile node MUST tunnel the Home
Test Init message to the home agent. The Home Test message will then
be tunneled back to the mobile node by the home agent. A home
address test SHOULD NOT overlap with a home registration or home
deregistration since this could result in the loss of the Home Test
Init or Home Test message.
If the Binding Update message is early, the mobile node MUST add a
Care-of Test Init option (see Section 5.4) to the message, requesting
the correspondent node to return a new care-of keygen token. The
Care-of Test Init option MUST follow the CGA Parameters and Signature
options, if those exist in the Binding Update message. Once a
responding Binding Acknowledgment message with a Care-of Test option
(see Section 5.5) is received, the mobile node MUST use the care-of
Arkko, et al. Standards Track [Page 15]
RFC 4866 Enhanced Route Optimization May 2007
keygen token contained therein in calculating the authenticator for a
complete Binding Update message and send this message to the
correspondent node.
If the Binding Update message is authenticated based on the CGA
property of the mobile node's home address, the mobile node MAY add a
CGA Parameters Request option (see Section 5.6) to the Binding Update
message so as to request the correspondent node to prove ownership of
its IP address within the Binding Acknowledgment message. This
ownership proof enables the mobile node to verify that the permanent
home keygen token returned in the Binding Acknowledgment message was
generated by the right correspondent node.
The mobile node includes the nonce indices associated with the
selected home and care-of keygen tokens in the Binding Update message
using a Nonce Indices option [1]. The home nonce index is thereby
determined as follows:
o If the Binding Update message is to be authenticated based on the
CGA property of the mobile node's home address, the mobile node
uses a temporary home keygen token to calculate the authenticator
for the Binding Update message, and the associated home nonce
index MUST be taken from the Home Test message with which the home
keygen token was obtained.
o If the Binding Update message is to be authenticated by a proof of
the mobile node's knowledge of a permanent home keygen token, the
home nonce index MUST be set to zero.
o If the Binding Update message is to be authenticated through a
proof of the mobile node's reachability at the home address, the
mobile node uses a temporary home keygen token to calculate the
authenticator for the Binding Update message, and the associated
home nonce index MUST be taken from the Home Test message with
which the home keygen token was obtained.
The care-of nonce index is determined according to the following
rules:
o If the Binding Update message is complete, the care-of nonce index
is taken from the Care-of Test option or Care-of Test message with
which the care-of keygen token (used to calculate the
authenticator for the Binding Update message) was obtained.
o If the Binding Update message is early, the care-of nonce index
MUST be set to zero.
Arkko, et al. Standards Track [Page 16]
RFC 4866 Enhanced Route Optimization May 2007
o If the purpose of the Binding Update message is to delete a
binding at the correspondent node, the care-of nonce index MUST be
set to zero.
The Nonce Indices option follows the CGA Parameters, Signature,
Care-of Test Init, and CGA Parameters Request options if those are
included in the Binding Update message as well.
The mobile node finally calculates an authenticator for the Binding
Update message based on the selected home and care-of keygen tokens,
following the rules described in Section 5.2 and Section 6.2.7 of
[1]. For a Binding Update message that requests the deletion of an
existing binding at the correspondent node, the authenticator is
calculated based on only a home keygen token, and it does not
incorporate a care-of keygen token. The authenticator is placed into
the Authenticator field of a Binding Authorization Data option [1],
which the mobile node adds to the Binding Update message as the last
option.
Mobile node Home agent Correspondent node
| | |
| | |
~ Handoff | |
| | |
|-Binding Update--------->| |
|-Care-of Test Init-------------------------------->|
| | |
| | |
|<------------Binding Ack-| |
|<-------------------------------------Care-of Test-|
| | |
| | |
|-Binding Update----------------------------------->|
| | |
| | |
|<--------------------------------------Binding Ack-|
| | |
Figure 3: Correspondent registration with authentication by a proof
of the mobile node's knowledge of a permanent home keygen token;
explicit care-of address test
The time-sequence diagrams in Figure 1 through Figure 3 illustrate
the operation of Enhanced Route Optimization based on a few selected
message exchanges. Figure 1 shows the messages exchanged for a
correspondent registration where an early Binding Update message is
authenticated by a proof of the mobile node's knowledge of a
permanent home keygen token. A Care-of Test Init option in the early
Arkko, et al. Standards Track [Page 17]
RFC 4866 Enhanced Route Optimization May 2007
Binding Update message requests the correspondent node to add to the
Binding Acknowledgment message a fresh care-of keygen token in a
Care-of Test option. The mobile node finally concludes the
correspondent registration with a complete Binding Update message.
Figure 2 shows the procedure of a correspondent registration where
the Binding Update message is authenticated with a proof of
reachability at the home address. The home address test is
proactively performed prior to handoff, permitting the mobile node to
issue a Binding Update message directly after the handoff. The
Binding Update message is again early, and a care-of keygen token is
delivered to the mobile node along with the Binding Acknowledgment
message. Figure 3 depicts a correspondent registration where the
mobile node initially obtains a fresh care-of keygen token through
the dedicated exchange of Care-of Test Init and Care-of Test
messages. It subsequently issues a complete Binding Update message
that is authenticated with the CGA property of the home address.
4.2. Receiving Binding Update Messages
When the correspondent node receives a Binding Update message, it
must first verify whether the sending mobile node is the legitimate
owner of the home address specified in the message. The
correspondent node selects the authentication method based on the
home nonce index given in the Nonce Indices option of the Binding
Update message, and on the existence of CGA Parameters and Signature
options in the Binding Update message:
o If the home nonce index is set to a non-null value and the Binding
Update message includes one or more CGA Parameters options
followed by a Signature option, the correspondent node MUST
authenticate the Binding Update message based on the CGA property
of the mobile node's home address.
o If the home nonce index is zero and the Binding Update message
does not include one or more CGA Parameters options followed by a
Signature option, the correspondent node MUST authenticate the
Binding Update message by a proof of the mobile node's knowledge
of a permanent home keygen token.
o If the home nonce index is set to a non-null value and the Binding
Update message does not include one or more CGA Parameters options
followed by a Signature option, the correspondent node MUST
authenticate the Binding Update message through a proof of the
mobile node's reachability at the home address.
Arkko, et al. Standards Track [Page 18]
RFC 4866 Enhanced Route Optimization May 2007
In addition to the validation procedure for Binding Update messages
specified in [1], the correspondent node must take the following
additional steps to reject Binding Update messages that are
inappropriately authenticated:
o If the Binding Update message includes one or more CGA Parameters
options followed by a Signature option and the home nonce index is
zero, the correspondent node MUST send a Binding Acknowledgment
message with status code 150 ("Non-null home nonce index
expected"). This ensures that a Binding Update message that is
authenticated based on the CGA property of the mobile node's home
address must also provide a proof of the mobile node's
reachability at the home address.
o If the Binding Update message is to be authenticated by a proof of
the mobile node's knowledge of a permanent home keygen token, the
correspondent node MUST verify that it has a Binding Cache entry
for the mobile node that includes a permanent home keygen token.
In case the correspondent node does not have a Binding Cache entry
for the mobile node, or if the existing Binding Cache entry for
the mobile node does not include a permanent home keygen token,
the correspondent node MUST reject the Binding Update message by
sending a Binding Acknowledgment message with status code 147
("Permanent home keygen token unavailable").
o If the Binding Update message is to be authenticated through a
proof of the mobile node's reachability at the home address, the
correspondent node MUST verify that it does not have a permanent
home keygen token in its Binding Cache entry for the mobile node.
If the correspondent node has a permanent home keygen token in its
Binding Cache entry for the mobile node, it MUST reject the
Binding Update message by sending a Binding Acknowledgment message
with status code 149 ("Permanent home keygen token exists"). This
ensures that an attacker cannot downgrade the authentication
method to hijack the binding of a legitimate mobile node.
The authenticator for the Binding Update message is calculated based
on a permanent or temporary home keygen token. Which type of home
keygen token the correspondent node uses in validating the
authenticator, and how it retrieves or recomputes the home keygen
token, depends on the authentication method:
o If the Binding Update message is to be authenticated based on the
CGA property of the mobile node's home address, the correspondent
node MUST recompute the temporary home keygen token defined by the
(non-null) home nonce index in the Nonce Indices option of the
Binding Update message, and it MUST use this recomputed token in
validating the authenticator of the message.
Arkko, et al. Standards Track [Page 19]
RFC 4866 Enhanced Route Optimization May 2007
o If the Binding Update message is to be authenticated by a proof of
the mobile node's knowledge of a permanent home keygen token, the
correspondent node MUST use the permanent home keygen token that
it has in its Binding Cache entry for the mobile node in
validating the authenticator of the Binding Update message.
o If the Binding Update message is to be authenticated through
verification of the mobile node's reachability at the home
address, the correspondent node MUST recompute the temporary home
keygen token defined by the (non-null) home nonce index in the
Nonce Indices option of the Binding Update message, and it MUST
use this recomputed token in validating the authenticator of the
message.
Unless the purpose of the Binding Update message is to delete an
existing binding at the correspondent node, the authenticator is also
calculated based on a care-of keygen token. Which care-of keygen
token the correspondent node uses in validating the authenticator
depends on whether the Binding Update message is complete or early:
o If the care-of nonce index in the Nonce Indices option of the
Binding Update message is set to a non-null value, the Binding
Update message is complete. In this case, the correspondent node
MUST recompute the care-of keygen token that is identified by the
care-of nonce index, and it MUST use this recomputed token in
validating the authenticator of the message.
o If the care-of nonce index in the Nonce Indices option of the
Binding Update message is zero, the Binding Update message is
early. The care-of keygen token to be used by the correspondent
node in validating the authenticator of the Binding Update message
is zero in this case.
The correspondent node finally validates the authenticator in the
Binding Update message based on the selected home and care-of keygen
tokens, following the algorithm described in Section 9.5.1 of [1].
If the validation fails, the correspondent node MUST discard the
Binding Update message. The correspondent node may have to send a
Binding Acknowledgment message with a status code indicating the
failure, as described in [1].
Provided that the validation of the authenticator in the Binding
Update message succeeds, the correspondent node registers the mobile
node's new care-of address, either updating an existing Binding Cache
entry, if one exists, or creating a new Binding Cache entry. The
lifetime granted for the binding depends on the lifetime requested by
the mobile node in the Lifetime field of the Binding Update message
Arkko, et al. Standards Track [Page 20]
RFC 4866 Enhanced Route Optimization May 2007
and the method by which the Binding Update message is authenticated.
If the Binding Update message is authenticated based on the CGA
property of the mobile node's home address or by a proof of the
mobile node's knowledge of a permanent home keygen token, the
lifetime for the binding SHOULD be set to the maximum of
MAX_CGA_BINDING_LIFETIME and the value specified in the Lifetime
field of the Binding Update message. If the Binding Update message
is authenticated through a proof of the mobile node's reachability at
the home address, then the lifetime for the binding SHOULD be set to
the maximum of MAX_RR_BINDING_LIFETIME [1] and the value specified in
the Lifetime field of the Binding Update message. The correspondent
node may in either case grant a further reduced lifetime, but it MUST
NOT accept a higher lifetime.
The state of the new care-of address depends on whether the Binding
Update message is complete or early:
o If the Binding Update message is complete, the new care-of address
is set to VERIFIED state. The correspondent node may then
immediately send packets to the new care-of address without
restrictions.
o If the Binding Update message is early, the new care-of address is
set to UNVERIFIED state. The correspondent node MUST then follow
the rules defined in Section 4.10 for sending packets to this
care-of address until the care-of address is set in VERIFIED
state.
If the Binding Update message contains one or multiple CGA Parameters
options, the mobile node is requesting the correspondent node to
accept the included CGA parameters either for establishing a new, or
for renewing an existing permanent home keygen token shared between
the mobile node and the correspondent node. The correspondent node
MUST in this case check if the CGA Parameters options are directly
followed by a Signature option and, if so, validate the CGA
parameters and signature as described in Section 4.6.
If the CGA Parameters option is not directly followed by a Signature
option, or the validation of the included CGA parameters and
signature fails, the correspondent node MUST discard the Binding
Update message and send a Binding Acknowledgment message with status
code 148 ("CGA and signature verification failed") to the mobile
node.
Provided that the signature included in the Signature option is
correct, the correspondent node generates a permanent home keygen
token to be shared with the mobile node and stores it in its Binding
Cache entry for the mobile node. The permanent home keygen token is
Arkko, et al. Standards Track [Page 21]
RFC 4866 Enhanced Route Optimization May 2007
sent to the mobile node within a Binding Acknowledgment message as
described in Section 4.3.
4.3. Sending Binding Acknowledgment Messages
Upon receipt of a valid Binding Update message, the correspondent
node returns to the mobile node a Binding Acknowledgment message in
any of the following cases:
o The Acknowledge flag in the Binding Update message is set.
o The Binding Update message contains one or multiple CGA Parameters
options directly followed by a Signature option, and the signature
included in the latter was determined to be correct.
o The Binding Update message is early and includes a Care-of Test
Init option.
If the Binding Update message further contains a CGA Parameters
Request option and the correspondent node's IP address is a CGA, the
correspondent node MUST include its CGA parameters and signature in
the Binding Acknowledgment message by adding one or more CGA
Parameters options directly followed by a Signature option. The
correspondent node's CGA parameters and signature enable the mobile
node to verify that the permanent home keygen token received in the
Binding Acknowledgment message was generated by the right
correspondent node. If the Binding Update message contains a CGA
Parameters Request option, but the correspondent node's IP address is
not a CGA, the correspondent node ignores the CGA Parameters Request
option and processes the Binding Update message further as described
below.
If the Binding Update message contains one or multiple CGA Parameters
options directly followed by a Signature option, and the signature
included in the latter was determined to be correct, the
correspondent node MUST add a Permanent Home Keygen Token option (see
Section 5.3) with a new permanent home keygen token to the Binding
Acknowledgment message. The correspondent node also stores this
permanent home keygen token in its Binding Cache entry for the mobile
node.
If the Binding Update message includes a Care-of Test Init option,
the correspondent node MUST append to the Binding Acknowledgment
message a Care-of Test option with a pseudo-random value in the
Care-of Keygen Token field. The Care-of Test option MUST appear
after the Permanent Home Keygen Token option in case both options are
present in the Binding Acknowledgment message.
Arkko, et al. Standards Track [Page 22]
RFC 4866 Enhanced Route Optimization May 2007
A Binding Authorization Data option must be added to the Binding
Acknowledgment message as a last option, as described in Section 5.2
and Section 6.2.7 of [1].
4.4. Receiving Binding Acknowledgment Messages
A mobile node first verifies a received Binding Acknowledgment
message according to the rules specified in [1]. Provided that the
Binding Acknowledgment message is not rejected based on these rules,
the mobile node takes the following additional steps.
If the mobile node included a CGA Parameters Request option in the
Binding Update message and the Binding Acknowledgment message
contains a Permanent Home Keygen Token option, the mobile node first
processes any CGA Parameters and Signature options in the Binding
Acknowledgment message in the following manner. If the Binding
Acknowledgment message contains one or more CGA Parameters options
that are directly followed by a Signature option, the mobile node
MUST check the ownership of the correspondent node's IP address by
verifying the included CGA parameters and signature as described in
Section 4.6. If the validation of the CGA parameters and signature
fails, the mobile node MUST silently discard the Binding
Acknowledgment message. The mobile node MUST also silently discard
the Binding Acknowledgment message if the message includes one or
more CGA Parameters options that are not directly followed by a
Signature option, or if the Binding Acknowledgment message lacks any
CGA Parameters options in the presence of a Signature option.
If the mobile node did not include a CGA Parameters Request option in
the Binding Update message or the Binding Acknowledgment message does
not contain a Permanent Home Keygen Token option, the mobile node
ignores any CGA Parameters and Signature options that the Binding
Acknowledgment message may contain. Careful use of the CGA
Parameters Request option in Binding Update messages enables the
mobile node to control the processing resources it spends on the
verification of a correspondent node's CGA as well as to disable such
verification in the case of persistent verification failures, which
may be due to misconfigured or outdated CGA software [12] on the
correspondent node side or at the mobile node itself. Specifically,
if the mobile node repeatedly fails to receive a Binding
Acknowledgment message including valid CGA Parameters and Signature
options in response to sending a Binding Update message with a CGA
Parameters Request option, the mobile node SHOULD refrain from
including a CGA Parameters Request option in future Binding Update
messages for the same correspondent node.
Arkko, et al. Standards Track [Page 23]
RFC 4866 Enhanced Route Optimization May 2007
If the mobile node included a CGA Parameters Request option in the
Binding Update message, but the Binding Acknowledgment message does
not contain any CGA Parameters or Signature options, the mobile node
cannot be sure if the correspondent node's IP address is simply not a
CGA, or if the Binding Acknowledgment message originates from an
attacker on the path from the mobile node to the correspondent node.
To avoid accepting a permanent home keygen token from an on-path
attacker, the mobile node MUST give precedence to Binding
Acknowledgment messages that include valid CGA Parameters and
Signature options over Binding Acknowledgment messages without such
options. One possible algorithm for the mobile node to follow in
this regard is to always accept the Binding Acknowledgment message
received first, and if this message does not contain valid CGA
Parameters or Signature options and another Binding Acknowledgment
message including such options is received later on, to revert any
state changes involved in accepting the first Binding Acknowledgment
in favor of this subsequent Binding Acknowledgment message. Giving
precedence to Binding Acknowledgment messages with valid CGA
Parameters and Signature options over Binding Acknowledgment messages
without such options enables the mobile node to communicate with
correspondent nodes that do not use a CGA, and at the same time
protects against most on-path attackers. The strategy does not
protect against an attacker that can intercept Binding Acknowledgment
messages from the correspondent node, but such an attacker could
preclude mobility management between the mobile node and the
correspondent node anyway. When the mobile node has permanently
accepted a Binding Acknowledgment message without valid CGA
Parameters and Signature options, the mobile node SHOULD refrain from
including a CGA Parameters Request option in future Binding Update
messages for the same correspondent node.
If the Binding Acknowledgment message contains a Permanent Home
Keygen Token option, the mobile node extracts the permanent home
keygen token included in this option and stores it in its Binding
Update List entry for the correspondent node. Future Binding Update
messages will then be authenticated by a proof of the mobile node's
knowledge of this permanent home keygen token.
If the Binding Acknowledgment message contains a Care-of Test option,
the mobile node extracts the care-of keygen token included in this
option, stores the token in its Binding Update List entry for the
correspondent node, and sends the correspondent node a complete
Binding Update message as defined in Section 4.1. Note that the
complete Binding Update message will be authenticated based on the
CGA property of the mobile node's home address if the Binding
Acknowledgment message also includes a Permanent Home Keygen Token
option. This is independent of the authentication method that was
used for the corresponding early Binding Update message.
Arkko, et al. Standards Track [Page 24]
RFC 4866 Enhanced Route Optimization May 2007
A mobile node MUST ensure that, while it has a binding for a certain
home address at a correspondent node, it also has a valid binding at
its home agent for the same home address. This may at times require
the mobile node to extend the binding lifetime at the home agent,
request a correspondent node to use a binding lifetime less than the
permitted maximum, or explicitly deregister an existing binding at a
correspondent node.
If the mobile node authenticates Binding Update messages for a
particular correspondent node by proving its knowledge of a permanent
home keygen token, but registrations at this correspondent node
persistently fail, the mobile node SHOULD renew the permanent home
keygen token by sending a Binding Update message that is
authenticated based on the CGA property of its home address. This
Binding Update message includes the mobile node's CGA parameters and
signature, and it requests the correspondent node to generate a new
permanent home keygen token and send this to the mobile node within a
Binding Acknowledgment message.
If the mobile node persistently receives Binding Acknowledgment
messages with status code 148 ("CGA and signature verification
failed") from a correspondent node, the mobile node SHOULD
authenticate future Binding Update messages for the same
correspondent nodes through a proof of its reachability at the home
address. This enables the mobile node to recover from misconfigured
or outdated CGA software [12] on the correspondent node side or at
the mobile node itself.
4.5. Sending CGA Parameters
A mobile node includes its CGA parameters and signature in a Binding
Update message for a correspondent node in any of the following
situations:
o To acquire a permanent home keygen token if the mobile node's home
address is a CGA, and the mobile node does not yet have a
permanent home keygen token from the correspondent node.
o To extend the lifetime of an existing binding if the mobile node
already has a permanent home keygen token from the correspondent
node, and the lifetime of the binding at the correspondent node is
about to expire.
o To renew an existing permanent home keygen token to prevent replay
attacks in the imminent event of a sequence number rollover, or
for improved protection against cryptanalysis.
Arkko, et al. Standards Track [Page 25]
RFC 4866 Enhanced Route Optimization May 2007
A correspondent node whose IP address is a CGA includes its CGA
parameters and signature in a Binding Acknowledgment message for the
mobile node when it receives a Binding Update message with a CGA
Parameters Request option.
CGA parameters are transmitted in the format of the CGA Parameters
data structure defined in [2]. The CGA Parameters data structure is
split over one or more CGA Parameters options as described in
Section 5.1. The last CGA Parameters option MUST be directly
followed by a Signature option.
The value for the Signature field in the Signature option is
calculated according to the signature generation algorithm defined in
Section 6 of [2]. The value is calculated with the mobile or
correspondent node's private key over the following sequence of
octets:
mobility data =
care-of address | correspondent node IP address | MH data
where "|" denotes concatenation. "Care-of address" is the mobile
node's care-of address, and "correspondent node IP address" is the IP
address of the correspondent node that is visible to protocol layers
above IP. In case the correspondent node is mobile, "correspondent
node IP address" refers to the correspondent node's home address.
"MH data" is the content of the Binding Update or Binding
Acknowledgment message including the mobility header and all options
up to the last CGA Parameters option. That is, "MH data" excludes
the IPv6 header and any IPv6 extension headers other than the
mobility header itself. The "mobility data" constitutes what is
referred to as the "message" in Section 6 of [2].
The value for the Signature field is calculated as if the Checksum
field in the mobility header was zero. The Checksum field in the
transmitted packet is still calculated in the usual manner, with the
calculated value in the Signature field being a part of the packet
protected by the checksum.
4.6. Receiving CGA Parameters
Mobile and correspondent nodes that receive a Binding Update or
Binding Acknowledgment message including one or more CGA Parameters
options directly followed by a Signature option first process the
message as described in [1]. This includes a verification of the
authenticator in the Authenticator field of the Binding Authorization
Data option. If the Binding Update or Binding Acknowledgment message
is rejected due to an incorrect authenticator or for any other
reason, the message is not processed further.
Arkko, et al. Standards Track [Page 26]
RFC 4866 Enhanced Route Optimization May 2007
Otherwise, if the validation of the Binding Update or Binding
Acknowledgment message succeeds, the mobile or correspondent node
reassembles the CGA Parameters data structure from the CGA Parameters
options included in the message as described in Section 5.1, and
executes the CGA verification algorithm defined in Section 5 of [2].
The CGA verification algorithm takes the to-be-verified CGA and the
reassembled CGA Parameters data structure as input. The to-be-
verified CGA is the mobile node's home address when the CGA
verification algorithm is executed by the correspondent node. When
the mobile node executes the CGA verification algorithm, the to-be-
verified CGA is the correspondent node's IP address that is visible
to protocol layers above IP. This is the correspondent node's home
address in case the correspondent node is mobile. The following
steps are skipped if the CGA verification fails.
If the CGA verification succeeds, the mobile or correspondent node
performs a more time-consuming check of the signature. It extracts
the signature from the Signature field in the Signature option and
executes the signature verification algorithm defined in Section 6 of
[2]. The signature verification algorithm takes as input the to-be-
verified CGA as defined above, the reassembled CGA Parameters data
structure, the MH data as defined in Section 4.5, the CGA Message
Type tag of Enhanced Route Optimization as defined in Section 7, and
the signature itself.
4.7. Sending Permanent Home Keygen Tokens
A correspondent node assigns a mobile node a new permanent home
keygen token after it has received from the mobile node a Binding
Update message with included CGA Parameters and Signature options,
and these options have been successfully validated as described in
Section 4.6. The permanent home keygen token is a 64-bit value
randomly generated by the correspondent node. The correspondent node
stores the permanent home keygen token in the binding cache entry
that it maintains for the mobile node.
The correspondent node sends the permanent home keygen token to the
mobile node in encrypted form within a Permanent Home Keygen Token
option in a Binding Acknowledgment message. It sends this message
even if the Acknowledge flag in the corresponding Binding Update
message was clear. The correspondent node encrypts the permanent
home keygen token with the mobile node's public key using the
RSAES-PKCS1-v1_5 format [4], and places the ciphertext into the
Permanent Home Keygen Token field of the Permanent Home Keygen Token
option.
The Binding Authorization Data option MUST be the last option in the
Binding Acknowledgment message. That is, the authenticator in the
Arkko, et al. Standards Track [Page 27]
RFC 4866 Enhanced Route Optimization May 2007
Binding Authorization Data option covers the Permanent Home Keygen
Token option.
4.8. Receiving Permanent Home Keygen Tokens
A mobile node that receives a Binding Acknowledgment message first
processes the message as described in [1], independent of whether the
message includes a Permanent Home Keygen Token option. This includes
a verification of the authenticator in the Authenticator field of the
Binding Authorization Data option. If the Binding Acknowledgment
message is rejected due to an incorrect authenticator or for any
other reason, the mobile node does not process the message further.
Otherwise, if the mobile node accepts the Binding Acknowledgment
message and the message includes a Permanent Home Keygen Token
option, the mobile node extracts the ciphertext from the Permanent
Home Keygen Token field in this option and decrypts it with its
private key using the RSAES-PKCS1-v1_5 format [4]. The result of the
encryption is the permanent home keygen token to be used in further
registrations with the correspondent node. The mobile node stores
the permanent home keygen token in the Binding Update List entry that
it maintains for the correspondent node.
4.9. Renewing Permanent Home Keygen Tokens
A mobile node that shares a permanent home keygen token with a
correspondent node MUST NOT use the same sequence number twice with
this permanent home keygen token in order to protect against replay
attacks. The mobile node MUST renew the permanent home keygen token
by including its CGA parameters and signature in a Binding Update
message for the correspondent node when a sequence number rollover is
imminent. In addition, the mobile node MAY renew its permanent home
keygen token at any time. Periodic renewal of the permanent home
keygen token provides increased protection against cryptanalysis.
Finally, the mobile node may in most cases want to renew the
permanent home keygen token when the lifetime of its binding at the
correspondent node expires.
4.10. Handling Payload Packets
The immediate exchange of an early Binding Update message after a
handoff on the mobile node side enables mobile and correspondent
nodes to quickly reestablish route-optimized communications via the
mobile node's new care-of address. The mobile node may send payload
packets to the correspondent node from the new care-of address as
soon as it has dispatched the early Binding Update message. The
correspondent node redirects outgoing payload packets for the mobile
node to the new care-of address once it has received the early
Arkko, et al. Standards Track [Page 28]
RFC 4866 Enhanced Route Optimization May 2007
Binding Update message and registered the new care-of address. Here,
a "payload packet" is defined as a packet that originates at a
protocol layer above IP.
Inbound
payload packet
|
|
V
_________________ _____________________
/ \ | |
/ Care-of address \ Yes | Increase credit |
| in |---------------------> | counter by |
\ VERIFIED state? / | payload packet size |
\_________________/ |_____________________|
| |
| |
| No |
| V
| _____________________
| | |
| | Deliver payload |
+--------------------------------> | packet to upper- |
| layer protocol |
|_____________________|
Figure 4: Handling outbound payload packets
A new care-of address that was registered with an early Binding
Update message is maintained in UNVERIFIED state by the correspondent
node until the correspondent node receives a complete Binding Update
message from the mobile node. The correspondent node then sets the
care-of address to VERIFIED state. The state of the care-of address
determines the maximum amount of data that the correspondent node is
allowed to send to the care-of address, as is necessary to prevent
amplified, redirection-based flooding attacks. For this purpose, the
correspondent node maintains a "credit counter" for each mobile node
with an entry in its Binding Cache. Whenever a payload packet
arrives from a mobile node with a care-of address in VERIFIED state,
the correspondent node SHOULD increase the mobile node's credit
counter by the size of the received payload packet. The
correspondent node MAY be restricted by policy to increase the credit
counter by a lower value or not to increase the credit at all. The
credit counter does not change when an inbound payload packet is
received from a care-of address in UNVERIFIED state. Figure 4 shows
a flow chart of this procedure.
Arkko, et al. Standards Track [Page 29]
RFC 4866 Enhanced Route Optimization May 2007
Outbound
payload packet
|
|
V
_________________ _____________________
/ \ | |
/ Care-of address \ Yes | Send payload |
| in |---------------------> | packet to |
\ VERIFIED state? / | care-of address |
\_________________/ |_____________________|
|
| _____________________
| No | |
| | Discard payload |
| +---------> | packet |
| | | immediately |
V | |_____________________|
_________________ | _____________________
/ \ | | |
/ Credit counter \ Yes / \ | Send payload |
| less than payload |-------> | |-------> | packet to |
\ packet size? / \ / | home address |
\_________________/ | |_____________________|
| | _____________________
| | | |
| No | | Buffer payload |
| +---------> | packet for |
| | later transmission |
| |_____________________|
V
_____________________ _____________________
| | | |
| Reduce credit | | Send payload |
| counter by |---------------------> | packet to |
| payload packet size | | care-of address |
|_____________________| |_____________________|
Figure 5: Handling outbound payload packets
When the correspondent node has a payload packet to send to the
mobile node, further treatment of the payload packet depends on the
state of the mobile node's care-of address and the current value of
the mobile node's credit counter, as illustrated in Figure 5: The
correspondent node MUST send the payload packet to the mobile node's
care-of address if the care-of address is in VERIFIED state. If the
care-of address is in UNVERIFIED state and the value of the credit
counter is higher than or equal to the size of the payload packet,
Arkko, et al. Standards Track [Page 30]
RFC 4866 Enhanced Route Optimization May 2007
the correspondent node MUST reduce the mobile node's credit counter
by the size of the payload packet and send the payload packet to the
care-of address as well. However, if the care-of address is in
UNVERIFIED state and the credit counter is less than the size of the
payload packet, the payload packet MUST NOT be sent to the mobile
node's care-of address. The correspondent node SHOULD then discard
the payload packet, although it MAY alternatively buffer the payload
packet until the care-of address moves to VERIFIED state, or send the
payload packet to the mobile node's home address. The credit counter
of the mobile node does not change when the correspondent node sends
a payload packet to the mobile node's care-of address while the
care-of address is in VERIFIED state.
The amount of data that the mobile node may send to the correspondent
node is never restricted due to the state of the mobile node's
care-of address. The care-of address state also does not change the
addressing and routing of payload packets in either traffic
direction: All payload packets that originate from the mobile node
have the care-of address in the Source Address field of the IPv6
header and the home address in the Home Address option of the IPv6
Destination Options extension header. Vice versa, all payload
packets from the correspondent node have the care-of address in the
Destination Address field of the IPv6 header and the home address in
the IPv6 Routing extension header.
4.11. Credit Aging
A correspondent node ensures that all credit counters that it
maintains gradually decrease over time. Each credit counter is
multiplied with a factor, CreditAgingFactor, of less than one in
fixed time intervals of CreditAgingInterval length. Such "credit
aging" limits the total credit that a mobile node can earn, provided
that the replenishing rate for the credit is constant or nearly
constant. It thereby enforces an upper bound on the rate at which
the correspondent node can durably sent to the mobile node's care-of
address while the care-of address is in UNVERIFIED state. In the
absence of credit aging, a malicious node with poor up-link capacity
could adopt the role of a mobile node, build up credit at a very slow
speed and over a long period, and spend this credit during a much
shorter period on redirecting a burst of payload packets to the IP
address of a victim.
Choosing appropriate values for CreditAgingFactor and
CreditAgingInterval is important to facilitate applications where the
correspondent node sends at a higher rate than the mobile node. If
CreditAgingFactor or CreditAgingInterval is too small, the credit
counter might persistently prevent the transmission of payload
packets to a care-of address in UNVERIFIED state. The values given
Arkko, et al. Standards Track [Page 31]
RFC 4866 Enhanced Route Optimization May 2007
in Section 7 are RECOMMENDED as they work well when the correspondent
node transfers a file to the mobile node via a TCP connection and the
end-to-end round-trip time does not exceed 500 milliseconds.
4.12. Simultaneous Movements
As specified in [1], Binding Update messages are sent to a mobile
correspondent node's home address. This makes it possible for two
mobile nodes to continue communications even if both of them change
IP connectivity at the same time.
5. Option Formats and Status Codes
Enhanced Route Optimization uses a set of new mobility options and
status codes in addition to the mobility options and status codes
defined in [1]. These are described below.
5.1. CGA Parameters Option
The CGA Parameters option is used in Binding Update and Binding
Acknowledgment messages. It contains part of the mobile or
correspondent node's CGA parameters. [1] limits mobility header
options to a maximum length of 255 bytes, excluding the Option Type
and Option Length fields. Since the CGA parameters are likely to
exceed this limit, multiple CGA Parameters options may have to be
concatenated to carry all CGA parameters.
The format of the CGA Parameters option is as follows:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Option Type | Option Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
: :
: CGA Parameters :
: :
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Option Type
8-bit identifier of the type of this mobility option. Its value
is 12.
Arkko, et al. Standards Track [Page 32]
RFC 4866 Enhanced Route Optimization May 2007
Option Length
8-bit unsigned integer representing the length of the CGA
Parameters field in octets.
CGA Parameters
This field contains up to 255 bytes of the CGA Parameters data
structure defined in [2]. The concatenation of all CGA Parameters
options in the order they appear in the Binding Update message
MUST result in the original CGA Parameters data structure. All
CGA Parameters options in the Binding Update message except the
last one MUST contain exactly 255 bytes in the CGA Parameters
field, and the Option Length field MUST be set to 255 accordingly.
All CGA Parameters options MUST appear directly one after another,
that is, a mobility option of a different type MUST NOT be placed
in between two CGA Parameters options.
5.2. Signature Option
The Signature option is used in Binding and Binding Acknowledgment
Update messages. It contains a signature that the mobile or
correspondent node generates with its private key over one or more
preceding CGA Parameters options.
The format of the Signature option is as follows:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Option Type | Option Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
: :
: Signature :
: :
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Option Type
8-bit identifier of the type of this mobility option. Its value
is 13.
Option Length
8-bit unsigned integer representing the length of the Signature
field in octets.
Arkko, et al. Standards Track [Page 33]
RFC 4866 Enhanced Route Optimization May 2007
Signature
This field contains the mobile or correspondent node's signature,
generated with the mobile or correspondent node's private key as
specified in Section 4.5.
5.3. Permanent Home Keygen Token Option
The Permanent Home Keygen Token option is used in Binding
Acknowledgment messages. It contains a permanent home keygen token,
which the correspondent node sends to the mobile node after it has
received a Binding Update message containing one or more CGA
Parameters options directly followed by a Signature option from the
mobile node.
The format of the Permanent Home Keygen Token option is as follows:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Option Type | Option Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
: :
: Permanent Home Keygen Token :
: :
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Option Type
8-bit identifier of the type of this mobility option. Its value
is 14.
Option Length
8-bit unsigned integer representing the length of the Permanent
Home Keygen Token field in octets.
Permanent Home Keygen Token
This field contains the permanent home keygen token generated by
the correspondent node. The content of this field MUST be
encrypted with the mobile node's public key as defined in
Section 4.7. The length of the permanent home keygen token is 8
octets before encryption, though the ciphertext [4] and, hence,
the Permanent Home Keygen Token field may be longer.
Arkko, et al. Standards Track [Page 34]
RFC 4866 Enhanced Route Optimization May 2007
5.4. Care-of Test Init Option
The Care-of Test Init option is included in Binding Update messages.
It requests a correspondent node to return a Care-of Test option with
a fresh care-of keygen token in the Binding Acknowledgment message.
The format of the Care-of Test Init option is as follows:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Option Type | Option Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Option Type
8-bit identifier of the type of this mobility option. Its value
is 15.
Option Length
This field MUST be set to zero.
5.5. Care-of Test Option
The Care-of Test option is used in Binding Acknowledgment messages.
It contains a fresh care-of keygen token, which the correspondent
node sends to the mobile node after it has received a Care-of Test
Init option in a Binding Update message.
The format of the Care-of Test option is as follows:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Option Type | Option Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Care-of Keygen Token +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Option Type
8-bit identifier of the type of this mobility option. Its value
is 16.
Arkko, et al. Standards Track [Page 35]
RFC 4866 Enhanced Route Optimization May 2007
Option Length
This field MUST be set to 8. It represents the length of the
Care-of Keygen Token field in octets.
Care-of Keygen Token
This field contains the care-of keygen token generated by the
correspondent node, as specified in Section 4.3.
5.6. CGA Parameters Request Option
The CGA Parameters Request option is included in Binding Update
messages that are authenticated based on the CGA property of the
mobile node's home address. It requests a correspondent node to
return its CGA parameters and signature in the Binding Acknowledgment
message, enabling the mobile node to verify that the permanent home
keygen token returned in the Binding Acknowledgment message was
generated by the right correspondent node.
The format of the CGA Parameters Request option is as follows:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Option Type | Option Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Option Type
8-bit identifier of the type of this mobility option. Its value
is 11.
Option Length
This field MUST be set to zero.
5.7. Status Codes
Enhanced Route Optimization uses the following four new status codes
for Binding Acknowledgment messages in addition to the status codes
defined in [1]:
Permanent home keygen token unavailable (147)
A correspondent node returns a Binding Acknowledgment message with
status code 147 to a mobile node if it has received from the
mobile node a Binding Update message that was authenticated
Arkko, et al. Standards Track [Page 36]
RFC 4866 Enhanced Route Optimization May 2007
through the CGA property of the mobile node's home address, but
the correspondent node either does not have a Binding Cache entry
for the mobile node, or the existing Binding Cache entry for the
mobile node does not contain a permanent home keygen token. A
Binding Acknowledgment message with status code 147 indicates to
the mobile node that it should request a new permanent home keygen
token from the correspondent node by sending the correspondent
node a Binding Update message including its CGA parameters and
signature. This in particular enables the mobile node to quickly
recover from state loss at the correspondent node.
[1] does not allow a correspondent node to send a Binding
Acknowledgment message with a status code indicating failure when
the authenticator of a received Binding Update message turns out
to be incorrect. This causes additional handoff latency with high
probability because the mobile node can detect the problem only
after the expiration of a retransmission timer. The mobile node
is furthermore likely to assume packet loss and resend the
incorrectly authenticated Binding Update message additional times.
A Binding Acknowledgment message with status code 147 helps the
mobile node to identify the underlying problem more efficiently
when the correspondent node could not verify the CGA property of
the mobile node's home address.
CGA and signature verification failed (148)
A correspondent node returns a Binding Acknowledgment message with
status code 148 to a mobile node if it has received from the
mobile node a Binding Update message that includes one or more CGA
Parameters options directly followed by a Signature option, but
either the CGA property of the home address cannot be verified
based on the contents of the CGA Parameters options, or the
verification of the signature in the Signature option has failed.
Permanent home keygen token exists (149)
A correspondent node returns a Binding Acknowledgment message with
status code 149 to a mobile node if it has received from the
mobile node a Binding Update message that was authenticated
through verification of the mobile node's reachability at the home
address and does not include one or more CGA Parameters options
directly followed by a Signature option, but the correspondent
node has a permanent home keygen token in its Binding Cache entry
for the mobile node. The Binding Update message is processed
further if it includes one or more CGA Parameters options directly
followed by a Signature option. This enables a mobile node to
obtain a new permanent home keygen token from the correspondent
node in case it has lost the existing one, for instance, due to a
Arkko, et al. Standards Track [Page 37]
RFC 4866 Enhanced Route Optimization May 2007
reboot. Whether the correspondent node accepts the Binding Update
message in this case depends on the verification of the CGA
parameters and the signature provided in the Binding Update
message.
Non-null home nonce index expected (150)
A correspondent node returns a Binding Acknowledgment message with
status code 150 to a mobile node if it has received from the
mobile node a Binding Update message that includes one or more CGA
Parameters options directly followed by a Signature option, but
the home nonce index specified in the Nonce Indices option is
zero. This behavior ensures that a Binding Update message that is
authenticated based on the CGA property of the mobile node's home
address must also provide a proof of the mobile node's
reachability at the home address.
6. Security Considerations
Enhanced Route Optimization differs from base Mobile IPv6 in that it
applies a set of optimizations for increased handoff performance,
stronger security, and reduced signaling overhead. These
optimizations entail the following conceptual changes to the security
model [5] of base Mobile IPv6:
o Base Mobile IPv6 conducts periodic tests of a mobile node's
reachability at the home address as a proof of home address
ownership. Enhanced Route Optimization applies an initial
cryptographic home address ownership proof in combination with a
verification of the mobile node's reachability at the home address
in order to securely exchange a secret permanent home keygen
token. The permanent home keygen token is used for cryptographic
authentication of the mobile node during subsequent correspondent
registrations, so that these later correspondent registrations can
be securely bound to the initial home address ownership proof. No
further periodic reachability verification at the home address
tests is performed.
o Base Mobile IPv6 requires a mobile node to prove its reachability
at a new care-of address during a correspondent registration.
This implies that the mobile node and the correspondent node must
exchange Care-of Test Init and Care-of Test messages before the
mobile node can initiate the binding update proper. Enhanced
Route Optimization allows the mobile node to initiate the binding
update first and follow up with a proof of reachability at the
care-of address. Mobile and correspondent nodes can so resume
communications early on after a handoff, while reachability
verification proceeds concurrently. The amount of data that the
Arkko, et al. Standards Track [Page 38]
RFC 4866 Enhanced Route Optimization May 2007
correspondent node is permitted to send to the care-of address
until reachability verification completes is governed by Credit-
Based Authorization.
o The maximum binding lifetime for correspondent registrations is 7
minutes in base Mobile IPv6. A mobile node must hence
periodically refresh a correspondent registration in cases where
it does not change IP connectivity for a while. This protocol
increases the maximum binding lifetime to 24 hours, reducing the
need for periodic refreshes to a negligible degree.
The ensuing discussion addresses the implications that these
conceptual changes of the Mobile IPv6 security model have. The
discussion ought to be seen in context with the security
considerations of [1], [2], and [5].
6.1. Home Address Ownership
Enhanced Route Optimization requires a mobile node to deliver a
strong cryptographic proof [2] that it is the legitimate owner of the
home address it wishes to use. The proof is based on the true home
address owner's knowledge of the private component in a public/
private-key pair with the following two properties:
o As an input to an irreversible CGA generation function along with
a set of auxiliary CGA parameters, the public key results in the
mobile node's home address.
o Among the CGA parameters that are fed into the CGA generation
function is a modifier that, as an input to an irreversible hash
extension function along with the public key, results in a string
with a certain minimum number of leading zeroes. Three reserved
bits in the home address encode this minimum number.
The first property cryptographically binds the home address to the
mobile node's public key and, by virtue of public-key cryptography,
to the private key. It allows the mobile node to claim ownership of
the home address by proving its knowledge of the private key. The
second property increases the cost of searching in brute-force manner
for a public/private-key pair that suffices the first property. This
increases the security of a cryptographically generated home address
despite its limitation to 59 bits with cryptographic significance.
Solely enforcing the first property would otherwise allow an attacker
to find a suitable public/private-key pair in O(2^59) steps. By
addition of the second property, the complexity of a brute-force
search can be increased to O(2^(59+N)) steps, where N is the minimum
number of leading zeroes that the result of the hash extension
function is required to have.
Arkko, et al. Standards Track [Page 39]
RFC 4866 Enhanced Route Optimization May 2007
In practice, for a legitimate mobile node to cryptographically
generate a home address, the mobile node must first accomplish a
brute-force search for a suitable modifier, and then use this
modifier to execute the CGA generation function. An attacker who is
willing to spoof the mobile node's home address, so-called "IP
address stealing" [5], then has two options: It could either generate
its own public/private-key pair and perform a brute-force search for
a modifier which, in combination with the generated public key,
suffices the initially described two properties; or it could integer-
factor the mobile node's public key, deduce the corresponding private
key, and copy the mobile node's modifier without a brute-force
search. The cost of the attack can be determined by the mobile node
in either case: Integer-factoring a public key becomes increasingly
complex as the length of the public key grows, and the key length is
at the discretion of the mobile node. The cost of a brute-force
search for a suitable modifier increases with the number of leading
zeroes that the result of the hash extension function is required to
have. This number, too, is a parameter that the mobile node can
choose. Downgrading attacks, where the attacker reduces the cost of
spoofing a cryptographically generated home address by choosing a set
of CGA parameters that are less secure than the CGA parameters the
mobile node has used to generate the home address, are hence
impossible.
The CGA specification [2] requires the use of RSA public and private
keys, and it stipulates a minimum key length of 384 bits. This
requirement that was tailored to Secure Neighbor Discovery for IPv6
[13], the original CGA application. Enhanced Route Optimization does
not increase the minimum key length because, in the absence of
downgrading attacks as explained before, the ability to use short
keys does not compromise the security of home addresses that were
cryptographically generated using longer keys. Moreover, extensions
to [2] may eventually permit the use of public/private-key classes
other than RSA. Such extensions are compatible with the CGA
application of Enhanced Route Optimization. Care must be taken in
selecting an appropriate key class and length, however. Home
addresses are typically rather stable in nature, so the chosen
parameters must be secure for a potentially long home address
lifetime. Where RSA keys are used, a minimum key length of 1024 bits
is therefore RECOMMENDED.
While the CGA generation function cryptographically ties the
interface identifier of a home address to the subnet prefix of the
home address, the function accepts any subnet prefix and hence does
not prevent a node from cryptographically generating a home address
with a spoofed subnet prefix. As a consequence, the CGA property of
a home address does not guarantee the owner's reachability at the
home address. This could be misused for a "return-to-home flooding
Arkko, et al. Standards Track [Page 40]
RFC 4866 Enhanced Route Optimization May 2007
attack" [5], where the attacker uses its own public key to
cryptographically generate a home address with a subnet prefix from a
victim network, requests a correspondent node to bind this to the
attacker's current care-of address, initiates the download of a large
file via the care-of address, and finally deregisters the binding or
lets it expire. The correspondent node would then redirect the
packets being downloaded to the victim network identified by the
subnet prefix of the attacker's spoofed home address. The protocol
defined in this document performs a reachability test for the home
address at the time the home address is first registered with the
correspondent node. This precludes return-to-home flooding.
The verification of the CGA property of a mobile node's home address
involves asymmetric public-key cryptography, which is relatively
complex compared to symmetric cryptography. Enhanced Route
Optimization mitigates this disadvantage through the use of symmetric
cryptography after an initial public-key-based verification of the
mobile node's home address has been performed. Specifically, the
correspondent node assigns the mobile node a permanent home keygen
token during the initial correspondent registration based on which
the mobile node can authenticate to the correspondent node during
subsequent correspondent registrations. Such authentication enables
the correspondent node to bind a subsequent correspondent
registration back to the initial public-key-based verification of the
mobile node's home address. The permanent home keygen token is never
sent in plain text; it is encrypted with the mobile node's public key
when initially assigned, and irreversibly hashed during subsequent
correspondent registrations.
6.2. Care-of Address Ownership
A secure proof of home address ownership can mitigate the threat of
IP address stealing, but an attacker may still bind a correct home
address to a false care-of address and thereby trick a correspondent
node into redirecting packets, which would otherwise be delivered to
the attacker itself, to a third party. Neglecting to verify a mobile
node's reachability at its claimed care-of address could therefore
cause one or multiple correspondent nodes to unknowingly contribute
to a redirection-based flooding attack against a victim chosen by the
attacker.
Redirection-based flooding attacks may target a single node, a link,
or a router or other critical network device upstream of an entire
network. Accordingly, the attacker's spoofed care-of address may be
the IP address of a node, a random IP address from a subnet prefix of
a particular link, or the IP address of a router or other network
device. An attack against a network potentially impacts a larger
number of nodes than an attack against a specific node, although
Arkko, et al. Standards Track [Page 41]
RFC 4866 Enhanced Route Optimization May 2007
neighbors of a victim node on a broadcast link typically suffer the
same damage as the victim itself.
Requiring mobile nodes to cryptographically generate care-of
addresses in the same way as they generate home addresses would
mitigate the threat of redirection-based flooding only marginally.
While it would prevent an attacker from registering as its care-of
address the IP address of a specific victim node, the attacker could
still generate a different CGA-based care-of address with the same
subnet prefix as that of the victim's IP address. Flooding packets
redirected towards this care-of address would then not have to be
received and processed by any specific node, but they would impact an
entire link or network and thus cause comparable damage. CGA-based
care-of addresses therefore have little effectiveness with respect to
flooding protection. On the other hand, they would require a
computationally expensive, public-key-based ownership proof whenever
the care-of address changes. For these reasons, Enhanced Route
Optimization uses regular IPv6 care-of addresses.
A common misconception is that a strong proof of home address
ownership would mitigate the threat of redirection-based flooding and
consequently eliminate the need to verify a mobile node's
reachability at a new care-of address. This notion may originate
from the specification of a base Mobile IPv6 home registration in
[1], which calls for the authentication of a mobile node based on an
IPsec security association, but does not require this to be
supplemented by a verification of the mobile node's reachability at
the care-of address. However, the reason not to mandate reachability
verification for a home registration is in this case the existence of
an administrative relationship between the home agent and the mobile
node, rather than the fact that the home agent can securely verify
the mobile node's home address ownership, or that the home
registration is IPsec-protected. The administrative relationship
with the mobile node allows the home agent, first, to trust in the
correctness of a mobile node's care-of address and, second, to
quickly identify the mobile node should it still start behaving
maliciously, for example, due to infection by malware. Section 15.3
in [1] and Section 1.3.2 in [5] explain these prerequisites.
Assuming trust, an administrative relationship between the mobile
node and its home agent is viable, given that the home agent is an
integral part of the mobility services that a mobile user typically
subscribes to, sets up her- or himself, or receives based on a
business relationship. A Mobile IPv6 extension [14] that leverages a
shared authentication key, preconfigured on the mobile node and the
correspondent node, preassumes the same relationship between the
mobile node and a correspondent node. While this assumption limits
the applicability of the protocol (Section 2 of [14] acknowledges
Arkko, et al. Standards Track [Page 42]
RFC 4866 Enhanced Route Optimization May 2007
this), it permits omission of care-of address reachability
verification as in the case of the home registration. Enhanced
Router Optimization does not make assumptions on the relationship
between mobile and correspondent nodes. This renders the protocol
applicable to arbitrary scenarios, but necessitates that
correspondent nodes must verify a mobile node's reachability at every
new care-of address.
6.3. Credit-Based Authorization
Enhanced Route Optimization enables mobile and correspondent nodes to
resume bidirectional communications after a handoff on the mobile-
node side before the mobile node's reachability at the new care-of
address has been verified by the correspondent node. Such
concurrency would in the absence of appropriate protection
reintroduce the threat of redirection-based flooding, which
reachability verification was originally designed to eliminate: Given
that the correspondent node is in general unaware of the round-trip
time to the mobile node, and since reachability verification may fail
due to packet loss, the correspondent node must accept a sufficiently
long concurrency period for reachability verification to complete.
An attacker could misuse this to temporarily trick the correspondent
node into redirecting packets to the IP address of a victim. The
attacker may also successively postpone reachability verification in
that it registers with the correspondent node anew, possibly with a
different spoofed care-of address, shortly before the correspondent
node's maximum permitted concurrency period elapses and the
correspondent node switches to waiting for the completion of
reachability verification without sending further packets. This
behavior cannot necessarily be considered malicious on the
correspondent node side since even a legitimate mobile node's
reachability may fail to become verified before the mobile node's
care-of address changes again. This may be due to high mobility on
the mobile node side, or to persistent packet loss on the path
between the mobile node and the correspondent node. It is generally
non-trivial to decide on the correspondent node side whether the
party at the other end behaves legitimately under adverse conditions
or maliciously.
Enhanced Route Optimization eliminates the threat of redirection-
based flooding despite concurrent reachability verification through
the use of Credit-Based Authorization. Credit-Based Authorization
manages the effort that a correspondent node expends in sending
payload packets to a care-of address in UNVERIFIED state. This is
accomplished based on the following three hypotheses:
Arkko, et al. Standards Track [Page 43]
RFC 4866 Enhanced Route Optimization May 2007
1. A flooding attacker typically seeks to shift the burden of
assembling and sending flooding packets to a third party.
Bandwidth is an ample resource for many attractive victims, so
the effort for sending the high rate of flooding packets required
to impair the victim's ability to communicate may exceed the
attacker's own capacities.
2. The attacker can always flood a victim directly by generating
bogus packets itself and sending those to the victim. Such an
attack is not amplified, so the attacker must be provisioned
enough to generate a packet flood sufficient to bring the victim
down.
3. Consequently, the additional effort required to set up and
coordinate a redirection-based flooding attack pays off for the
attacker only if the correspondent node can be tricked into
contributing to and amplifying the attack.
Non-amplified redirection-based flooding is hence, from an attacker's
perspective, no more attractive than pure direct flooding, where the
attacker itself sends bogus packets to the victim. It is actually
less attractive given that the attacker needs to maintain a context
for mobility management in order to coordinate the redirection. On
this basis, Credit-Based Authorization extinguishes the motivation
for redirection-based flooding by preventing the amplification that
could be reached through it, rather than eliminating malicious packet
redirection in the first place. The ability to send unrequested
packets is an inherent property of packet-oriented networks, and
direct flooding is a threat that results from this. Since direct
flooding exists with and without mobility support, it constitutes a
reasonable measure in comparing the security provided by Enhanced
Route Optimization to the security of the non-mobile Internet.
Through the use of Credit-Based Authorization, Enhanced Route
Optimization satisfies the objective to provide a security level
comparable to that of the non-mobile Internet.
Since the perpetrator of a redirection-based flooding attack would
take on the role of a mobile node, Credit-Based Authorization must be
enforced on the correspondent node side. The correspondent node
continuously monitors the effort that the mobile node spends in
communicating with the correspondent node. The mobile node's effort
is then taken as a limit on the effort that the correspondent node
may spend in sending payload packets when the mobile node's care-of
address is in UNVERIFIED state. The permission for the correspondent
node to send a limited amount of payload packets to a care-of address
in UNVERIFIED state enables immediate resumption of bidirectional
communications once the mobile node has registered a new IP address
with the correspondent node after a handoff.
Arkko, et al. Standards Track [Page 44]
RFC 4866 Enhanced Route Optimization May 2007
If what appears to be a mobile node is in fact an attacker who tricks
the correspondent node into redirecting payload packets to the IP
address of a victim, Credit-Based Authorization ensures that the
stream of flooding packets ceases before the effort that the
correspondent node spends on generating the stream exceeds the effort
that the attacker has recently spent itself. The flooding attack is
therefore at most as effective as a direct flooding attack, and
consequently fails to produce any amplification.
Another property of Credit-Based Authorization is that it does not
assign a mobile node credit while its care-of addresses is in
UNVERIFIED state. This deserves justification since it would
technically be feasible to assign credit independent of the state of
the mobile node's care-of address. However, the assignment of credit
for packets received from a care-of address in UNVERIFIED state would
introduce a vulnerability to sustained reflection attacks.
Specifically, an attacker could cause a correspondent node to
redirect packets for the attacker to the IP address of a victim, and
sustain the packet flow towards the victim in that it continuously
replenishes its credit by sending packets to the correspondent node.
Although such a redirection-based reflection attack would fail to
produce any amplification, it may still be appealing to an attacker
who wishes to pursue an initial transport protocol handshake with the
correspondent node -- which typically requires the attacker to
receive some unguessable data -- and redirect the download to the
victim's IP address afterwards. Credit-Based Authorization ensures
that the attacker in this case cannot acquire additional credit once
the download has been redirected, and thereby forces the attack to
end quickly.
Arkko, et al. Standards Track [Page 45]
RFC 4866 Enhanced Route Optimization May 2007
6.4. Time Shifting Attacks
Base Mobile IPv6 limits the lifetime of a correspondent registration
to 7 minutes and so arranges that a mobile node's reachability at its
home and care-of addresses is reverified periodically. This ensures
that the return routability procedure's vulnerability to
eavesdropping cannot be exploited by an attacker that is only
temporarily on the path between the correspondent node and the
spoofed home or care-of address. Such "time shifting attacks" [5]
could otherwise be misused for off-path IP address stealing, return-
to-home flooding, or flooding against care-of addresses.
Enhanced Route Optimization repeats neither the initial home address
test nor any care-of address test in order to decrease handoff delays
and signaling overhead. This does not limit the protocol's
robustness to IP address stealing attacks because the required CGA-
based ownership proof for home addresses already eliminates such
attacks. Reachability verification does not add further protection
in this regard. On the other hand, the restriction to an initial
reachability verification facilitates time-shifted, off-path flooding
attacks -- either against home addresses with incorrect prefixes or
against spoofed care-of addresses -- if the perpetrator can interpose
in the exchange before it moves to a different location.
The design choice against repeated home and care-of address tests was
made based on the observation that time shifting attacks are already
an existing threat in the non-mobile Internet of today.
Specifically, an attacker can temporarily move onto the path between
a victim and a correspondent node, request a stream of packets from
the correspondent node on behalf of the victim, and then move to a
different location. Most transport protocols do not verify an
initiator's reachability at the claimed IP address after an initial
verification during connection establishment. It enables an attacker
to participate only in connection establishment and then move to an
off-path position, from where it can spoof acknowledgments to feign
continued presence at the victim's IP address. The threat of time
shifting hence already applies to the non-mobile Internet.
It should still be acknowledged that the time at which Enhanced Route
Optimization verifies a mobile node's reachability at a home or
care-of address may well antecede the establishment of any transport
layer connection. This gives an attacker more time to move away from
the path between the correspondent node and the victim and so makes a
time shifting attack more practicable. If the lack of periodic
reachability verification is considered too risky, a correspondent
node may enforce reruns of home or care-of address tests by limiting
the registration lifetime, or by sending Binding Refresh Request
messages to a mobile node.
Arkko, et al. Standards Track [Page 46]
RFC 4866 Enhanced Route Optimization May 2007
6.5. Replay Attacks
The protocol specified in this document relies on 16-bit base Mobile
IPv6 sequence numbers and periodic rekeying to avoid replay attacks.
Rekeying allows mobile and correspondent nodes to reuse sequence
numbers without exposing themselves to replay attacks. It must be
pursued at least once every 24 hours due to the maximum permitted
binding lifetime for correspondent registrations. Mobile and
correspondent nodes also rekey whenever a rollover in sequence number
space becomes imminent. This is unlikely to happen frequently,
however, given that available sequence numbers are sufficient for up
to 32768 correspondent registrations, each consisting of an early and
a complete Binding Update message. The sequence number space thus
permits an average rate of 22 correspondent registrations per minute
without exposing a need to rekey throughout the 24-hour binding
lifetime.
6.6. Resource Exhaustion
While a CGA-based home address ownership proof provides protection
against unauthenticated Binding Update messages, it can expose a
correspondent node to denial-of-service attacks since it requires
computationally expensive public-key cryptography. Enhanced Route
Optimization limits the use of public-key cryptography to only the
first correspondent registration and if/when rekeying is needed. It
is RECOMMENDED that correspondent nodes in addition track the amount
of processing resources they spend on CGA-based home address
ownership verification, and that they reject new correspondent
registrations that involve public-key cryptography when these
resources exceed a predefined limit. [2] discusses the feasibility of
CGA-based resource exhaustion attacks in depth.
6.7. IP Address Ownership of Correspondent Node
Enhanced Route Optimization enables mobile nodes to authenticate a
received Binding Acknowledgment message based on a CGA property of
the correspondent node's IP address, provided that the correspondent
node has a CGA. The mobile node requests this authentication by
including a CGA Parameters Request option in the Binding Update
message that it sends to the correspondent node, and the
correspondent node responds by adding its CGA parameters and
signature to the Binding Acknowledgment message within CGA Parameters
and Signature options. Proving ownership of the correspondent node's
IP address protects the mobile node from accepting a spoofed Binding
Acknowledgment message and from storing the included permanent home
keygen token for use during future correspondent registrations. Such
an attack would result in denial of service against the mobile node
because it would prevent the mobile node from transacting any binding
Arkko, et al. Standards Track [Page 47]
RFC 4866 Enhanced Route Optimization May 2007
updates with the obtained permanent home keygen token. Enhanced
Route Optimization recommends renewal of a permanent home keygen
token in case of persistent correspondent registration failures,
allowing mobile nodes to recover from denial-of-service attacks that
involve spoofed permanent home keygen tokens.
The threat of the described denial-of-service attack is to some
extent mitigated by requirements on the attacker's location: A
Binding Update message that requests a correspondent node to provide
a permanent home keygen token is authenticated based on the CGA
property of the mobile node's home address. This authentication
method involves a home address test, providing the mobile node with a
home keygen token based on which it can calculate the authenticator
of the Binding Update message. Since the mobile node expects the
authenticator of the returning Binding Acknowledgment message to be
calculated with the same home keygen token, an attacker that is
willing to spoof a Binding Acknowledgment message that includes a
permanent home keygen token must eavesdrop on the home address test.
The attacker must hence be present on the path from the correspondent
node to the mobile node's home agent while the home address test
proceeds. Moreover, if the Binding Update message requesting the
permanent home keygen token is complete, its authenticator is further
calculated based on a care-of keygen token. The attacker must then
also know this care-of keygen token to generate the authenticator of
the Binding Acknowledgment message. This requires the attacker to be
on the path from the correspondent node to the mobile node's current
IP attachment at the time the correspondent node sends the care-of
keygen token to the mobile node within a Care-of Test message or the
Care-of Test option of a Binding Acknowledgment message.
Since a mobile node in general does not know whether a particular
correspondent node's IP address is a CGA, the mobile node must be
prepared to receive a Binding Acknowledgment message without CGA
Parameters and Signature options in response to sending a Binding
Update message with an included CGA Parameters Request option. Per
se, this mandatory behavior may enable downgrading attacks where the
attacker would send, on the correspondent node's behalf, a Binding
Acknowledgment message without CGA Parameters and Signature options,
claiming that the correspondent node's IP address is not a CGA.
Enhanced Route Optimization mitigates this threat in that it calls
for mobile nodes to prioritize Binding Acknowledgment messages with
valid CGA Parameters and Signature options over Binding
Acknowledgment messages without such options. This protects against
downgrading attacks unless the attacker can intercept Binding
Acknowledgment messages from the correspondent node. Given that the
attacker must be on the path from the correspondent node to the
mobile node's home agent at roughly the same time as explained above,
the attacker may not be able to intercept the correspondent node's
Arkko, et al. Standards Track [Page 48]
RFC 4866 Enhanced Route Optimization May 2007
Binding Acknowledgment messages. On the other hand, an attacker that
can intercept Binding Acknowledgment messages from the correspondent
node is anyway in a position where it can pursue denial of service
against the mobile node and the correspondent node. This is a threat
that already exists in the non-mobile Internet, and it is not
specific to Enhanced Route Optimization.
External mechanisms may enable the mobile node to obtain certainty
about whether a particular correspondent node's IP address is a CGA.
The mobile node may then insist on an IP address ownership proof from
the correspondent node, in which case it would discard any received
Binding Acknowledgment messages that do not contain valid CGA
Parameters and Signature options. One conceivable means for mobile
nodes to distinguish between standard IPv6 addresses and CGAs might
be an extension to the Domain Name System.
7. Protocol Constants and Configuration Variables
[2] defines a CGA Message Type namespace from which CGA applications
draw CGA Message Type tags to be used in signature calculations.
Enhanced Route Optimization uses the following constant, randomly
generated CGA Message Type tag:
0x5F27 0586 8D6C 4C56 A246 9EBB 9B2A 2E13
[1] bounds the lifetime for bindings that were established with
correspondent nodes by way of the return routability procedure to
MAX_RR_BINDING_LIFETIME. Enhanced Route Optimization adopts this
limit for bindings that are authenticated through a proof of the
mobile node's reachability at the home address. However, the binding
lifetime is limited to the more generous constant value of
MAX_CGA_BINDING_LIFETIME when the binding is authenticated through
the CGA property of the mobile node's home address:
MAX_CGA_BINDING_LIFETIME 86400 seconds
Credit aging incorporates two configuration variables to gradually
decrease a mobile node's credit counter over time. It is RECOMMENDED
that a correspondent node uses the following values:
CreditAgingFactor 7/8
CreditAgingInterval 5 seconds
Arkko, et al. Standards Track [Page 49]
RFC 4866 Enhanced Route Optimization May 2007
8. IANA Considerations
This document defines the following six new mobility options, which
must be assigned type values within the mobility option numbering
space of [1]:
o CGA Parameters Request mobility option (11)
o CGA Parameters mobility option (12)
o Signature mobility option (13)
o Permanent Home Keygen Token mobility option (14)
o Care-of Test Init mobility option (15)
o Care-of Test mobility option (16)
This document allocates the following four new status codes for
Binding Acknowledgment messages:
o "Permanent home keygen token unavailable" (147)
o "CGA and signature verification failed" (148)
o "Permanent home keygen token exists" (149)
o "Non-null home nonce index expected" (150)
The values to be assigned for these status codes must all be greater
than or equal to 128, indicating that the respective Binding Update
message was rejected by the receiving correspondent node.
This document also defines a new 128-bit value under the CGA Message
Type namespace [2].
9. Acknowledgments
The authors would like to thank Tuomas Aura, Gabriel Montenegro,
Pekka Nikander, Mike Roe, Greg O'Shea, Vesa Torvinen (in alphabetical
order) for valuable and interesting discussions around
cryptographically generated addresses.
The authors would also like to thank Marcelo Bagnulo, Roland Bless,
Zhen Cao, Samita Chakrabarti, Greg Daley, Vijay Devarapalli, Mark
Doll, Lakshminath Dondeti, Francis Dupont, Lars Eggert, Eric Gray,
Manhee Jo, James Kempf, Suresh Krishnan, Tobias Kuefner, Lila Madour,
Vidya Narayanan, Mohan Parthasarathy, Alice Qinxia, and Behcet
Arkko, et al. Standards Track [Page 50]
RFC 4866 Enhanced Route Optimization May 2007
Sarikaya (in alphabetical order) for their reviews of and important
comments on this document and the predecessors of this document.
Finally, the authors would also like to emphasize that [15] pioneered
the use of cryptographically generated addresses in the context of
Mobile IPv6 route optimization, and that this document consists
largely of material from [16], [17], and [18] and the contributions
of their authors.
10. References
10.1. Normative References
[1] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in
IPv6", RFC 3775, June 2004.
[2] Aura, T., "Cryptographically Generated Addresses (CGA)",
RFC 3972, March 2005.
[3] Bradner, S., "Key Words for Use in RFCs to Indicate Requirement
Levels", IETF BCP 14, RFC 2119, March 1997.
[4] Jonsson, J. and B. Kaliski, "Public-Key Cryptography Standards
(PKCS) #1: RSA Cryptography Specifications Version 2.1",
RFC 3447, February 2003.
10.2. Informative References
[5] Nikander, P., Arkko, J., Aura, T., Montenegro, G., and E.
Nordmark, "Mobile IP Version 6 Route Optimization Security
Design Background", RFC 4225, December 2005.
[6] Vogt, C. and J. Arkko, "A Taxonomy and Analysis of Enhancements
to Mobile IPv6 Route Optimization", RFC 4651, February 2007.
[7] Vogt, C. and M. Doll, "Efficient End-to-End Mobility Support in
IPv6", Proceedings of the IEEE Wireless Communications and
Networking Conference, IEEE, April 2006.
[8] Mirkovic, J. and P. Reiher, "A Taxonomy of DDoS Attack and DDoS
Defense Mechanisms", ACM SIGCOMM Computer Communication Review,
Vol. 34, No. 2, ACM Press, April 2004.
[9] Arkko, J. and C. Vogt, "Credit-Based Authorization for Binding
Lifetime Extension", Work in Progress, May 2004.
Arkko, et al. Standards Track [Page 51]
RFC 4866 Enhanced Route Optimization May 2007
[10] O'Shea, G. and M. Roe, "Child-Proof Authentication for MIPv6
(CAM)", ACM SIGCOMM Computer Communication Review, ACM Press,
Vol. 31, No. 2, April 2001.
[11] Nikander, P., "Denial-of-Service, Address Ownership, and Early
Authentication in the IPv6 World", Revised papers from the
International Workshop on Security Protocols, Springer-Verlag,
April 2002.
[12] Bagnulo, M. and J. Arkko, "Support for Multiple Hash Algorithms
in Cryptographically Generated Addresses (CGAs)", Work
in Progress, April 2007.
[13] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure
Neighbor Discovery (SEND)", RFC 3971, March 2005.
[14] Perkins, C., "Securing Mobile IPv6 Route Optimization Using a
Static Shared Key", RFC 4449, June 2006.
[15] Roe, M., Aura, T., O'Shea, G., and J. Arkko, "Authentication of
Mobile IPv6 Binding Updates and Acknowledgments", Work
in Progress, March 2002.
[16] Haddad, W., Madour, L., Arkko, J., and F. Dupont, "Applying
Cryptographically Generated Addresses to Optimize MIPv6 (CGA-
OMIPv6)", Work Progress, May 2005.
[17] Vogt, C., Bless, R., Doll, M., and T. Kuefner, "Early Binding
Updates for Mobile IPv6", Work in Progress, February 2004.
[18] Vogt, C., Arkko, J., Bless, R., Doll, M., and T. Kuefner,
"Credit-Based Authorization for Mobile IPv6 Early Binding
Updates", Work in Progress, May 2004.
Arkko, et al. Standards Track [Page 52]
RFC 4866 Enhanced Route Optimization May 2007
Authors' Addresses
Jari Arkko
Ericsson Research NomadicLab
FI-02420 Jorvas
Finland
EMail: jari.arkko@ericsson.com
Christian Vogt
Institute of Telematics
Universitaet Karlsruhe (TH)
P.O. Box 6980
76128 Karlsruhe
Germany
EMail: chvogt@tm.uka.de
Wassim Haddad
Ericsson Research
8400, Decarie Blvd
Town of Mount Royal
Quebec H4P 2N2, Canada
EMail: wassim.haddad@ericsson.com
Arkko, et al. Standards Track [Page 53]
RFC 4866 Enhanced Route Optimization May 2007
Full Copyright Statement
Copyright (C) The IETF Trust (2007).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.
Arkko, et al. Standards Track [Page 54]