RFC 4866
Enhanced Route Optimization for Mobile IPv6
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.
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
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.
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.
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
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
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.
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
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.
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.
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
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
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.
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.
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.
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.
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.
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
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
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.
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,
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
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.
(page 32 continued on part 3)
