Enhanced Route Optimization for Mobile IPv6
Extracted elements (31)
An initial home address test is required even with CGA-based ownership proofs to prevent subnet-prefix spoofing attacks, where a malicious node generates a CGA using a victim network's prefix and tricks a correspondent node into flooding that prefix. This test need not be repeated on subsequent handoffs.
Credit-Based Authorization is introduced to prevent redirection-based flooding when concurrent care-of address tests allow a correspondent node to forward packets to an UNVERIFIED care-of address. By capping the correspondent node's outbound effort to no more than what it receives from a VERIFIED address, the attack cannot exceed the effectiveness of direct flooding — the threat level of the non-mobile Internet.
Cryptographically Generated Addresses (CGAs) are used for the mobile node's home address to provide a strong cryptographic binding between the interface identifier and the node's public key. This eliminates the need for repeated home address tests after an initial prefix validation, enabling longer binding lifetimes and lower handoff delays without requiring a public-key infrastructure.
Semi-permanent security associations (based on a shared permanent home keygen token) are introduced because CGA-based authentication is computationally expensive and requires large CGA parameter payloads per message. An initial CGA exchange establishes the token, which then authenticates subsequent registrations more efficiently.
Enhanced Route Optimization is an amendment to base Mobile IPv6 route optimization [RFC 3775] and is designed to be applied alongside it. A mobile node may choose to use only CGA-based home address authentication, only concurrent care-of address tests, or both enhancements together. If neither enhancement applies, base Mobile IPv6 procedures govern.
A mobile node MUST NOT reuse the same sequence number with a given permanent home keygen token. When a sequence number rollover is imminent, the mobile node MUST renew the permanent home keygen token by including its CGA parameters and signature in a new Binding Update to the correspondent node.
If a Binding Update is to be authenticated using a permanent home keygen token but the correspondent node has no such token in its Binding Cache entry, it MUST reject the message with status code 147 ('Permanent home keygen token unavailable').
If the Binding Update is early (no valid care-of keygen token), the mobile node MUST include a Care-of Test Init option requesting the correspondent node to return a fresh care-of keygen token in the Binding Acknowledgment. Upon receipt, the mobile node MUST then send a complete Binding Update using that token.
If the mobile node's home address is a CGA and it already holds a permanent home keygen token for the correspondent node, it MUST authenticate the Binding Update message by proving knowledge of the permanent home keygen token rather than using a CGA-based or reachability-based method.
Once a permanent home keygen token is obtained, the mobile node MUST authenticate all subsequent Binding Updates to the same correspondent node using that token, until the binding expires, the token is renewed, or the binding is deregistered. This prevents an on-path attacker from downgrading authentication to reachability-based proof.
The correspondent node MUST reject a Binding Update authenticated through reachability at the home address if it already holds a permanent home keygen token for that mobile node, returning status code 149 ('Permanent home keygen token exists'). This prevents downgrade attacks by on-path adversaries.
The Lifetime field of a Binding Update authenticated via CGA or permanent home keygen token MUST NOT exceed MAX_CGA_BINDING_LIFETIME. For reachability-based authentication, the lifetime MUST NOT exceed MAX_RR_BINDING_LIFETIME. It is RECOMMENDED that the mobile node always request the maximum permitted lifetime to minimize signaling overhead.
The permanent home keygen token MUST be transmitted encrypted using RSAES-PKCS1-v1_5 with the mobile node's public key in the Permanent Home Keygen Token field. The Binding Authorization Data option MUST be the last option in the Binding Acknowledgment, covering the Permanent Home Keygen Token option.
When sending payload packets to a care-of address in UNVERIFIED state, the correspondent node MUST reduce the credit counter by the packet size and may send only if the counter is at least as large as the payload. If the counter is insufficient, the packet MUST NOT be sent to the care-of address; it SHOULD be discarded, but MAY be buffered or sent to the home address instead.
When the mobile node returns to its home link and wishes to deregister, it MUST initiate the home deregistration first and MUST wait for a successful Binding Acknowledgment before initiating correspondent deregistration. This prevents the home agent from proxying the mobile node's address during Duplicate Address Detection.
Four new Binding Acknowledgment status codes are defined: 147 ('Permanent home keygen token unavailable'), 148 ('CGA and signature verification failed'), 149 ('Permanent home keygen token exists'), and 150 ('Non-null home nonce index expected'). Each signals a specific authentication failure to the mobile node.
The credit counter is a per-mobile-node value maintained by the correspondent node. It increases by the size of each inbound payload packet received from a VERIFIED care-of address, and decreases by the size of each outbound packet sent to an UNVERIFIED care-of address. Credit aging periodically multiplies the counter by CreditAgingFactor (< 1) at CreditAgingInterval intervals to bound the total accumulated credit.
The permanent home keygen token is a 64-bit pseudo-random value generated by the correspondent node and shared with the mobile node after successful CGA verification. It serves as the basis for a semi-permanent security association, replacing repeated CGA authentication and enabling efficient subsequent Binding Update authentication.
The signature value in the Signature option is computed over the concatenation of care-of address, correspondent node IP address, and MH data (mobility header plus all options up to and including the last CGA Parameters option), using the signer's private key per the CGA signature generation algorithm. The checksum field is treated as zero during signature calculation.
Section 8 requests IANA assignments for the new mobility options (CGA Parameters, Signature, Permanent Home Keygen Token, Care-of Test Init, Care-of Test, CGA Parameters Request) and new Binding Acknowledgment status codes (147–150) defined by this document, extending the Mobile IPv6 option and status code registries.
CGA-based home address ownership proof protects against impersonation even by on-path attackers, unlike the base Mobile IPv6 return routability procedure. An attacker can forge reachability proofs if on the path between the correspondent node and the home agent, but cannot forge a CGA-based signature without the mobile node's private key.
Credit-Based Authorization ensures that redirection-based flooding via UNVERIFIED care-of addresses cannot exceed the rate of direct flooding, because the correspondent node's credit is bounded by the actual traffic received from the mobile node. Credit aging prevents slow, long-term credit accumulation followed by a burst attack.
Replay attacks are prevented by requiring a unique sequence number per permanent home keygen token. When a rollover is imminent, the token must be renewed. Additionally, the semi-permanent token should be renewed periodically to limit exposure to cryptanalysis.
Resource exhaustion attacks are mitigated because public-key operations are deferred: the correspondent node performs the cheap CGA prefix check before the more expensive signature verification. The mobile node can also disable CGA Parameters Request options for correspondent nodes that persistently fail CGA verification, to avoid wasted verification effort.
A care-of address registered via a complete Binding Update (with valid care-of keygen token) is placed in VERIFIED state; one registered via an early Binding Update is placed in UNVERIFIED state. The transition from UNVERIFIED to VERIFIED occurs when the correspondent node receives a subsequent complete Binding Update for the same care-of address. In VERIFIED state, packets are sent without credit restrictions; in UNVERIFIED state, credit-based limits apply.
The Care-of Test Init option is added to an early Binding Update message to request a fresh care-of keygen token from the correspondent node. It MUST follow any CGA Parameters and Signature options in the message.
The Care-of Test option is carried in a Binding Acknowledgment message responding to an early Binding Update with a Care-of Test Init option. Its Care-of Keygen Token field holds a pseudo-random 64-bit value generated by the correspondent node.
The CGA Parameters option carries a fragment of the CGA Parameters data structure. Because the mobility header limits options to 255 bytes (excluding Type and Length), the full CGA parameters may be split across multiple consecutive CGA Parameters options, which are reassembled in order by the receiver.
The CGA Parameters Request option may be included in a Binding Update to request that the correspondent node prove ownership of its IP address by returning its CGA parameters and signature in the Binding Acknowledgment. This allows the mobile node to verify that the permanent home keygen token was issued by the correct correspondent node.
The Permanent Home Keygen Token option is included in Binding Acknowledgment messages and carries the correspondent node's RSA-encrypted 64-bit permanent home keygen token in its Permanent Home Keygen Token field. It MUST appear before the Care-of Test option when both are present.
The Signature option contains the cryptographic signature computed per Section 4.5 and MUST immediately follow the last CGA Parameters option in a Binding Update or Binding Acknowledgment message. Its Signature field carries the output of the CGA signature generation algorithm.