Network Working Group C. Vogt Internet-Draft Univ. of Karlsruhe, Germany Expires: August 18, 2005 February 14, 2005 Early Binding Updates for Mobile IPv6 draft-vogt-mobopts-early-binding-updates-00.txt Status of this Memo This document is an Internet-Draft and is subject to all provisions of Section 3 of RFC 3667. 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 become aware will be disclosed, in accordance with RFC 3668. 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 18, 2005. Copyright Notice Copyright (C) The Internet Society (2005). Abstract Mobile IPv6 defines a return-routability procedure for secure use of route optimization between unacquainted nodes. The handover latency caused by the procedure can significantly impact delay-sensitive applications, however. This document presents an optimization to Mobile IPv6 that eliminates the latency. The optimization is realized as an optional, and fully backward-compatible, extension to Mobile IPv6. Vogt Expires August 18, 2005 [Page 1] Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . 4 2.1 New Terminology . . . . . . . . . . . . . . . . . . . . . 5 2.2 New Message Types . . . . . . . . . . . . . . . . . . . . 5 2.3 Acronyms . . . . . . . . . . . . . . . . . . . . . . . . . 6 3. Optimization Components . . . . . . . . . . . . . . . . . . 7 3.1 Optimistic Behavior . . . . . . . . . . . . . . . . . . . 7 3.2 Proactive Home Address Tests . . . . . . . . . . . . . . . 8 3.3 Tentative Correspondent Registrations . . . . . . . . . . 8 3.4 Concurrent Care-of Address Tests . . . . . . . . . . . . . 9 3.5 Proactive Registrations . . . . . . . . . . . . . . . . . 9 4. Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . 9 5. Handling Unverified Care-of Addresses . . . . . . . . . . . 14 5.1 Dropping Packets . . . . . . . . . . . . . . . . . . . . . 14 5.2 Buffering Packets . . . . . . . . . . . . . . . . . . . . 14 5.3 Diverted Routing . . . . . . . . . . . . . . . . . . . . . 15 5.4 Heuristics . . . . . . . . . . . . . . . . . . . . . . . . 15 5.5 Trusted Communities . . . . . . . . . . . . . . . . . . . 15 5.6 Credit-Based Authorization . . . . . . . . . . . . . . . . 15 5.7 Ingress Filtering . . . . . . . . . . . . . . . . . . . . 16 6. Performance Analysis . . . . . . . . . . . . . . . . . . . . 16 6.1 Basic Mobile IPv6 . . . . . . . . . . . . . . . . . . . . 17 6.2 Optimistic Behavior . . . . . . . . . . . . . . . . . . . 18 6.3 Early Binding Updates . . . . . . . . . . . . . . . . . . 19 7. Security Considerations . . . . . . . . . . . . . . . . . . 21 7.1 Authentication . . . . . . . . . . . . . . . . . . . . . . 21 7.2 Reachability . . . . . . . . . . . . . . . . . . . . . . . 21 8. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . 22 9. Protocol Constants . . . . . . . . . . . . . . . . . . . . . 23 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 23 10.1 Normative References . . . . . . . . . . . . . . . . . . 23 10.2 Informational References . . . . . . . . . . . . . . . . 23 Author's Address . . . . . . . . . . . . . . . . . . . . . . 25 A. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 25 Intellectual Property and Copyright Statements . . . . . . . 26 Vogt Expires August 18, 2005 [Page 2] Internet-Draft Early Binding Updates February 2005 1. Introduction Mobility Support in IPv6 (RFC 3775 [1]), or Mobile IPv6, enables mobile nodes to change their point of IP attachment without loosing active communications connections. It uses two IP addresses per mobile node in order to separate localization semantics from identification semantics: A transient "care-of address" routes to the mobile node"s current point of IP attachment. A static "home address" serves as an identifier at stack layers above IP. The mobile node configures a new care-of address when it detects that it has moved to a different subnet. The home address remains stable across movements. Correspondent nodes can send packets for the mobile node to either address. When they send them to the care-of address, the packets reach the mobile node directly. When they send them to the home address, they will be routed to the mobile node's "home network". There, a non-mobile "home agent" intercepts the packets, encapsulates them, and tunnels them to the care-of address. Vice versa, the mobile node may send its packets from the care-of address directly to the correspondent node, or it may tunnel them to the home agent to have them sent from the home address. Relaying packets through the home agent is called "bidirectional tunneling", sending them directly "route optimization". Route optimization has the appealing property that it saves a lot of routing overhead compared to bidirectional tunneling. Experts deem this more and more important, in particular in the IPv6 Internet, due to the increasing number of mobile nodes. However, route optimization bears a security challenge, since two communication peers do not necessarily have to be acquainted. One may think, e.g., of a mobile user streaming a news video from CNN. It is non-trivial to secure mobility-related signaling between these peers. [11] gives a detailed account on the Mobile IPv6 security design. Relevant to this document are the following two questions. o When the correspondent node receives a command to redirect node X's packets, how can it be sure that it is X itself, rather than a malicious third node, who has send this command? o Assuming that the correspondent node can somehow identify X as the originator of a certain redirection request, how can it rely on X actually being present at the IP address to which packets are to be redirected? The first question raises an authentication issue, the second points to the lack of trust between the peers. There are a variety of possibilities how one could have realized authentication in Mobile IPv6. Amongst them are certificate technology [8], DNSSEC [7], or Vogt Expires August 18, 2005 [Page 3] Internet-Draft Early Binding Updates February 2005 crypto-based identifiers [14][10]. But a desire to be independent from a global, trusted infrastructure as well as IPR restrictions paved the way for a different strategy: return routability. Testing "return routability" of a node X at an IP address A means to check whether X can receive packets sent to A. Since Mobile IPv6 uses the home address as an identifier and the care-of address as a locator, checking return routability of the former can authenticate a mobile node, and checking return routability of the latter can validate a mobile node's presence at the new destination for redirected packets. The advantages of the return-routability procedure are low processing and state requirements as well as an infrastructural independence. A vulnerability to on-path attackers is acceptable because the issue with on-path attacks already applies to the non-mobile Internet and is not mobility-specific (cf. [11]). A disadvantage of the return-routability procedure is its high latency, though: Both a home-address test and a care-of-address test are potentially executed over very long distances, so interactive real-time applications can be significantly impacted by their delay. This document proposes an optional extension to Mobile IPv6, Early Binding Updates, which eliminates the delays caused by the return-routability procedure. The improvement is achieved by doing a home-address test proactively before a handover, allowing a mobile node to optimistically pursue its home and correspondent registrations in parallel, tentatively registering a new care-of address immediately after movement detection and IPv6 Address Autoconfiguration (i.e., without doing the care-of-address test first), and postponing the care-of-address test to a time where usual communications have already been resumed through the new care-of address. This reduces the critical handover latency from two round-trip times to one. Early Binding Updates also allow the mobile node to proactively register a new care-of address with its home agent and correspondent node before moving to that care-of address. This requires an external mechanism to notify the mobile node, at its old point of IP attachment, about an imminent handover and a valid new care-of address [12]. Proactive registrations can eliminate Mobile IPv6 handover signaling entirely. Early Binding Updates for Mobile IPv6 were first presented at the 59th IETF meeting in Seoul, Republic of Korea, in February 2004. 2. Definitions This document uses the terminology and message types specified in RFC 3775. It additionaly introduces a small set of new terminology and Vogt Expires August 18, 2005 [Page 4] Internet-Draft Early Binding Updates February 2005 defines two new message types. Some abbreviations are used for the sake of brevity and preciseness throughout the document. This section summarizes any terminology, message types, and acronyms not already mentioned in RFC 3775. 2.1 New Terminology Proactive Home Address Test A home-address test initiated by a mobile node before handover, the intention being to have a valid Home Keygen Token already available during the critical handover period (cf. Section 3). Tentative Correspondent Registration A correspondent registration with limited lifetime that a mobile node conducts before it initiates a standard correspondent registration. A tentative correspondent registration does not provide evidence to a correspondent node that the mobile node is indeed reachable at the registered care-of address (cf. Section 3). 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 done. 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. Concurrent Care-of Address Test A care-of-address test 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 (cf. Section 3). Proactive Registration A method by which a mobile node may register a new care-of address before moving to that care-of address (cf. Section 3). 2.2 New Message Types Vogt Expires August 18, 2005 [Page 5] Internet-Draft Early Binding Updates February 2005 Early Binding Update A mobile node sends an Early Binding Update message to a correspondent node for tentative correspondent registration. Early Binding Acknowledgement A correspondent node may return an Early Binding Acknowledgement message to a mobile node in response to an Early Binding Update message. 2.3 Acronyms HoTI The Home Test Init message that a mobile node sends to a correspondent node during the home-address test. HoT The Home Test message that a correspondent node returns to a mobile node during the home-address test. CoTI The Care-of Test Init message that a mobile node sends to a correspondent node during the care-of-address test. CoT The Care-of Test message that a correspondent node returns to a mobile node during the care-of-address test. BU[HA] The Binding Update message that a mobile node sends to its home agent during home registration. BA[HA] The Binding Acknowledgement message that a home agent returns to a mobile node during home registration. BU[CN] The Binding Update message that a mobile node sends to a correspondent node during correspondent registration. BA[CN] The Binding Acknowledgement message that a correspondent node returns to a mobile node during correspondent registration. EBU Vogt Expires August 18, 2005 [Page 6] Internet-Draft Early Binding Updates February 2005 The Early Binding Update message that a mobile node sends to a correspondent node during tentative correspondent registration. EBA The Early Binding Acknowledgement message that a correspondent node may return to a mobile node during tentative correspondent registration. RTT[MN,HA] One round-trip time between a mobile node and its home agent. RTT[MN,CN] One round-trip time between a mobile node and a correspondent node, measured on the direct path between the peers. RTT[MN,HA,CN] One round-trip time between a mobile node and a correspondent node for messages bidirectionally routed through the mobile node's home agent. 3. Optimization Components Early Binding Updates for Mobile IPv6 have four basic optimization components: optimistic behavior, proactive home-address tests, tentative correspondent registrations, and concurrent care-of-address test. Optionally, proactive registrations may be used in addition. This section introduces the optimization components. 3.1 Optimistic Behavior RFC 3775 allows a mobile node to pursue a return-routability procedure in parallel with the corresponding home registration. This behavior is "optimistic" in the sense that the return-routability procedure would have been accomplished in vain should the home registration fail or be rejected. Conservative Mobile IPv6 implementations for mobile nodes execute the home registration and the return-routability procedure in sequence. E.g., the current version of Kame Shisa [16] activates its return-routability state machine upon reception of a BA{HA}. Optimistic behavior may be applied without Early Binding Updates, but not vice versa. Early Binding Updates go one step further in that they allow the mobile node to not only conduct the return-routability procedure, but also a tentative correspondent registration (see below) simultaneously with the home registration. Vogt Expires August 18, 2005 [Page 7] 3.2 Proactive Home Address Tests RFC 3775 defines a lifetime of 3.5 minutes for Home and Care-of Keygen Tokens. This feature allows a mobile node to authenticate itself during a handover based on a Home Keygen Token that it has already acquired before the handover. Such a proactive home-address test saves a possibly long round-trip time through the home agent during the critical handover period. There are essentially two ways to implement proactive home-address tests. If the mobile node's local link layer provides a trigger that tells the mobile node about an imminent handover, the mobile node can invoke proactive home-address tests on a just-in-time basis. Alternatively, the mobile node may repeat the proactive home-address test whenever the most recently obtained Home Keygen Token is about to expire. Either way, the mobile node has a valid token at hand when a handover occurs. A mobile node should also do proactive home-address tests while it stays at home. This allows the mobile node to apply Early Binding Updates when leaving the home network. The Binding Update List contains information about the state of a home-address test, so the mobile node may keep existing and create new entries in the Binding Update List when at home, just as it does when not at home. Such entries would have the current care-of address set to the mobile node's home address. Implementations must not confuse Binding Update List entries for which a correspondent (de-)registration is pending or still to be initiated from those for which (de-)registration is already complete. In particular should the mobile node not automatically initiate (de-)registration when receiving the HoT from a proactive home-address test. 3.3 Tentative Correspondent Registrations According to RFC 3775, a mobile node may initiate the return-routability procedure for a planned correspondent registration while it is waiting for a BA[HA] acknowledging successful home registration. However, the mobile node must receive this BA[HA] before it can register with the correspondent node. Early Binding Updates allow the mobile node to also pursue a tentative correspondent registration while waiting for the BA[HA]. A tentative correspondent registration has a lifetime just long enough to bridge the expected duration of the remaining registration procedure. It is authenticated with the Home Keygen Token from the most recent proactive home-address test, but lacks proof of a successful care-of-address test. The mobile node replaces a tentative Vogt Expires August 18, 2005 [Page 8] Internet-Draft Early Binding Updates February 2005 correspondent registration with a standard one later during the message exchange. A tentatively registered care-of address is called "unverified", and a care-of address registered the standard way is called "verified". 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. Section 5 discusses a range of possible policies that the correspondent node may apply in different scenarios. 3.4 Concurrent Care-of Address Tests RFC 3775 requires a mobile node to support a correspondent registration with proof of its reachability at the new care-of address. Early Binding Updates allow the mobile node to tentatively register an unverified care-of address without such evidence, and to make up for the care-of-address test after data communications have been resumed. The mobile node affects a standard correspondent registration subsequent to this concurrent care-of-address test, making the unverified care-of address a verified one. 3.5 Proactive Registrations It is conceivable that external mechanisms assist a mobile node before handover in learning a valid care-of address for the new link [12]. This allows the mobile node to register the new care-of address with its home agent and, tentatively, with its correspondent node while it is still connected to the old link. The mobile node initiates a concurrent care-of-address test as soon as it arrives at the new link. It then proceeds with a standard correspondent registration. Proactive home and correspondent registrations are an optional feature of Early Binding Updates. 4. Protocol This section describes the Mobile IPv6 registration procedure when optimized with Early Binding Updates. Note that a mobile node may wish to do route optimization with more than one correspondent node at a time. In this case, the mobile node needs to run a separate correspondent registration with each of them. For the sake of Vogt Expires August 18, 2005 [Page 9] Internet-Draft Early Binding Updates February 2005 simplicity, it is assumed henceforth that there is only a single correspondent node. Figure 1 illustrates the optimized protocol. Mobile Node Home Agent Correspondent Node | | | |=HoTI=========>|-HoTI--------->| | | | |<==========HoT=|<----------HoT-| | | | Handover ~ | | |-BU[HA]------->| | Use new CoA |-EBU-------------------------->| Use unverified CoA |-CoTI------------------------->| | | | |<-------BA[HA]-| | |<--------------------------EBA-| |<--------------------------CoT-| | | | |-BU[CN]----------------------->| Use verified CoA | | | |<-----------------------BA[CN]-| | | | Figure 1: Registration Procedure with Early Binding Updates The mobile node seeks to have a fresh Home Keygen Token acquired prior to any handover. It does so by initiating the home-address test in a proactive way. The test may run periodically whenever the current Home Keygen Token is about to expire. According to RFC 3775, tokens are valid for 3.5 minutes (MAX_TOKEN_LIFETIME [1]), so the interval between successive proactive home-address tests should be a little bit less (HOME_ADDR_TEST_INTERVAL, cf. Section 9). Alternatively, the mobile node's local link layer may provide a trigger indicating when a handover is about to happen. The mobile node may do the proactive home-address test right in time in this case. When the mobile node detects that it has moved to a different network, it configures a new care-of address. The mobile node then sends three messages back to back: a BU[HA] to its home agent, and an EBU and a CoTI to the correspondent node. The BU[HA] initiates the home registration, which uses the same messages and proceeds in exactly the same way as specified in RFC 3775. The EBU is a request for a tentative registration at the correspondent node. It has the same syntax as a standard BU[CN], but its authenticator is calculated Vogt Expires August 18, 2005 [Page 10] Internet-Draft Early Binding Updates February 2005 only with the Home Keygen Token obtained during the most recent home-address test. An EBU is similar to the BU[CN] used during deregistration when the mobile node returns to its home network. It is a newmessage introduced by Early Binding Updates. The CoTI initiates the concurrent care-of-address test. A concurrent care-of-address test uses the same messages and follows the same procedure as specified in RFC 3775, except that data packets may already be exchanged through the new care-of address while the test is in progress. The home agent processes a received BU[HA] according to RFC 3775, binds the mobile node's home address to the new care-of address, and sends a BA[HA] back to the mobile node. When the correspondent node receives the EBU, it tentatively binds the mobile node's home address to the new care-of address. It labels the new care-of address "unverified", because the EBU does not show whether the mobile node is indeed reachable at this address. If the A flag is set in the EBU, the correspondent node sends an EBA back to the mobile node. The EBA is syntactically the same as a standard BA{CN}. 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 5 discusses various policies that the correspondent node may apply. In any case, the correspondent node should not send any further packets to an older care-of address of the mobile node. Vogt Expires August 18, 2005 [Page 11] Internet-Draft Early Binding Updates February 2005 Mobile Node Home Agent Correspondent Node | | | L2-triggered | | | notification |-BU[HA]------->| | |=HoTI=========>|-HoTI--------->| | | | |<-------BA[HA]-| | |<==========HoT=|<----------HoT-| | | | |-EBU-------------------------->| Use unverified CoA | | | L3-triggered |<--------------------------EBA-| handover ~ | | Use new CoA |-CoTI------------------------->| | | | |<--------------------------CoT-| | | | |-BU[CN]----------------------->| Use verified CoA | | | |<-----------------------BA[CN]-| | | | Figure 2: Registration Procedure with Early Binding Updates and Proactive Registrations The local access network may assist the mobile node in doing proactive home and correspondent registrations. The registration procedure is a bit different then, as shown in Figure 2. Proactive registrations require that the mobile node is given a valid care-of address for the new link (to which it wants to move) while it is still connected to the old link. The mobile node can so send a BU[HA], conduct a proactive home-address test, and send an EBU from the old link. The BU[HA] and EBU have an attached Alternate Care-of Address option carrying the new care-of address. Note that this address differs from the source addresses in the messages' IP headers. Moreover, both messages should have the A flag set. The mobile node initiates handover to the new link when it receives the returning EBA. It sends a CoTI as soon as it arrives at the new link and proceeds as it would do if proactive registrations did not apply. The correspondent node processes an incoming CoTI, and returns a Care-of Test message (CoT), in the way described in RFC 3775. RFC 3775 requires that the requested lifetime for a correspondent registration must be less than or equal to the remaining lifetime of the current home registration. The mobile node provides the former Vogt Expires August 18, 2005 [Page 12] Internet-Draft Early Binding Updates February 2005 in the EBU and BU[CN]; the home agent defines the latter in the BA[HA]. As a consequence, the mobile node does not know the home-registration lifetime at the time it sends the EBU. The requested lifetime for a tentative correspondent registration should therefore be very short. Specifically, it must not be greater than TENTATIVE_RR_BINDING_LIFETIME (see Section 9). The EBA is a confirmation that the correspondent node has tentatively registered the mobile node's new care-of address. The correspondent node sends an EBA only if the A flag in the EBU is set. The mobile node should retransmit the EBU only when both an expected EBA and the CoT fail to be delivered. Any retransmission of an EBU message must be synchronized with a retransmission of the CoTI, and such retransmissions must be subject to the rate limitations for CoTI's defined in RFC 3775. The mobile node handles an incoming CoT in the way defined in RFC 3775. Specifically, the mobile node sends the correspondent node a BU[CN], the authenticator of which is calculated with the Care-of Keygen Token from the received CoT and the Home Keygen Token from the most recently received HoT. When the correspondent node receives the BU[CN], it sets the lifetime of the binding between the mobile node's home and care-of addresses as specified in RFC 3775. 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 A flag in the received BU[CN] is set, the correspondent node sends a BA[CN] back to the mobile node. This concludes the correspondent registration from the correspondent node's perspective. A received BA[CN] concludes the correspondent registration from the mobile node's perspective. If an expected BA[CN] fails to be delivered, the mobile node resends the BU[CN] subject to the retransmission limitations specified in RFC 3775. The mobile node should not resend an EBU due to the missing BA, however. Handover efficiency is highest when the correspondent node sends packets to an unverified care-of address directly, but the correspondent node may choose to send them to the home address until it receives a BU[CN] from the mobile node (cf. Section 5). The mobile node must expect to receive the correspondent node's packets encapsulated by its home agent from the time it receives the EBA (or from the time it sends the EBU in case it does not set the A flag in this message) up to when it receives the correspondent node's BA[CN] (or shortly after it has sent the BU[CN] in case it does not set the A flag in this message). Reception of an EBA is not required, but can reconfirm this expectation. The mobile node should not consider Vogt Expires August 18, 2005 [Page 13] Internet-Draft Early Binding Updates February 2005 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. 5. Handling Unverified Care-of Addresses A care-of-address test serves to determine whether a mobile node can really receive packets at the care-of address where it claims to be reachable. This reachability check misses from a tentative correspondent registration. There is hence a possibility that a node illegitimately redirects packets to a third party, even though the lifetime for tentative correspondent registrations is limited to TENTATIVE_RR_BINDING_LIFETIME (cf. Section 9). The severity of such "redirection-based flooding attacks" over conventional flooding attacks not so much emanates from packet redirection per se, but rather from the enormous potential for flooding amplification: Not the attacker itself, but the correspondent node ends up flooding the victim--unknowingly, of course. A correspondent node may apply different policies for choosing the destination address of data packets that it has to send while the recipient's current care-of address is unverified. This section compiles several such policies. Whether or not a particular one is feasible in a given scenarios mainly depends on the level of trust between the correspondent node and the mobile node. In any case must the correspondent node stop sending further packets to an old care-of address of the mobile node, and it must accept packets that the mobile node sends to it from the unverified care-of address. 5.1 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. 5.2 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 Vogt Expires August 18, 2005 [Page 14] Internet-Draft Early Binding Updates February 2005 the care-of address gets verified. 5.3 Diverted Routing 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 must expect to receive such packets encapsulated by its home agent during handover. 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. 5.4 Heuristics The lifetime for tentative correspondent registrations is limited to TENTATIVE_RR_BINDING_LIFETIME (cf. Section 9). If supplemented with a heuristic for misuse detection, this restriction 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. However, some damage from protocol misuse may still occur, even if the heuristic is very responsive. Reactive punishment of a perpetrator may also have little impact when the administrative relationship between the perpetrator and the correspondent node is loose or non-existant. 5.5 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. If the mobile node is unknown, the correspondent node ought to be more cautious while the care-of address is unverified. It may then drop or buffer the packets, or send them to the mobile node's home address. As an example, this strategy could be used by a corporate server which trusts mobile nodes only if they are affiliated to its own company. 5.6 Credit-Based Authorization As previously mentioned, redirection-based flooding attacks are a Vogt Expires August 18, 2005 [Page 15] Internet-Draft Early Binding Updates February 2005 particular threat due to their potential for high amplification. Malicious redirection would lose its attraction to simpler direct flooding attacks if theamplification was by some means inhibited. Such is the approach followed by Credit-Based Authorization for concurrent care-of-address tests [13]. Here, the correspondent node monitors a mobile node's effort for transmission or reception of data packets. It gives credit to the mobile node proportionally to this effort. Packets that the correspondent node sends to an unverified care-of address of the mobile node reduce the credit. The correspondent node discontinues sending further route-optimized packets when no credit is left. It usually sends the packets to the mobile node's home address instead, but it may apply one of the other strategies discussed in this section. It is worthwhile to mention that Credit-Based Authorization facilitates secure use of Alternate Care-of Address options in conjunction with concurrent care-of-address tests. This allows a mobile node to proactively register a new care-of address with its correspondent node before a handover, provided that it can anticipate the handover and foresee a valid new care-of address through some external mechanism. 5.7 Ingress Filtering The correspondent node may be aware that ingress filtering [4] is active on a certain set of IP addresses. E.g., these IP addresses could be allocated to a trusted operator's network. The correspondent node can then send packets to any unverified care-of address from this set without risk and apply a different strategy for other unverified care-of addresses. However, a shortfall of ingress filtering is that it only checks a packet's source address. It hence fails when a to-be-registered care-of address different than the registration message's source address appears in an Alternate Care-of Address option. Proactive correspondent registrations through Alternate Care-of Address options and concurrent care-of-address tests are hence not compatible with ingress filtering (cf. Section 5.6). 6. Performance Analysis This section evaluates the signaling delays of basic Mobile IPv6 without optimistic behavior, Mobile IPv6 with optimistic behavior, and Mobile IPv6 with Early Binding Updates. There is explicit mentioning of optimistic behavior because many Mobile IPv6 implementations for mobile nodes do not use this optimization Vogt Expires August 18, 2005 [Page 16] Internet-Draft Early Binding Updates February 2005 opportunity yet. Signaling delays are measured from the mobile node's perspective, in terms of not being allowed to send and being unable to receive. This document does not yet analyze the efficiency of proactive registrations, but future versions will. Section 5 discusses a number of strategies for handling unverified care-of addresses. Some of them have implications on handover performance. In this section, it is assumed that the correspondent node sends route-optimized packets directly to the mobile node's new, unverified care-of address as soon as it receives an EBU. Note that the overall handover performance does not depend on Mobile IPv6 signaling alone, but also on signaling at other layers of the protocol stack. This includes link-layer authentication [3] and attachment procedures [2], movement detection, IPv6 Neighbor Discovery [5], as well as Address Autoconfiguration and Duplicate Address Detection [6]. This document does not consider these additional delays, however, as this would go beyond its scope. On the other hand, delays at other stack layers are independent of whether basic Mobile IPv6, optimistic behavior, or Early Binding Updates are used. This makes it feasible to focus on Mobile IPv6 signaling. 6.1 Basic Mobile IPv6 This section evalates the signaling delay of basic Mobile IPv6 when optimistic behavior is not applied. I.e., the return-routability procedure does not begin until the mobile node has received a BA[HA] acknowledging successful home registration. RFC 3775 defines that a mobile node must do the following steps before it can use the new care-of address: First, the mobile node must register the new care-of address with its home agent. Second, it must execute the return-routability procedure. Third, the mobile node must register the new care-of address with its correspondent node. A home registration is an exchange of a BU[HA] and a BA[HA] between the mobile node and its home agent. Let RTT[MN,HA] be the round-trip time required for these messages. The home-address test is an exchange of a HoTI and a HoT between the mobile node and the correspondent node. Both of these messages are routed through the home agent. Let their required round-trip time be RTT[MN,HA,CN]. The care-of-address test is an exchange of a CoTI and a CoT between the mobile node and the correspondent node. These messages are transmitted directly between the peers, i.e., they do not (necessarily) pass the home agent. Let the round-trip time that Vogt Expires August 18, 2005 [Page 17] Internet-Draft Early Binding Updates February 2005 these messages need be RTT[MN,CN]. The mobile node must wait for all, the BA[HA], the HoT, and the CoT, before it can register its care-of address with the correspondent node. The correspondent registration, in turn, is an exchange of a BU[CN] and an optional BA[CN]. However, the mobile node does not need to wait for the BA[CN]. It may resume sending route-optimized packets to the correspondent node as soon as it has dispatched the BU[CN]. The signaling delay observed by the mobile node in terms of packet transmission thus amounts to LATENCY[SEND] = RTT[MN,HA] + Max (RTT[MN,HA,CN], RTT[MN,CN]) Given that the end-to-end path through the home agent is typically longest, LATENCY[SEND] = RTT[MN,HA] + RTT[MN,HA,CN] holds in most cases. The correspondent node starts using the mobile node's new care-of address once it receives the BU[CN]. It then takes another 0.5 RTT[MN,CN] time until the first data packet arrives at this address. This is independent of whether or not a BA[CN] is transmitted. Thus, the mobile node's observed signaling delay for receiving packets can be calculated as LATENCY[RECEIVE] = RTT[MN,HA] + Max (RTT[MN,HA,CN], RTT[MN,CN]) + RTT[MN,CN] which should usually reduce to LATENCY[RECEIVE] = RTT[MN,HA] + RTT[MN,HA,CN] + RTT[MN,CN]. If the mobile node has already recently changed its point of network attachment, it may reuse its previously acquired Home Keygen Token without running another home-address test. In this situation, RTT[MN,HA,CN] reduces to zero, so LATENCY[SEND] = RTT[MN,HA] + RTT[MN,CN] and LATENCY[RECEIVE] = RTT[MN,HA] + 2*RTT[MN,CN]. 6.2 Optimistic Behavior Many Mobile IPv6 implementations for mobile nodes execute a home registration and the return-routability procedure in sequence. E.g., the current version of Kame Shisa [16] activates its return-routability state machine upon reception of a BA[HA]. However, RFC 3775 leaves sufficient room for pursuing the return-routability procedure already in parallel with the home registration. This section explicitly considers the performance benefit of this optimistic behavior. As mentioned previously, the latencies for a home registration, a Vogt Expires August 18, 2005 [Page 18] Internet-Draft Early Binding Updates February 2005 home-address test, and a care-of-address test are RTT[MN,HA], RTT[MN,HA,CN], and RTT[MN,CN], respectively. RFC 3775 defines that the mobile node must wait for all, the BA[HA], the HoT, and the CoT, before it can send the BU[CN]. As the mobile node may start sending route-optimized packets to the correspondent node right after it has dispatched the BU[CN], its observed handover latency for sending packets amounts to LATENCY[SEND,OPTIMISTIC] = Max (RTT[MN,HA], RTT[MN,HA,CN], RTT[MN,CN]) Given that the end-to-end path through the home agent is typically longest, LATENCY[SEND,OPTIMISTIC] = RTT[MN,HA,CN] holds in most cases. Adding another RTT[MN,CN] propagation delay for the BU[CN] and the first data packet sent to the new care-of address yields the observed handover latency for receiving packets: LATENCY[RECEIVE,OPTIMISTIC] = Max (RTT[MN,HA], RTT[MN,HA,CN], RTT[MN,CN]) + RTT[MN,CN] which should be LATENCY[RECEIVE,OPTIMISTIC] = RTT[MN,HA,CN] + RTT[MN,CN] in most scenarios. If the mobile node is able to reuse a previously acquired Home Keygen Token due to a handover that occurred just recently, RTT[MN,HA,CN] becomes zero, and LATENCY[SEND,OPTIMISTIC] = Max (RTT[MN,HA], RTT[MN,CN]) and LATENCY[RECEIVE,OPTIMISTIC] = Max (RTT[MN,HA], RTT[MN,CN]) + RTT[MN,CN]. 6.3 Early Binding Updates This section compares the signaling delay of Mobile IPv6 optimized with Early Binding Updates to Mobile IPv6 with optimistic behavior alone. A proactive home-address test does not affect the Mobile IPv6 signaling delay because it happens while communications are actively ongoing at the mobile node's old IP attachment. A concurrent care-of-address test does not add to the signaling delay either, but the reason for this, explained next, is a bit more complicated. It is clear that the mobile node can send throughout the entire test. The correspondent node, however, becomes aware of the new care-of address only when it receives the EBU, and the EBU is transmitted during the concurrent care-of-address test. So, actually, the correspondent node sends to the new care-of address for only half of Vogt Expires August 18, 2005 [Page 19] Internet-Draft Early Binding Updates February 2005 the test. On the other hand, the EBU's propagation latency equals that of a BU[CN]'s. The one-way-time loss of the correspondent node's packets during the first half concurrent care-of-address test is therefore compensated in that the correspondent node can already send to the new care-of address during the one-way-time propagation of the BU[CN], which is not the case in standard Mobile IPv6. As a consequence, the concurrent care-of-address test can be perceived as having no effect on the Mobile IPv6 signaling delay. The mobile node sends the BU[HA], the EBU, and the CoTI back to back, and it may send route-optimized packets as of then. Outgoing packets can thus be transmitted virtually immediately, and LATENCY[SEND,EARLY] = 0 A tentative correspondent registration consists of an EBU and an optional EBA exchanged between the mobile node and the correspondent node. The correspondent node learns the new care-of address through the EBU, and it may start sending route-optimized packets to the mobile node right then. The first such packet arrives at the mobile node 0.5 RTT[MN,CN] time later. This is independent of whether or not an EBA is transmitted. Thus, the mobile node's observed signaling delay for receiving packets can be calculated as LATENCY[RECEIVE,EARLY] = RTT[MN,CN] This evaluation shows that Early Binding Updates, when compared to Mobile IPv6 with optimistic behavior, typically reduces the signaling latency by RTT[MN,HA,CN]. Compared to basic, non-optimistic Mobile IPv6, the signaling latency decreases by even RTT[MN,HA] + RTT[MN,HA,CN]: one round-trip time for the home registration and another for the return-routability procedure. The improvements are RTT[MN,CN] and RTT[MN,HA] + RTT[MN,CN], respectively, in case the mobile node has a fresh-enough Home Keygen Token from a recent home-address test which it can reuse. There may be situations in which the mobile node does not know a valid Home Keygen Token during a handover. For instance, the mobile node may not support proactive home-address tests while attached to its home link, so it cannot leverage Early Binding Updates when it leaves home. The mobile node may also be temporarily down or disconnected, hence unable to execute proactive home-address tests for a while. In cases like this, the mobile node must perform a standard binding update, and there is no efficiency improvement. Vogt Expires August 18, 2005 [Page 20] Internet-Draft Early Binding Updates February 2005 7. Security Considerations Early Binding Updates 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. This section elaborates on security implications that might originate from these differences. 7.1 Authentication According to RFC 3775, 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 execute both the home-address test and the care-of-address test before it can notify its correspondent node about a new care-of address. In contrast, the home-address test alone is sufficient to tentatively register an unverified care-of address when Early Binding Updates are used. The unverified care-of address becomes verified once the mobile node has provided proof to the correspondent node that it is indeed reachable at this address. The question is whether lack of a care-of-address test renders authentication through EBU's less secure than authentication through BU{CN}'s. At first glance, it may seem so: A BU{CN}'s authenticator depends on two tokens transmitted via separate paths, so whoever generates it must be on the intersection of both paths. Even if the paths happen to coincide are they independent in a sense, because only one of them is IPsec-protected between the mobile node and the home agent. The point, however, is that only the Home Keygen Token is bound to the mobile node's home address (which is the mobile node's identifier in the context of Mobile IPv6). The Care-of Keygen Token can be bound to any address. In particular may the attacker choose an address through which it is itself reachable. The attacker can consequently acquire both tokens once it is in a position to intercept a HoT 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 affect a BU{CN}'s authentication capability. An EBU is therefore as secure as a BU{CN} with respect to authentication. It is worthwhile emphasizing that the EBU is authenticated in just the same way as a standard BU{CN} for deregistration. 7.2 Reachability Early Binding Updates allow a mobile node to register a new care-of address without yet having shown that it is reachable at that Vogt Expires August 18, 2005 [Page 21] Internet-Draft Early Binding Updates February 2005 address. A malicious node could potentially misuse this feature for a redirection-based flooding attack against a third party. Ingress filtering [4] is usually considered a possible solution to this 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 checks only a packet's IP source address. As a consequence, ingress filtering fails when an EBU or BU{CN} has an Alternate Care-of Address option with a care-of address different than the message's source address. This makes ingress filtering incompatible with proactive correspondent registrations. Local policies at the correspondent node must hence be restrictive enough to rule out misuse of unverified care-of addresses. Section 5 discusses a number of strategies that the correspondent node may follow. It depends on the particular deployment scenario which of these strategies applies best. 8. Conclusion Mobile IPv6 uses the return-routability procedure for secure route optimization between unacquainted nodes. The procedure verifies whether a mobile node can receive packets at its claimed home and care-of addresses. As these tests are executed during the critical handover phase, their latency may have an adverse impact on delay-sensitive applications. This document proposes an optimization to Mobile IPv6, Early Binding Updates, which eliminates the handover delay caused by the return-routability procedure. Early Binding Updates move the home-address test to the time before handover, and they postpone the care-of-address test to a time when the new care-of address can already be used. The performance of this optimization is analyzed and compared to that of standard Mobile IPv6. Early Binding Updates additionally allow a mobile node to proactively register a new care-of address prior to handover. This can eliminate the entire Mobile IPv6 handover delay. Proactive registrations require assistance from the local access network for IPv6 Neighbor Discovery and Duplicate Address Detection. Vogt Expires August 18, 2005 [Page 22] Internet-Draft Early Binding Updates February 2005 Early Binding Updates are realized as an optional, and fully backward-compatible, extension to Mobile IPv6. Early Binding Updates use two new messages, both of which have no effect if either communication end-point does not support them. There is, however, a price to pay for the reduced latency. First, Early Binding Updates require transmission of one or two additional messages: an EBU and, optionally, an EBA for confirmation. Second, a mobile node must execute the home-address test periodically unless the test can be more efficiently scheduled through link-layer notifications. This generally increases the signaling overhead as well. However, the additional overhead should be worth being spent in exchange for the expected performance gain. To gather more insight in this regard, Early Binding Updates have been implemented based on the Kame-Shisa Mobile IPv6 extension for FreeBSD. The source code is available at [15]. Practical performance evaluations will supplement the analytical results shown in this document. 9. Protocol Constants Early Binding Updates use the protocol constants and variables defined in RFC 3775 [1]. This section summarizes some additional protocol constants. HOME_ADDR_TEST_INTERVAL 200 seconds TENTATIVE_RR_BINDING_LIFETIME 10 seconds 10. References 10.1 Normative References [1] Johnson, D., Perkins, C. and J. Arkko, "Mobility Support in IPv6", RFC 3775, June 2004. 10.2 Informational References [2] Institute of Electrical and Electronics Engineers, "Local and Metropolitan Area Networks: Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) Specifications", ANSI/IEEE Standard 802.11, R2003, June 2003. Vogt Expires August 18, 2005 [Page 23] Internet-Draft Early Binding Updates February 2005 [3] Institute of Electrical and Electronics Engineers, "Local and Metropolitan Area Networks: Port-Based Network Access Control", IEEE Standard 802.1X, September 2001. [4] Ferguson, P. and D. Senie, "Network Ingress Filtering: Defeating Denial of Service Attacks which employ IP Source Address Spoofing", RFC 2827, May 2000. [5] Narten, T., Nordmark, E. and W. Simpson, "Neighbor Discovery for IP Version 6 (IPv6)", RFC 2461, December 1998. [6] Thomson, S. and T. Narten, "IPv6 Stateless Address Autoconfiguration", RFC 2462, December 1998. [7] Eastlake, D., "Domain Name System Security Extensions", RFC 2535, March 1999. [8] Housley, R., Polk, W., Ford, W. and D. Solo, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 3280, April 2002. [9] Hinden, R. and S. Deering, "Internet Protocol Version 6 (IPv6) Addressing Architecture", RFC 3513, April 2003. [10] Haddad, W., Madour, L., Arkko, J. and F. Dupont, "Applying Cryptographically Generated Addresses to Optimize MIPv6 (CGA-OMIPv6)", Internet-Draft draft-haddad-mip6-cga-omipv6 (work in progress). [11] Nikander, P., Arkko, J., Aura, T., Montenegro, G. and E. Nordmark, "Mobile IP version 6 Route Optimization Security Design Background", Internet-Draft draft-ietf-mip6-ro-sec (work in progress). [12] Koodli, R., "Fast Handovers for Mobile IPv6", Internet-Draft draft-ietf-mipshop-fast-mipv6 (work in progress). [13] Vogt, C. and J. Arkko, "Credit-Based Authorization for Mobile IPv6 Early Binding Updates", Internet-Draft draft-vogt-mobopts-credit-based-authorization (work in progress). [14] Montenegro, G. and C. Castelluccia, "Crypto-Based Identifiers (CBIDs): Concepts and Applications", ACM Transactions on Information and System Security Vol. 7, No. 1, February 2004. [15] "Route Optimization Optimized", Project homepage, available Vogt Expires August 18, 2005 [Page 24] Internet-Draft Early Binding Updates February 2005 at http://www.tm.uka.de/~chvogt/ro2/. [16] "Kame-Shisa Mobile IPv6 Implementation for FreeBSD", available at http://www.mobileip.jp/. Author's Address Christian Vogt Institute of Telematics University of Karlsruhe (TH) P.O. Box 6980 76128 Karlsruhe Germany Email: chvogt@tm.uka.de URI: http://www.tm.uka.de/~chvogt/ Appendix A. Acknowledgements For their interest and valuable feedback, the author thanks the MIP6 and MOBOPTS communities, in particular Jari Arkko, Roland Bless, Mark Doll, Francis Dupont, Gregory Daley, James Kempf, Tobias Kuefner, Lars Eggert, Nick (Sharkey) Moore, Pekka Nikander, Erik Nordmark, Charles Perkins, and Kilian Weniger (listed in alphabetical order). Thanks are also due to Keiichi Shima and his colleagues from the Kame-Shisa development team. Vogt Expires August 18, 2005 [Page 25] Internet-Draft Early Binding Updates February 2005 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 (2005). 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 18, 2005 [Page 26]