RFC 4866
Enhanced Route Optimization for Mobile IPv6
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.
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.
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.
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.
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
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
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
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.
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
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
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
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:
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.
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.
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.
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
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
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
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
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.
[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.
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
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.