Network Working Group C. Vogt Internet-Draft Universitaet Karlsruhe (TH) Expires: August 31, 2006 February 27, 2006 Early Binding Updates for Mobile IPv6 draft-vogt-mobopts-simple-ebu-00.txt Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on August 31, 2006. Copyright Notice Copyright (C) The Internet Society (2006). Abstract Mobile IPv6 defines a return-routability procedure for secure use of route optimization between unacquainted nodes. Unfortunately, this procedure is known to have undesired impacts on handoff latency. This document specifies extensions to Mobile IPv6 that eliminate the latency of the return-routability procedure. The extensions thus provide a basis for more efficient reactive as well as proactive handoff management. They are optional and fully backward-compatible. Vogt Expires August 31, 2006 [Page 1] Internet-Draft Early Binding Updates for Mobile IPv6 February 2006 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 5 3.1 Reactive Registration Procedure . . . . . . . . . . . . . 5 3.2 Proactive Registration Procedure . . . . . . . . . . . . . 8 4. Handling Unverified Care-of Addresses . . . . . . . . . . . . 11 5. Modifications to RFC 3775 . . . . . . . . . . . . . . . . . . 13 5.1 Overview of Mobile IPv6 Security (Section 5) . . . . . . . 13 5.2 Correspondent Node Operation (Section 9) . . . . . . . . . 18 5.3 Home Agent Operation (Section 10) . . . . . . . . . . . . 23 5.4 Mobile Node Operation (Section 11) . . . . . . . . . . . . 26 6. Security Considerations . . . . . . . . . . . . . . . . . . . 35 6.1 Authentication . . . . . . . . . . . . . . . . . . . . . . 36 6.2 Reachability . . . . . . . . . . . . . . . . . . . . . . . 36 7. Protocol Constants . . . . . . . . . . . . . . . . . . . . . . 37 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 37 8.1 Normative References . . . . . . . . . . . . . . . . . . . 37 8.2 Informational References . . . . . . . . . . . . . . . . . 37 Author's Address . . . . . . . . . . . . . . . . . . . . . . . 38 A. Acknowledgment . . . . . . . . . . . . . . . . . . . . . . . . 38 Intellectual Property and Copyright Statements . . . . . . . . 39 Vogt Expires August 31, 2006 [Page 2] Internet-Draft Early Binding Updates for Mobile IPv6 February 2006 1. Introduction Mobile IPv6 [RFC3775] specifies a mode for route optimization, enabling mobile nodes to register their current logical position in the Internet with correspondent nodes. Peers can thus communicate along a direct path in addition to sending their packets via a stationary proxy of the mobile node, the mobile node's home agent. Due to the typical absence of a pre-configured security context between arbitrary Internet nodes, route optimization must be protected in an ad-hoc manner against various types of impersonation, denial-of-service, and flooding threats [RFC4225]. Specifically, correspondent nodes verify a mobile node's reachability at its IP addresses, both periodically and when the mobile node undergoes a change in IP attachment. This is called the "return-routability procedure" Unfortunately, the return-routability procedure defined in [RFC3775] does not permit mobile nodes to communicate with their peers while it is being accomplished. This can have detrimental impacts on handoff latencies and cause adverse behavior of delay-sensitive applications. This document specifies optional and fully backward-compatible extensions to Mobile IPv6 route optimization that allow for smoother reactive handoffs. The extensions can also be used for proactive handoff management where mobile nodes have the capabilities to anticipate movements. The extensions specified in this document where first proposed at the 59th IETF meeting in Seoul, Republic of Korea, in February 2004. They have since been discussed within IETF MIP6 working group and the IRTF MobOpts research group. 2. Terminology Unverified care-of address A care-of address registered by means of a tentative correspondent registration. A mobile node's reachability at an unverified care-of address is not known to a correspondent node, because no care-of-address test has (yet) been accomplished. Vogt Expires August 31, 2006 [Page 3] Internet-Draft Early Binding Updates for Mobile IPv6 February 2006 Verified care-of address A care-of address registered by means of a standard correspondent registration. A mobile node's reachability at a verified care-of address has been determined through a care-of-address test. Active care-of address The care-of address currently registered by a home agent or correspondent node. The unqualified term "care-of address" refers to the active care-of address unless otherwise specified. A home agent or correspondent node sends packets for a mobile node to the the active care-of address of that mobile node. Previous care-of address The care-of address that was replaced by the active care-of address during the last home or correspondent registration. After a home registration, the home agent continues for a short period to accept packets that arrive from the mobile node's previous care-of address. Likewise, after a correspondent registration, the correspondent node continues for a while to accept packets with a Home Address destination option that have been sent from the previous care-of address. Tentative correspondent registration A correspondent registration with limited lifetime, which a mobile node can request before it has obtained a care-of keygen token. A tentative correspondent registration provides evidence to a correspondent node that the mobile node is reachable at the home address, but it does not prove the mobile node's reachability at the claimed care-of address. Standard correspondent registration A correspondent registration as specified in [RFC3775]. The term is used for differentiation from a tentative correspondent registration. A standard correspondent registration provides evidence to a correspondent node that the mobile node is reachable at both the home address and the claimed care-of address. Early Binding Update message Vogt Expires August 31, 2006 [Page 4] Internet-Draft Early Binding Updates for Mobile IPv6 February 2006 A Binding Update message sent by a mobile node to request a tentative correspondent registration for a new care-of address. The early Binding Update message does not contain a proof of the mobile node's reachability at that care-of address. The Care-of Nonce Index field in the Nonce Indices mobility option following an early Binding Update message is set to zero, indicating that the Authenticator field in the Binding Authorization Data mobility option was calculated without a care-of keygen token. Standard Binding Update message A Binding Update message sent by a mobile node to request a standard correspondent registration for a new care-of address, as specified in [RFC3775]. The term is used for differentiation from an early Binding Update message. Proactive home-address test The exchange of a pair of Home Test Init and Home Test messages, initiated by a mobile node in order to acquire a valid home keygen token in preparation for a future handoff. Concurrent care-of address test The exchange of a pair of Care-of Test Init and Care-of Test messages for an unverified care-of address, executed subsequent to a tentative correspondent registration. The unverified care-of address is already in use during the concurrent care-of-address test. 3. Protocol Overview The Mobile IPv6 extensions specified in this document allow for efficient reactive or proactive handoff management. Reactive and proactive registration procedures are described separately in the following. For the sake of simplicity, it is assumed that the mobile node communicates with a single correspondent node. If the mobile node communicates with more than one correspondent node at a time, it needs to run a separate correspondent registration with each of the correspondent node. 3.1 Reactive Registration Procedure Figure 1 illustrates the reactive Mobile IPv6 registration procedure when early Binding Updates are used. Vogt Expires August 31, 2006 [Page 5] Internet-Draft Early Binding Updates for Mobile IPv6 February 2006 mobile node home agent correspondent node | | | |=Home Test Init===>|-Home Test Init--->| | | | |<========Home Test=|<--------Home Test-| | | | handoff ~ | | | | | use new |-Binding Update--->| | c/o address |-early Binding Update----------------->| c/o address |-Care-of Test Init-------------------->| unverified | | | |<------Binding Ack-| | |<--------------------early-Binding Ack-| |<-------------------------Care-of Test-| | | | |-Binding Update----------------------->| c/o address | | | verified |<--------------------------Binding Ack-| | | | Figure 1: Reactive registration procedure with early Binding Updates The mobile node sends a Home Test Init message prior to handoff in order to proactively elicit a Home Test message from the correspondent node with a fresh home keygen token. The Home Test Init message may be sent periodically whenever the current home keygen token is about to expire. Tokens are valid for MAX_TOKEN_LIFETIME [RFC3775], so the interval between successive Home Test Init messages should be a little bit less. Alternatively, the mobile node's local link layer may provide a trigger announcing imminent handoff. The mobile node may send the Home Test Init message right in time in this case. The Home Test Init and Home Test messages have the same syntax, and are processed in the same way, as specified in [RFC3775]. When the mobile node detects that it has moved to a different link, it configures a new care-of address. The mobile node then sends three messages back to back: a Binding Update message to its home agent, and early Binding Update and a Care-of Test Init messages to the correspondent node. The Binding Update for the home agent is the same as specified in [RFC3775]. The early Binding Update for the correspondent node is a request to cache a tentative binding. It has the same syntax as a standard Binding Update message, but the Authenticator value in the Binding Authorization Data mobility option is calculated only with a proactively obtained home keygen token. The Care-of Nonce Index field in the Nonce Indices mobility option is Vogt Expires August 31, 2006 [Page 6] Internet-Draft Early Binding Updates for Mobile IPv6 February 2006 set to zero. The early Binding Update is hence similar to a standard Binding Update that the mobile node sends to a correspondent node for the purpose of de-registration when returning to the home link. The Care-of Test Init message elicits a Care-of Test message from the correspondent node with a fresh care-of keygen token. Data packets may already be exchanged through the new care-of address during this handshake. The Care-of Test Init and Care-of Test messages have the same syntax, and are processed in the same way, as specified in [RFC3775]. The home agent processes a received Binding Update according to the rules specified in [RFC3775]. The home agent then sends a Binding Acknowledgment message back to the mobile node. When the correspondent node receives the early Binding Update message, it tentatively binds the mobile node's home address to the new care-of address. It sets the new care-of address to UNVERIFIED state, because the early Binding Update message does not show whether the mobile node is indeed reachable at this address. If the Acknowledge (A) flag is set in the early Binding Update message, the correspondent node sends a Binding Acknowledgment message back to the mobile node. The correspondent node may send route-optimized data packets to the unverified care-of address from this time on. Whether or not it does so depends on its local policies. Section 4 discusses various policies that the correspondent node may apply. In any case, the correspondent node should not send any further packets to the previous care-of address of the mobile node. [RFC3775] requires that the requested lifetime for a correspondent registration must be less than or equal to the remaining lifetime of the current home registration. However, the home agent defines the lifetime of the home registration in its Binding Acknowledgment message, so the mobile node does not know the home-registration lifetime at the time it sends an early Binding Update message. The lifetime requested in the early Binding Update message must therefore not exceed TENTATIVE_RR_BINDING_LIFETIME. After a successful Binding Acknowledgment message has been received from the home agent, and after a fresh care-of keygen token has been obtained from the correspondent node, the mobile node sends a standard Binding Update message to the correspondent node. As specified in [RFC3775], the Authenticator value of the Binding Authorization Data mobility option is calculated with the care-of keygen token from the received Care-of Test message and the home keygen token from the most recently received Home Test message. The nonce indices in the Nonce Indices mobility option are set Vogt Expires August 31, 2006 [Page 7] Internet-Draft Early Binding Updates for Mobile IPv6 February 2006 appropriately. When the correspondent node receives the standard Binding Update message to the correspondent node, it sets the lifetime of the mobile node's binding as specified in [RFC3775]. This extends the lifetime from its tentative value. The correspondent node also changes the state of the care-of address from UNVERIFIED to VERIFIED. If the Acknowledge (A) flag in the received Binding Update message is set, the correspondent node sends a Binding Acknowledgment message back to the mobile node. If the mobile node sets the Acknowledge (A) flag in the early Binding Update message, but fails to receive a corresponding Binding Acknowledgment message within appropriate time, it may retransmit the early Binding Update message every INITIAL_BINDACK_TIMEOUT [RFC3775] up to EARLY_BINDING_UPDATE_RETRIES times until it either receives an acknowledgment for the early Binding Update message or meets the preconditions to send a standard Binding Update message. When the mobile node can be sure that the correspondent node has received its early Binding Update message, it may periodically refresh the tentative registration until it can be sure that the correspondent node has received its standard Binding Update message. The mobile node resends the standard Binding Update message according to rules specified in [RFC3775] until it can be sure that the correspondent node has successfully processed the message. Handoff efficiency is highest when the correspondent node sends packets to a care-of address in UNVERIFIED state directly, but the correspondent node may choose to send them to the home address until the state of the care-of address changes to VERIFIED (cf. Section 4). The mobile node must expect to receive the correspondent node's packets encapsulated by its home agent from the time it sends the early Binding Update message up to a short period of time after it has sent the standard Binding Update message to the correspondent node. The mobile node should not consider the encapsulated packets as an indication of a failed correspondent registration. Moreover, the mobile node may route-optimize its packets for the correspondent node rather than reverse-tunneling them through the home agent. The correspondent node accepts these packets due to the tentative binding between the home address and the unverified care-of address. 3.2 Proactive Registration Procedure A mobile node may be able to anticipate movements and acquire the prefixes of its prospective next default router by some external means. The mobile node MAY then proactively form a new care-of address and register this with its home agent while still connected Vogt Expires August 31, 2006 [Page 8] Internet-Draft Early Binding Updates for Mobile IPv6 February 2006 to the old link. For a mobile node to anticipate movements and schedule handoff-related activities accordingly, the IP layer must be able to issue commands to the link layer and receive events as well as anticipatory information from the link layer. This calls for a bidirectional interface between these layers, the specification of which is outside the scope of this document. mobile node home agent correspondent node | | | L2-triggered |=Home Test Init===>|-Home Test Init--->| notification | | | |<========Home Test=|<--------Home Test-| | | | |-Binding Update--->| | |-early Binding Update----------------->| c/o address | | | unverified L3-triggered |<------Binding Ack-| | handoff ~ X <----------------early Binding Ack-| | | | use new |-early Binding Update----------------->| c/o address |-Care-of Test Init-------------------->| | | | |<--------------------early-Binding Ack-| |<-------------------------Care-of Test-| | | | |-Binding Update----------------------->| c/o address | | | verified |<--------------------------Binding Ack-| | | | Figure 2: Proactive registration procedure with early Binding Updates Figure 2 illustrates the proactive registration procedure. At some point, the mobile node receives a link-layer notification indicating that the signal strength for its current link attachment has dropped below a certain threshold. This causes the mobile node to send a Home Test Init message and acquire a home keygen token from its correspondent node. Depending on how long the mobile node remains in this pre-handoff stage, it may have to resend the Home Test Init message in order to refresh the token. Should a later notification tell that the signal quality has again increased, the periodic tests can be stopped. However, if the signal quality falls further, the mobile node will at some point receive a link-layer notification indicating that a change in link-layer attachment is due. This includes the link-layer address of the prospectively new access point, which the mobile node resolves to the set of prefixes in use on the target link. Vogt Expires August 31, 2006 [Page 9] Internet-Draft Early Binding Updates for Mobile IPv6 February 2006 Based on a prefix from the target link, the mobile node configures a new care-of address. The mobile node MUST set the address to Optimistic state [ODAD] and use Optimistic Duplicate Address Detection [ODAD] for verifying uniqueness of the address when it arrives on the new link. The mobile node then sends a Binding Update message to the home agent and an early Binding Update message to the correspondent node. Since these messages are sent from the old link, and the IPv6 Source Address field does not contain the new care-of address as it usually does, Alternate Care-of Address mobility options are added to the messages to hold the new care-of address. The Acknowledge (A) flag is set in both messages. The mobile node uses its old care-of address until it has actually moved to the new link. When the home agent receives the Binding Update message, it registers the new care-of address, but continues for a period of PREVIOUS_CAREOF_ADDRESS_LIFETIME time to also accept packets that the mobile node may send from the old care-of address before moving to the new link [PETANDER05]. Likewise, the correspondent node registers the new care-of address upon receipt of an early Binding Update message, but continues for a period of PREVIOUS_CAREOF_ADDRESS_LIFETIME time to also accept packets from the old care-of address. The home agent and the correspondent node return their acknowledgments to the old care-of address, but direct subsequent packets to the new care-of address. One of these acknowledgments will cause the mobile node to instruct its link layer to switch to the newly discovered access point. The mobile node implements its own policy as to which acknowledgment it uses for this purpose. When the mobile node eventually arrives on the new link, it begins Optimistic Duplicate Address Detection signaling [ODAD] and sends subsequent data packets via the new care-of address. Some of the acknowledgments are usually lost on the old link, so the mobile node cannot tell whether all registrations were successful. It hence retransmits Binding Update and early Binding Update messages for any unconfirmed registrations. In Figure 2, the registration with the only correspondent node remains unacknowledged on the old link, so the mobile node resends the early Binding Update message from the new link. Incoming packets may already be queued at the new access router when the mobile node arrives on the new link, or they arrive shortly, as the home agent and the correspondent node should already be using the new care-of address. The mobile node sends a Care-of Test Init message to the correspondent node in order to elicit a Care-of Test message from the correspondent node with a fresh care-of keygen token. Data packets may already be exchanged through the new care-of Vogt Expires August 31, 2006 [Page 10] Internet-Draft Early Binding Updates for Mobile IPv6 February 2006 address during this handshake. After a successful Binding Acknowledgment message has been received from the home agent, either on the old or on the new link, and after a fresh care-of keygen token has been obtained from the correspondent node, the mobile node sends a standard Binding Update message to the correspondent node. The correspondent node returns a Binding Acknowledgment message in case the Acknowledge (A) flag is set in the Binding Update message. 4. Handling Unverified Care-of Addresses The correspondent node stops sending further packets to an old care-of address once the mobile node has tentatively registered a new, unverified care-of address. It accepts route-optimized packets that the mobile node sends from the unverified care-of address from that time on. However, whether or not the correspondent node sends data packets to the unverified care-of address depends on its local policies. Several approaches are conceivable: Dropping Packets Local policies may prohibit the correspondent node to send data packets to an unverified care-of address. The correspondent node may simply drop such packets. It may rely on protocols at stack layers above IP to retransmit the lost packets when the care-of address becomes verified. Buffering Packets The correspondent node may buffer packets for a mobile node whoose care-of address is unverified. It can send these packets as soon as the care-of address gets verified. However, packet buffering makes the correspondent node susceptible to memory-overflow attacks and may represent a denial-of-service vulnerability on its own. It should hence be limited to scenarios where the correspondent node can identify a trustworthy mobile node based on the home address, and the mobile node's reachability at the home address has been verified. Diverted Routing Vogt Expires August 31, 2006 [Page 11] Internet-Draft Early Binding Updates for Mobile IPv6 February 2006 The correspondent node may choose to send packets for a mobile node to the home address while the care-of address is unverified. The mobile node may still send route-optimized packets for the correspondent node directly instead of reverse-tunneling them through the home agent. It may reverse-tunnel the packets, however, if latency differences between packets routed through the home agent and those sent directly would otherwise cause disruption to the application. Heuristics A rigid lifetime limit for tentative correspondent registrations supplemented with a heuristic for misuse detection can be a sufficient discouragement of malicious packet redirection. Mobile nodes have to authenticate their home addresses during a tentative correspondent registration, so an attacker can always be identified by means of its home address. Trusted Communities The correspondent node may use the home address as a criterion for deciding whether a particular mobile node belongs to a trusted community. If it can rely on the mobile node's trustworthiness, it can send packets to an unverified care-of address of this mobile node. This strategy could be used by a corporate server which trusts mobile nodes only if they are affiliated to its own company. Credit-Based Authorization Redirection-based flooding attacks are a particular threat due to their potential for high amplification. Credit-Based Authorization [CBA] prevents such amplification, discouraging malicious packet redirection in the first place. This is accomplished by limiting the data that a correspondent node can send to an unverified care-of address of a mobile node by the data that the correspondent node has recently received from that mobile node. A redirection-based flooding attack thus becomes 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. Vogt Expires August 31, 2006 [Page 12] Internet-Draft Early Binding Updates for Mobile IPv6 February 2006 5. Modifications to RFC 3775 The Mobile IPv6 extensions set forth in this document are most precisely specified as the set of changes to RFC 3775 that they require. These changes are listed in the following, giving implementors a step-by-step guide on how to modify RFC-3775-conform software so as to support Early Binding Updates. 5.1 Overview of Mobile IPv6 Security (Section 5) Modifications to Section 5.2.5, "Return Routability Procedure": - Original text The Return Routability Procedure enables the correspondent node to obtain some reasonable assurance that the mobile node is in fact addressable at its claimed care-of address as well as at its home address. Only with this assurance is the correspondent node able to accept Binding Updates from the mobile node which would then instruct the correspondent node to direct that mobile node's data traffic to its claimed care-of address. + New text The Return Routability Procedure enables the correspondent node to obtain some reasonable assurance that the mobile node is in fact addressable at its claimed care-of address as well as at its home address. The correspondent node may (tentatively) accept Binding Update messages based only on the knowledge that the mobile node is addressable at its home address if additional protection against false care-of addresses is provided (see Section 4). The correspondent node can then temporarily direct the mobile node's data traffic to the claimed care-of address while the validity of the care-of address is being verified. However, in the regular case, or if no additional protection against false care-of addresses exists, a Binding Update can only be accepted with the assurance that the mobile node's home address and care-of address are both correct. - Original text The Home and Care-of Test Init messages are sent at the same time. The procedure requires very little processing at the correspondent node, and the Home and Care-of Test messages can be returned quickly. These four messages form the return routability procedure. Vogt Expires August 31, 2006 [Page 13] Internet-Draft Early Binding Updates for Mobile IPv6 February 2006 + New text The Home and Care-of Test Init messages can be sent at the same time or separately. The procedure requires very little processing at the correspondent node, and the Home and Care-of Test messages can be returned quickly, possibly nearly simultaneously. These four messages form the return routability procedure. - Original text When the mobile node has received both the Home and Care-of Test messages, the return routability procedure is complete. As a result of the procedure, the mobile node has the data it needs to send a Binding Update to the correspondent node. The mobile node hashes the tokens together to form a 20 octet binding key Kbm: Kbm = SHA1 (home keygen token | care-of keygen token) + New text When the mobile node has received the Home Test messages, it has the data required to send an early Binding Update message to the correspondent node. The mobile node hashes the home keygen token to form a 20 octet binding key Kbm: Kbm = SHA1 (home keygen token) When the mobile node has received both the Home and Care-of Test messages, the return routability procedure is complete. As a result of the procedure, the mobile node has the data it needs to send a standard Binding Update message to the correspondent node. The mobile node now hashes both tokens together to form a new 20 octet binding key Kbm: Kbm = SHA1 (home keygen token | care-of keygen token) Modifications to Section 5.2.6, "Authorizing Binding Management Messages": - Original text Binding Update Vogt Expires August 31, 2006 [Page 14] Internet-Draft Early Binding Updates for Mobile IPv6 February 2006 To authorize a Binding Update, the mobile node creates a binding management key Kbm from the keygen tokens as described in the previous section. The contents of the Binding Update include the following: * Source Address = care-of address * Destination Address = correspondent * Parameters + home address (within the Home Address destination option if different from the Source Address) + sequence number (within the Binding Update message header) + home nonce index (within the Nonce Indices option) + care-of nonce index (within the Nonce Indices option) + First (96, HMAC_SHA1 (Kbm, (care-of address | correspondent | BU))) + New text Binding Update To authorize an early Binding Update message, the mobile node creates a binding management key Kbm from the home keygen token as described in the previous section. The contents of the early Binding Update message include the following: * Source Address = care-of address * Destination Address = correspondent * Parameters + home address (within the Home Address destination option if different from the Source Address) + sequence number (within the Binding Update message header) + home nonce index (within the Nonce Indices option) + First (96, HMAC_SHA1 (Kbm, (care-of address | correspondent | BU))) To authorize a standard Binding Update message, the mobile node creates a binding management key Kbm from both keygen tokens as described in the previous section. The contents of the standard Binding Update message include the following: * Source Address = care-of address * Destination Address = correspondent * Parameters + home address (within the Home Address destination option if different from the Source Address) + sequence number (within the Binding Update message header) Vogt Expires August 31, 2006 [Page 15] Internet-Draft Early Binding Updates for Mobile IPv6 February 2006 + home nonce index (within the Nonce Indices option) + care-of nonce index (within the Nonce Indices option) + First (96, HMAC_SHA1 (Kbm, (care-of address | correspondent | BU))) - Original text The Binding Update contains a Nonce Indices option, indicating to the correspondent node which home and care-of nonces to use to recompute Kbm, the binding management key. The MAC is computed as described in Section 6.2.7, using the correspondent node's address as the destination address and the Binding Update message itself ("BU" above) as the MH Data. + New text The Binding Update message contains a Nonce Indices option, indicating to the correspondent node which home and care-of nonces to use to recompute Kbm, the binding management key. For an early Binding Update message, the Care-of Nonce Index field in this option is set to zero. The MAC is computed as described in Section 6.2.7, using the correspondent node's address as the destination address and the Binding Update message itself ("BU" above) as the MH Data. - Original text Binding Acknowledgement The Binding Update is in some cases acknowledged by the correspondent node. The contents of the message are as follows: * Source Address = correspondent * Destination Address = care-of address * Parameters: + sequence number (within the Binding Update message header) + First (96, HMAC_SHA1 (Kbm, (care-of address | correspondent | BA))) + New text Binding Acknowledgement The Binding Update is in some cases acknowledged by the correspondent node. The contents of the message are as follows: Vogt Expires August 31, 2006 [Page 16] Internet-Draft Early Binding Updates for Mobile IPv6 February 2006 * Source Address = correspondent * Destination Address = care-of address * Parameters: + sequence number (within the Binding Update message header) + First (96, HMAC_SHA1 (Kbm, (care-of address | correspondent | BA))) The binding management key, Kbm, used to authenticate the Binding Acknowledgment message is the same Kbm that was used to authenticate the corresponding Binding Update message. I.e., if the Binding Acknowledgment message is sent in response to an early Binding Update message, only a home keygen token is required to compute the Kbm. If the Binding Acknowledgment message is sent in response to a standard Binding Update message, the Kbm is based on a home and a care-of keygen token. - Original text Bindings established with correspondent nodes using keys created by way of the return routability procedure MUST NOT exceed MAX_RR_BINDING_LIFETIME seconds (see Section 12). + New text Bindings established with correspondent nodes using keys created by way of the return routability procedure MUST NOT exceed MAX_RR_BINDING_LIFETIME seconds (see Section 12) when registered with a standard Binding Update message. When registered with an early Binding Update message, the bindings MUST NOT exceed TENTATIVE_RR_BINDING_LIFETIME seconds (see Section 12). - Original text Binding Updates may also be sent to delete a previously established binding. In this case, generation of the binding management key depends exclusively on the home keygen token and the care-of nonce index is ignored. + New text If the Care-of Nonce Index field in the Nonce Indices option of a received Binding Update message is zero, the message is considered an early Binding Update message. In this case, generation of the binding management key depends exclusively on the home keygen token and the care-of nonce index is ignored. Likewise, the care-of nonce index is ignored for Binding Update messages that are sent to delete a previously established binding, and the binding management key again depends exclusively on the home Vogt Expires August 31, 2006 [Page 17] Internet-Draft Early Binding Updates for Mobile IPv6 February 2006 keygen token. 5.2 Correspondent Node Operation (Section 9) Modifications to Section 9.1, "Conceptual Data Structures": - Original text Each Binding Cache entry conceptually contains the following fields: o The home address of the mobile node for which this is the Binding Cache entry. This field is used as the key for searching the Binding Cache for the destination address of a packet being sent.' o The care-of address for the mobile node indicated by the home address field in this Binding Cache entry. o A lifetime value, indicating the remaining lifetime for this Binding Cache entry. The lifetime value is initialized from the Lifetime field in the Binding Update that created or last modified this Binding Cache entry. + New text Each Binding Cache entry conceptually contains the following fields: o The home address of the mobile node for which this is the Binding Cache entry. This field is used as the key for searching the Binding Cache for the destination address of a packet being sent.' o The care-of address for the mobile node indicated by the home address field in this Binding Cache entry. o The previous care-of address that was replaced by the currently registered, active care-of address. The previous care-of address is needed for proactive handoff support, which may require a correspondent node to receive packets from the previous care-of address for a short period, even though a new active care-of address has already been (proactively) registered [PETANDER05]. Packets that the correspondent node sends always use the currently active care-of address, however. The previous care-of address is copied from the currently Vogt Expires August 31, 2006 [Page 18] Internet-Draft Early Binding Updates for Mobile IPv6 February 2006 active care-of address during a correspondent registration. o A lifetime value that indicates the remaining lifetime for this Binding Cache entry. The lifetime value is initialized from the Lifetime field in the Binding Update that created or last modified this Binding Cache entry. o A lifetime value that indicates the remaining lifetime for the previous care-of address. The lifetime of the previous care-of address is initialized to the minimum of PREVIOUS_CAREOF_ADDRESS_LIFETIME and the lifetime of the currently active care-of address just before this active care-of address is replaced and becomes the previous care-of address. Modifications to Section 9.3.1, "Receiving Packets with Home Address Option": - Original text Mobile nodes can include a Home Address destination option in a packet if they believe the correspondent node has a Binding Cache entry for the home address of a mobile node. Packets containing a Home Address option MUST be dropped if there is no corresponding Binding Cache entry. A corresponding Binding Cache entry MUST have the same home address as appears in the Home Address destination option, and the currently registered care-of address MUST be equal to the source address of the packet. These tests MUST NOT be done for packets that contain a Home Address option and a Binding Update. - New text Mobile nodes can include a Home Address destination option in a packet if they believe the correspondent node has a Binding Cache entry for the home address of a mobile node. When processing an incoming packet that contains a Home Address destination option, the correspondent node verifies whether it has a Binding Cache entry with (i) the same home address as appears in the Home Address destination option of the incoming packet and (ii) either the currently registered care-of address or the previous care-of address MUST be equal to the source address of the packet. In addition, the correspondent node ensures that, if the packet's source address is equal to the previous care-of address in the Binding Cache entry, the remaining lifetime for that previous care-of address is not yet expired. These tests MUST NOT be done for packets that contain a Home Address option and a Binding Vogt Expires August 31, 2006 [Page 19] Internet-Draft Early Binding Updates for Mobile IPv6 February 2006 Update. Modifications to Section 9.3.4, "Receiving ICMP Error Messages": - Original text Thus, in all cases, any meaningful ICMP error messages caused by packets from a correspondent node to a mobile node will be returned to the correspondent node. If the correspondent node receives persistent ICMP Destination Unreachable messages after sending packets to a mobile node based on an entry in its Binding Cache, the correspondent node SHOULD delete this Binding Cache entry. Note that if the mobile node continues to send packets with the Home Address destination option to this correspondent node, they will be dropped due to the lack of a binding. For this reason it is important that only persistent ICMP messages lead to the deletion of the Binding Cache entry. + New text Thus, in all cases, any meaningful ICMP error messages caused by packets from a correspondent node to a mobile node will be returned to the correspondent node. If the correspondent node receives persistent ICMP Destination Unreachable messages after sending packets to a mobile node based on an entry in its Binding Cache, the correspondent node SHOULD delete this Binding Cache entry. Note that if the mobile node continues to send packets with the Home Address destination option to this correspondent node, they will be dropped due to the lack of a binding. For this reason it is important that only persistent ICMP messages lead to the deletion of the Binding Cache entry. In particular, packets in flight from the correspondent node to an old location of the mobile node may elicit ICMP Destination Unreachable messages from an access router after the mobile node has changed IP connectivity. The correspondent node may also receive ICMP Destination Unreachable messages, shortly after the correspondent registration for a proactive handoff, for packets that arrive at the mobile node's prospective access router before the mobile node attaches itself. The actual number of ICMP Destination Unreachable messages depends on topological properties of the involved routing paths, the eagerness of the prospective access router in sending ICMP messages, as well as the time needed by the mobile node to connect to the new link. The correspondent node ought to accept a small number of these messages without assuming the Binding Cache entry being incorrect. Vogt Expires August 31, 2006 [Page 20] Internet-Draft Early Binding Updates for Mobile IPv6 February 2006 Modifications to Section 9.5.1, "Receiving Binding Updates": - Original text A Nonce Indices mobility option MUST be present, and the Home and Care-of Nonce Index values in this option MUST be recent enough to be recognized by the correspondent node. (Care-of Nonce Index values are not inspected for requests to delete a binding.) + New text A Nonce Indices mobility option MUST be present, and the Home Nonce Index value in this option MUST be recent enough to be recognized by the correspondent node. If the received Binding Update message is not a request to delete a binding, and if the Care-of Nonce Index value in the option is non-zero, the Care-of Nonce Index value MUST also be recent enough to be recognized by the correspondent node. - Original text The correspondent node MUST re-generate the home keygen token and the care-of keygen token from the information contained in the packet. It then generates the binding management key Kbm and uses it to verify the authenticator field in the Binding Update as specified in Section 6.1.7. + New text The correspondent node MUST re-generate the home keygen token and, if needed, the care-of keygen token from the information contained in the packet. It then generates the binding management key Kbm and uses it to verify the authenticator field in the Binding Update as specified in Section 6.1.7. Modifications to Section 9.5.2, "Requests to Cache a Binding": - Original text In this case, the receiving node SHOULD create a new entry in its Binding Cache for this home address, or update its existing Binding Cache entry for this home address, if such an entry already exists. The lifetime for the Binding Cache entry is initialized from the Lifetime field specified in the Binding Update, although this lifetime MAY be reduced by the node caching the binding; the lifetime for the Binding Cache entry MUST NOT be greater than the Lifetime value specified in the Binding Update. Vogt Expires August 31, 2006 [Page 21] Internet-Draft Early Binding Updates for Mobile IPv6 February 2006 + New text In this case, the receiving node SHOULD create a new entry in its Binding Cache for this home address, or update its existing Binding Cache entry for this home address, if such an entry already exists. The previous care-of address in the Binding Cache entry is set to the currently active care-of address, if any, and its lifetime is initialized to the minimum of PREVIOUS_CAREOF_ADDRESS_LIFETIME and the lifetime of the currently active care-of address. The currently active care-of address is then replaced by the new care-of address indicated in the Binding Update message. The lifetime for the Binding Cache entry is usually initialized from the Lifetime field specified in the received Binding Update message. The lifetime MAY be reduced by the node caching the binding, but it MUST NOT be greater than the Lifetime value specified in the Binding Update message. Furthermore, in case of a standard Binding Update message, the lifetime MUST NOT be greater than MAX_RR_BINDING_LIFETIME, and in case of an early Binding Update message, it MUST NOT be greater than TENTATIVE_RR_BINDING_LIFETIME. Modifications to Section 9.5.3, "Requests to Delete a Binding": - Original text If the Binding Cache entry was created by use of return routability nonces, the correspondent node MUST ensure that the same nonces are not used again with the particular home and care-of address. If both nonces are still valid, the correspondent node has to remember the particular combination of nonce indexes, addresses, and sequence number as illegal until at least one of the nonces has become too old. + New text If the Binding Cache entry was created by use of return routability nonces, the correspondent node MUST ensure that the same nonces are not used again with the particular home and care-of address. If both nonces are still valid, the correspondent node has to remember the particular combination of nonce indexes, addresses, and the sequence number used in this Binding Update message as illegal until at least one of the nonces has become too old. In addition, if the home nonce is still valid, the correspondent node has to remember the combination of home nonce index, addresses, and the sequence number used in the Vogt Expires August 31, 2006 [Page 22] Internet-Draft Early Binding Updates for Mobile IPv6 February 2006 previous early Binding Update message as illegal until the home nonce has become too old. Modifications to Section 9.5.5, "Sending Binding Refresh Requests": - Original text If the sender knows that the Binding Cache entry is still in active use, it MAY send a Binding Refresh Request message to the mobile node in an attempt to avoid this overhead and latency due to deleting and recreating the Binding Cache entry. This message is always sent to the home address of the mobile node. + New text If the sender knows that the Binding Cache entry is still in active use, and if the registered care-of address is not in UNVERIFIED state, the sender MAY send a Binding Refresh Request message to the mobile node in an attempt to avoid this overhead and latency due to deleting and recreating the Binding Cache entry. This message is always sent to the home address of the mobile node. The Binding Refresh Request message SHOULD NOT be sent if the registered care-of address is in UNVERIFIED state because the binding lifetime is very limited in this case anyway. 5.3 Home Agent Operation (Section 10) Modifications to Section 10.3.1, "Primary Care-of Address Registration": - Original text If home agent accepts the Binding Update, it MUST then create a new entry in its Binding Cache for this mobile node or update its existing Binding Cache entry, if such an entry already exists. The Home Address field as received in the Home Address option provides the home address of the mobile node. + New text If home agent accepts the Binding Update, it MUST then create a new entry in its Binding Cache for this mobile node or update its existing Binding Cache entry, if such an entry already exists. The Home Address field as received in the Home Address option provides the home address of the mobile node. The previous Vogt Expires August 31, 2006 [Page 23] Internet-Draft Early Binding Updates for Mobile IPv6 February 2006 care-of address in the Binding Cache entry as well as the lifetime of the previous care-of address are set as described in section 9.5.2. - Original text If the home agent does not reject the Binding Update as described above, then it MUST delete any existing entry in its Binding Cache for this mobile node. Then, the home agent MUST return a Binding Acknowledgement to the mobile node, constructed as follows: + New text If the home agent does not reject the Binding Update as described above, then it MUST deactivate any existing entry in its Binding Cache for this mobile node as follows: The previous care-of address in the Binding Cache entry is set to the currently active care-of address, and its lifetime is initialized to the minimum of PREVIOUS_CAREOF_ADDRESS_LIFETIME and the lifetime of the active care-of address. The active care-of address is then set to the mobile node's home address, indicating that packets for the mobile node are henceforth to be delivered directly, i.e., without the addition of a type-2 routing header. The lifetime of the active care-of address is set to the same value as the lifetime of the previous care-of address. The home agent SHOULD continue to accept encapsulated packets that arrive from the previous care-of address, decapsulate them, and forward them to the respective destination, until the lifetime of the previous care-of address expires. This is necessary for the support of proactive handoffs, during which the mobile node may send packets from its old location for a while before it moves to the home network [PETANDER05]. The Binding Cache entry MUST be deleted when this lifetime expires. When the home agent has updated the previous and active care-of addresses, it MUST return a Binding Acknowledgement to the mobile node, constructed as follows: Modifications to Section 10.4.5, "Handling Reverse Tunneled Packets": - Original text Vogt Expires August 31, 2006 [Page 24] Internet-Draft Early Binding Updates for Mobile IPv6 February 2006 Unless a binding has been established between the mobile node and a correspondent node, traffic from the mobile node to the correspondent node goes through a reverse tunnel. Home agents MUST support reverse tunneling as follows: + New text Unless a binding has been established between the mobile node and a correspondent node, traffic from the mobile node to the correspondent node goes through a reverse tunnel. Packets reveived through the tunnel interface typically use the mobile node's primary care-of address as the source address in the outer IPv6 header. However, it is RECOMMENDED that the home agent in addition accepts packets on the tunnel interface that use the previous care-of address, stored in the mobile node's Binding Cache entry, as long as the lifetime of that care-of address has not yet expired. This is necessary for the support of proactive handoffs, as described in section 10.3.2. Home agents MUST support reverse tunneling as follows: - Original text o Otherwise, when a home agent decapsulates a tunneled packet from the mobile node, the home agent MUST verify that the Source Address in the tunnel IP header is the mobile node's primary care-of address. Otherwise, any node in the Internet could send traffic through the home agent and escape ingress filtering limitations. This simple check forces the attacker to know the current location of the real mobile node and be able to defeat ingress filtering. This check is not necessary if the reverse- tunneled packet is protected by ESP in tunnel mode. + New text o Otherwise, when a home agent decapsulates a tunneled packet from the mobile node, the home agent MUST verify that the Source Address in the tunnel IP header is correct. At a minimum, the home agent MUST accept packets from the mobile node's primary care-of address, but it SHOULD also accept packets from the mobile node's previous care-of address, as stored in the Binding Cache entry. Any packet not from either the primary care-of address or the previous care-of address MUST be discarded. If the Source Address in the tunnel IP header is the previous care-of address, then the home agent MUST in addition verify that the lifetime for this address has not yet expired. Without these checks, any node in the Internet could send traffic through the home agent and escape Vogt Expires August 31, 2006 [Page 25] Internet-Draft Early Binding Updates for Mobile IPv6 February 2006 ingress filtering limitations. The checks force the attacker to know the current location of the real mobile node and be able to defeat ingress filtering. They are not necessary if the reverse-tunneled packet is protected by ESP in tunnel mode. 5.4 Mobile Node Operation (Section 11) Modifications to Section 11.1, "Conceptual Data Structures": - Original text The Binding Update List records information for each Binding Update sent by this mobile node, in which the lifetime of the binding has not yet expired. The Binding Update List includes all bindings sent by the mobile node either to its home agent or correspondent nodes. It also contains Binding Updates which are waiting for the completion of the return routability procedure before they can be sent. However, for multiple Binding Updates sent to the same destination address, the Binding Update List contains only the most recent Binding Update (i.e., with the greatest Sequence Number value) sent to that destination. The Binding Update List MAY be implemented in any manner consistent with the external behavior described in this document. + New text The Binding Update List records information for each Binding Update sent by this mobile node, in which the lifetime of the binding has not yet expired. The Binding Update List includes all bindings sent by the mobile node either to its home agent or correspondent nodes. It also contains Binding Updates which are waiting for the completion of the return routability procedure before they can be sent. However, for multiple Binding Updates sent to the same destination address, the Binding Update List contains only the most recent early Binding Update and the most recent standard Binding Update (i.e., the respective messages with the greatest Sequence Number values) sent to that destination. The Binding Update List MAY be implemented in any manner consistent with the external behavior described in this document. - Original text Vogt Expires August 31, 2006 [Page 26] Internet-Draft Early Binding Updates for Mobile IPv6 February 2006 Each Binding Update List entry conceptually contains the following fields: o The IP address of the node to which a Binding Update was sent. o The home address for which that Binding Update was sent. o The care-of address sent in that Binding Update. This value is necessary for the mobile node to determine if it has sent a Binding Update while giving its new care-of address to this destination after changing its care-of address. o The initial value of the Lifetime field sent in that Binding Update. o The remaining lifetime of that binding. This lifetime is initialized from the Lifetime value sent in the Binding Update and is decremented until it reaches zero, at which time this entry MUST be deleted from the Binding Update List. o The maximum value of the Sequence Number field sent in previous Binding Updates to this destination. The Sequence Number field is 16 bits long and all comparisons between Sequence Number values MUST be performed modulo 2**16 (see Section 9.5.1). o The time at which a Binding Update was last sent to this destination, as needed to implement the rate limiting restriction for sending Binding Updates. o The state of any retransmissions needed for this Binding Update. This state includes the time remaining until the next retransmission attempt for the Binding Update and the current state of the exponential back-off mechanism for retransmissions. o A flag specifying whether or not future Binding Updates should be sent to this destination. The mobile node sets this flag in the Binding Update List entry when it receives an ICMP Parameter Problem, Code 1, error message in response to a return routability message or Binding Update sent to that destination, as described in Section 11.3.5. - New text Each Binding Update List entry conceptually contains the following fields: o The IP address of the node to which a Binding Update was sent. o The home address for which that Binding Update was sent. o The care-of address sent in that Binding Update. This value is necessary for the mobile node to determine if it has sent a Binding Update while giving its new care-of address to this destination after changing its care-of address. Vogt Expires August 31, 2006 [Page 27] Internet-Draft Early Binding Updates for Mobile IPv6 February 2006 o The initial value of the Lifetime field sent in that Binding Update. o The remaining lifetime of that binding. This lifetime is initialized from the Lifetime value sent in the Binding Update and is decremented until it reaches zero, at which time this entry MUST be deleted from the Binding Update List. o The maximum value of the Sequence Number field sent in previous standard Binding Updates to this destination. The Sequence Number field is 16 bits long and all comparisons between Sequence Number values MUST be performed modulo 2**16 (see Section 9.5.1). o The maximum value of the Sequence Number field sent in previous early Binding Updates to this destination. The Sequence Number field is 16 bits long and all comparisons between Sequence Number values MUST be performed modulo 2**16. o The time at which a standard Binding Update was last sent to this destination, as needed to implement the rate limiting restriction for sending standard Binding Updates. o The time at which an early Binding Update was last sent to this destination, as needed to implement the rate limiting restriction for sending early Binding Updates. o The state of any retransmissions needed for the last standard Binding Update. This state includes the time remaining until the next retransmission attempt for the standard Binding Update and the current state of the exponential back-off mechanism for retransmissions. o The state of any retransmissions needed for the last early Binding Update. This state includes the time remaining until the next retransmission attempt for the early Binding Update and the current state of the exponential back-off mechanism for retransmissions. o A flag specifying whether or not future standard Binding Updates should be sent to this destination. The mobile node sets this flag in the Binding Update List entry when it receives an ICMP Parameter Problem, Code 1, error message in response to a return routability message or Binding Update sent to that destination, as described in Section 11.3.5. o A flag specifying whether or not future early Binding Updates should be sent to this destination. The mobile node sets this flag in the Binding Update List entry, as described in Section TODO, when it determines that the correspondent node supports regular Mobile IPv6 route optimization, but does not recognize early Binding Updates. Modifications to Section 11.3.1, "Sending Packets While Away from Home": Vogt Expires August 31, 2006 [Page 28] Internet-Draft Early Binding Updates for Mobile IPv6 February 2006 - Original text * The entry indicates that a binding has been successfully created. + New text * The entry indicates that a regular or tentative binding has been successfully created. New Section 11.5.5, "Movement Anticipation and Proactive Handoff Management": + New text A mobile node may be able to anticipate movements and acquire the prefixes of its prospective next default router by some external means. The mobile node MAY then proactively form a new care-of address and register this with its home agent while still connected to the old link. The Binding Update MUST then have the currently active care-of address in the IPv6 header's Source Address field, and it MUST carry the home address in a Home Address destination option and the new care-of address in an Alternate Care-of Address mobility option. Furthermore, the Home Registration (H) and Acknowledge (A) bits MUST be set. The mobile node implements its own policy as to when it initiates the link-layer handoff to the new link. In a typical case, the mobile node waits for a Binding Acknowledgment on the old link. This can be the Binding Acknowledgment from the home agent or one from a correspondent node (see Section 11.7.2). Signal conditions on the old link may force the mobile node to move to the new link at an earlier time, however. Furthermore, the mobile node MAY proactively send a Binding Update from the home link shortly before it leaves the home link and moves to a different link. This Binding Update has the home address in the IPv6 header's Source Address field and the new care-of address in an Alternate Care-of Address mobility option. The Home Registration (H) and Acknowledge (A) bits MUST be set. The Binding Update SHOULD also include a Home Address destination option. Since the mobile node may not know the IP address of a home agent to which it could send the Binding Update, the mobile node may have to anycast an ICMPv6 Dynamic Home Agent Address Discovery Request message on the home link. Home agents SHOULD be prepared to receive such a message on an interface attaching to the home link. Vogt Expires August 31, 2006 [Page 29] Internet-Draft Early Binding Updates for Mobile IPv6 February 2006 The mobile node MAY also proactively send a Binding Update for de- registration shortly before it returns to its home link after a period of roaming. This Binding Update MUST have the currently active care-of address in the IPv6 header's Source Address field, and it MUST carry the home address in both a Home Address destination option as well as an Alternate Care-of Address mobility option. The Home Registration (H) and Acknowledge (A) bits MUST be set, and the Lifetime field MUST be set to zero. In all of the cases described above, the mobile node sends the Binding Update on a link that it will soon leave. The new care-of address, or home address if returning home, hence cannot yet be configured on the interface undergoing handoff at that time. Instead, the mobile node configures the new care-of address or home address as soon as it attaches to the new link, e.g., in response to a link-layer notification indicating link establishment. Unless the mobile node returns to its home link prior to the expiration of the current binding at the home agent, the mobile node MUST set the address to Optimistic state [ODAD] and use Optimistic Duplicate Address Detection [ODAD] for verifying uniqueness of the address on the new link. A simple mechanism to obtain the prefixes that can be used in the proactive construction of a new care-of address is the following: The mobile node maintains a least-recently-used cache to map the link-layer addresses of a visited access point onto the set of prefixes advertised by routers on the link to which this access point connects. This allows the mobile node to proactively resolve these prefixes during future handoffs to that link. The technique performs well in scenarios where mobile nodes tend to revisit a rather stable set of access points, e.g., at home or office environments, campuses, conferences, and local shopping centers. More sophisticated mechanisms, which may also allow prefix resolution for previously unvisited links, are beyond the scope of this document, however. New Section 11.7.1, "Sending Binding Updates to the Home Agent": - Original text After deciding to change its primary care-of address as described in Section 11.5.1 and Section 11.5.2, a mobile node MUST register this care-of address with its home agent in order to make this its primary care-of address. Vogt Expires August 31, 2006 [Page 30] Internet-Draft Early Binding Updates for Mobile IPv6 February 2006 + New text After deciding to change its primary care-of address as described in Section 11.5.1, Section 11.5.2, or Section 11.5.5, a mobile node MUST register this care-of address with its home agent in order to make this its primary care-of address. New Section 11.7.2, "Correspondent Registration": - Original text Upon successfully completing the return routability procedure, and after receiving a successful Binding Acknowledgement from the Home Agent, a Binding Update MAY be sent to the correspondent node. In any Binding Update sent by a mobile node, the care-of address (either the Source Address in the packet's IPv6 header or the Care-of Address in the Alternate Care-of Address mobility option of the Binding Update) MUST be set to one of the care-of addresses currently in use by the mobile node or to the mobile node's home address. A mobile node MAY set the care-of address differently for sending Binding Updates to different correspondent nodes. A mobile node MAY also send a Binding Update to such a correspondent node, instructing it to delete any existing binding for the mobile node from its Binding Cache, as described in Section 6.1.7. Even in this case a successful completion of the return routability procedure is required first. If the care-of address is not set to the mobile node's home address, the Binding Update requests that the correspondent node create or update an entry for the mobile node in the correspondent node's Binding Cache. This is done in order to record a care-of address for use in sending future packets to the mobile node. In this case, the value specified in the Lifetime field sent in the Binding Update SHOULD be less than or equal to the remaining lifetime of the home registration and the care-of address specified for the binding. The care-of address given in the Binding Update MAY differ from the mobile node's primary care-of address. If the Binding Update is sent to the correspondent node, requesting the deletion of any existing Binding Cache entry it has for the mobile node, the care-of address is set to the mobile node's home address and the Lifetime field set to zero. In this case, generation of the binding management key depends exclusively on the home keygen token (Section 5.2.5). The care-of nonce index Vogt Expires August 31, 2006 [Page 31] Internet-Draft Early Binding Updates for Mobile IPv6 February 2006 SHOULD be set to zero in this case. In keeping with the Binding Update creation rules below, the care-of address MUST be set to the home address if the mobile node is at home, or to the current care-of address if it is away from home. + New text After a home keygen token has been obtained through the return routability procedure, an early Binding Update or a Binding Update for de-registration MAY be sent to the correspondent node. An early Binding Update requests the correspondent node to create or update an entry for the mobile node in the correspondent node's Binding Cache. This is done in order to record a care-of address for use in sending future packets to the mobile node. A Binding Update for de-registration requests the correspondent node to delete any existing Binding Cache entry it has for the mobile node, as described in Section 6.1.7. In both cases, generation of the binding management key depends exclusively on the home keygen token (Section 5.2.5), and the Care-of Nonce Index field in the Nonce Indices mobility option MUST be set to zero. An early Binding Update MAY already be sent in a proactive manner if the mobile node is able to anticipate movements and acquire the prefixes of its prospective next default router while still connected to the old link (see Section 11.5.5). The mobile node can then form a new care-of address prior to handoff. The early Binding Update MUST have the currently active care-of address in the IPv6 header's Source Address field, and it MUST carry the home address in a Home Address destination option and the new care-of address in an Alternate Care-of Address mobility option. The mobile node MAY also proactively send an early Binding Update from the home link shortly before it leaves the home link and moves to a different link. This early Binding Update has the home address in the IPv6 header's Source Address field and the new care-of address in an Alternate Care-of Address mobility option. The Binding Update SHOULD also include a Home Address destination option. Furthermore, the mobile node MAY proactively send a Binding Update for de-registration shortly before it returns to its home link after a period of roaming. This Binding Update MUST have the currently active care-of address in the IPv6 header's Source Address field, and it MUST carry the home address in both a Home Address destination option as well as an Alternate Care-of Address mobility option. Vogt Expires August 31, 2006 [Page 32] Internet-Draft Early Binding Updates for Mobile IPv6 February 2006 The Lifetime field in an early Binding Update MUST be set to a value less than or equal to TENTATIVE_RR_BINDING_LIFETIME; the Lifetime field in a Binding Update for de-registration MUST be set to zero. If an early Binding Update is sent before a Binding Acknowledgment has been received from the home agent for the same pair of home and care-of addresses, the mobile node MUST be prepared to immediately delete the new binding at the correspondent node should the home registration fail. The overhead associated with such premature correspondent registrations can be avoided if the mobile node waits for a successful Binding Acknowledgment from the home agent before it sends the early Binding Update to the correspondent node. This may come at the cost of increased handoff latency, however. After obtaining a home keygen token and a care-of keygen token through the return routability procedure, and after receiving a successful Binding Acknowledgment from the home agent, a standard Binding Update MAY be sent to the correspondent node. This standard Binding Update SHOULD be sent if an early Binding Update has already been sent to the correspondent node during the same registration process. The Lifetime field in the Binding Update SHOULD be set to a value less than or equal to the remaining lifetime of the home registration and the care-of address specified in the message. The care-of address given in the Binding Update MAY differ from the mobile node's primary care-of address. Unless a Binding Update is sent for de-registration, the care-of address (either the Source Address in the packet's IPv6 header or the Care-of Address in the Alternate Care-of Address mobility option of the Binding Update) MUST be set to one of the care-of addresses currently in use by the mobile node. A mobile node MAY set the care-of address differently for sending Binding Updates to different correspondent nodes. If the Binding Update is sent for de-registration, in keeping with the Binding Update creation rules below, the care-of address MUST be set to the home address if the mobile node is at home, or to the current care-of address if it is away from home. - Original text If the mobile node wants to ensure that its new care-of address has been entered into a correspondent node's Binding Cache, the mobile node needs to request an acknowledgement by setting the Acknowledge (A) bit in the Binding Update. Vogt Expires August 31, 2006 [Page 33] Internet-Draft Early Binding Updates for Mobile IPv6 February 2006 + New text If the mobile node wants to ensure that its new care-of address has been entered into a correspondent node's Binding Cache, the mobile node needs to request an acknowledgment by setting the Acknowledge (A) bit in the Binding Update. The Acknowledge bit MUST be set if the Binding Update is proactively sent before the mobile node has actually moved to the link to which the new care-of address (or home address, in case of a proactive de- registration) belongs. The mobile node can then attempt to defer the link-layer handoff to the new link until it receives a Binding Acknowledgment from this correspondent node. If the mobile node moves to a new link before it has received a Binding Acknowledgment from a correspondent node to which it proactively sent a Binding Update from the previous link, it MUST resend the Binding Update from the new link. - Original text Each Binding Update MUST have a Sequence Number greater than the Sequence Number value sent in the previous Binding Update to the same destination address (if any). The sequence numbers are compared modulo 2**16, as described in Section 9.5.1. There is no requirement, however, that the Sequence Number value strictly increase by 1 with each new Binding Update sent or received, as long as the value stays within the window. The last Sequence Number value sent to a destination in a Binding Update is stored by the mobile node in its Binding Update List entry for that destination. If the sending mobile node has no Binding Update List entry, the Sequence Number SHOULD start at a random value. The mobile node MUST NOT use the same Sequence Number in two different Binding Updates to the same correspondent node, even if the Binding Updates provide different care-of addresses. + New text Each Binding Update MUST have a Sequence Number greater than the Sequence Number value sent in the previous Binding Update to the same destination address (if any). The sequence numbers are compared modulo 2**16, as described in Section 9.5.1. There is no requirement, however, that the Sequence Number value strictly increase by 1 with each new Binding Update sent or received, as long as the value stays within the window. The last Sequence Number value sent to a destination in a standard Binding Update as well as the last Sequence Number value sent to the same destination in an early Binding Update are stored by the mobile node in its Binding Update List entry for that destination. If the sending mobile node has no Binding Update List entry, the Vogt Expires August 31, 2006 [Page 34] Internet-Draft Early Binding Updates for Mobile IPv6 February 2006 Sequence Number SHOULD start at a random value. The mobile node MUST NOT use the same Sequence Number in two different Binding Updates to the same correspondent node, even if the Binding Updates provide different care-of addresses. New Section 11.7.3, "Receiving Binding Acknowledgements": - Original text o The Sequence Number field matches the Sequence Number sent by the mobile node to this destination address in an outstanding Binding Update. + New text o The Sequence Number field matches the Sequence Number sent by the mobile node to this destination address in an outstanding Binding Update. Note that, for Binding Acknowledgments reveived from a correspondent node, the mobile node needs to compare the Sequence Number value of the Binding Acknowledgment to the right value in its Binding Update List entry, depending on whether the Binding Acknowledgment corresponds to a standard Binding Update or to an early Binding Update. 6. Security Considerations The Mobile IPv6 extensions specified in this document differ from standard Mobile IPv6 in the way a mobile node authenticates itself to a correspondent node, and when it provides evidence of its reachability at the claimed care-of address. According to [RFC3775], a mobile node must have acquired valid home and care-of keygen tokens before it can initiate a correspondent registration. This requires the mobile node to be reachable at both its home and claimed care-of address. The extensions defined in this document relax this rule in that they allow introduce an early Binding Update message that can be authenticated with a home keygen token alone. This implies two questions: First, does lack of a care-of-address test render authentication through early Binding Update messages less secure than authentication through standard Binding Update messages? Second, inhowfar can early Binding Update messages be misused to register a spoofed care-of address and effect malicious packet redirection? The following elaborates on both of these questions. Vogt Expires August 31, 2006 [Page 35] Internet-Draft Early Binding Updates for Mobile IPv6 February 2006 6.1 Authentication At first glance, it may seem that authentication for early Binding Update messages is weaker than that for standard Binding Update messages: A standard Binding Update message is authenticated based on two tokens transmitted via separate paths, so whoever generates it must be on the intersection of both paths. The paths are in some sense independent even if they happen to coincide topologically, because only one of the paths is IPsec-protected between the mobile node and the home agent. However, only the home keygen token can prove the mobile node's identity; an attacker can generate a care-of keygen token for any address through which it is itself reachable. The attacker can consequently acquire both tokens once it is in a position to intercept a Home Test message that a correspondent node has sent to the mobile node's home address. Due to the IPsec tunnel between the mobile node and the home agent, this position can only be somewhere on the path between the correspondent node and the home agent. In summary, the care-of keygen token does not strengthen the authentication capability of a standard Binding Update message. An early Binding Update is therefore as secure as a standard Binding Update message with respect to authentication. It is worthwhile emphasizing that the early Binding Update message is authenticated in just the same way as a standard Binding Update message for de- registration. 6.2 Reachability A mobile node can use an early Binding Update message to register a new care-of address without yet having shown that it is reachable at that address. To prevent misuse of this feature for the purpose of redirection-based flooding attacks, appropriate protection must be provided. The specific protection mechanism is at the discretion of the correspondent node. Section 4 discusses some approaches that correspondent nodes may follow. It depends on the particular deployment scenario which of these strategies applies best. Ingress filtering [RFC2827] is usually considered an alternative solution to the reachability problem. If deployed close to the mobile node's IP attachment, ingress filtering can provide reasonable insurance that an unverified care-of address is correct. The technique has two disadvantages, however. One is that it can provide full protection against address spoofing only if it is deployed universally. As long as some operators do not use it, redirection attacks can originate from their networks. Another disadvantage is that ingress filtering evaluates only a packet's IP source address. As a consequence, ingress filtering fails when an early or standard Binding Update message contains the care-of address within an Vogt Expires August 31, 2006 [Page 36] Internet-Draft Early Binding Updates for Mobile IPv6 February 2006 Alternate Care-of Address mobility option. Ingress filtering hence cannot protect a proactive registration procedure. 7. Protocol Constants Section 12 of [RFC3775] defines a set of protocol constants. The Mobile IPv6 extensions specified in this document require the following additional protocol constants. TENTATIVE_RR_BINDING_LIFETIME 10 seconds PREVIOUS_CAREOF_ADDRESS_LIFETIME 10 seconds EARLY_BINDING_UPDATE_RETRIES 3 retransmissions 8. References 8.1 Normative References [CBA] Vogt, C. and J. Arkko, "Credit-Based Authorization for Concurrent Reachability Verification", IETF Internet Draft draft-vogt-mobopts-simple-cba-00.txt (work in progress), February 2006. [ODAD] Moore, N., "Optimistic Duplicate Address Detection for IPv6", IETF Internet Draft draft-ietf-ipv6-optimistic-dad-07.txt (work in progress), December 2005. [RFC3775] Johnson, D., E., C., and J. Arkko, "Mobility Support in IPv6", IETF Request for Comments 3775, June 2004. 8.2 Informational References [PETANDER05] Petander, H. and E. Perera, "Improved Binding Management for Make Before Break Handoffs in Mobile IPv6", IETF Internet Draft draft-petander-mip6-mbb-00.txt (work in progress), October 2005. [RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering: Defeating Denial of Service Attacks which employ IP Source Address Spoofing", RFC 2827, May 2000. [RFC4225] Nikander, P., Arkko, J., Aura, T., Montenegro, G., and E. Vogt Expires August 31, 2006 [Page 37] Internet-Draft Early Binding Updates for Mobile IPv6 February 2006 Nordmark, "Mobile IP Version 6 Route Optimization Security Design Background", IETF Request for Comments 4225, December 2005. Author's Address Christian Vogt Institute of Telematics Universitaet Karlsruhe (TH) P.O. Box 6980 76128 Karlsruhe Germany Email: chvogt@tm.uka.de Appendix A. Acknowledgment For their interest and valuable feedback, the authors thank the MIP6 and MOBOPTS communities, in particular Ralf Beck, Roland Bless, Mark Doll, Francis Dupont, Gregory Daley, Lars Eggert, Daniel Jungbluth, James Kempf, Rajeev Koodli, Tobias Kuefner, Max Laier, Marco Liebsch, Gabriel Montenegro, Nick (Sharkey) Moore, Pekka Nikander, Erik Nordmark, Charles Perkins, Constantin Schimmel, and Kilian Weniger (listed in alphabetical order). Thanks are also due to the development team of the Kame-Shisa Mobile IPv6 implementation. Vogt Expires August 31, 2006 [Page 38] Internet-Draft Early Binding Updates for Mobile IPv6 February 2006 Intellectual Property Statement 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. Disclaimer of Validity 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 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. Copyright Statement Copyright (C) The Internet Society (2006). 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. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Vogt Expires August 31, 2006 [Page 39]