Network Working Group C. Vogt, Ed. Internet-Draft R. Bless Expires: August 4, 2004 M. Doll T. Küfner Univ. of Karlsruhe, Germany February 4, 2004 Early Binding Updates for Mobile IPv6 draft-vogt-mip6-early-binding-updates-00 Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. 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 4, 2004. Copyright Notice Copyright (C) The Internet Society (2004). All Rights Reserved. Abstract The long latency associated with Mobile IPv6's home-address and care-of-address tests can significantly impact delay-sensitive applications. We propose a modified binding-update procedure that evades the latency of both address tests. The modified binding update runs in half, or less, of the time that a standard binding update takes. Moreover, the modified binding update is nearly equivalent to the standard procedure with respect to security, and it increases the resources required at the correspondent node only marginally. The modification is realized as an optional, and fully backward-compatible, extension to Mobile IPv6. Vogt, Ed., et al. Expires August 4, 2004 [Page 1] Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Standard Binding Updates . . . . . . . . . . . . . . . . . . . 6 4. Early Binding Updates . . . . . . . . . . . . . . . . . . . . 9 4.1 Protocol Specification . . . . . . . . . . . . . . . . . . . . 10 4.2 Concurrent Care-of Address Tests . . . . . . . . . . . . . . . 14 4.3 Initial Care-of Address Registration . . . . . . . . . . . . . 15 5. Efficiency Considerations . . . . . . . . . . . . . . . . . . 16 5.1 Standard Binding Updates . . . . . . . . . . . . . . . . . . . 16 5.2 Early Binding Updates . . . . . . . . . . . . . . . . . . . . 18 6. Security Considerations . . . . . . . . . . . . . . . . . . . 20 6.1 Decoupled Address Tests . . . . . . . . . . . . . . . . . . . 21 6.2 Concurrent Care-of Address Tests . . . . . . . . . . . . . . . 23 7. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 24 8. Protocol Configuration Variables . . . . . . . . . . . . . . . 24 References . . . . . . . . . . . . . . . . . . . . . . . . . . 24 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 25 Intellectual Property and Copyright Statements . . . . . . . . 27 Vogt, Ed., et al. Expires August 4, 2004 [Page 2] Internet-Draft Early Binding Updates February 2004 1. Introduction Mobility Support for IPv6 [1], or Mobile IPv6, allows a mobile node to change its point of network attachment without loosing higher-level communications connections. A mobile node has a preferably permanent "home address", by means of which the mobile node can be identified. In addition, the mobile node has a "care-of address", which is a topologically correct IP address at the mobile node's current location. The care-of address changes whenever the mobile node moves to a different location. If a mobile node and a correspondent node use route optimization, the correspondent node maintains a "binding" between the mobile node's home address and current care-of address. When the mobile node attaches to a different network, it initiates a "binding update", i.e., it signals to the correspondent node its new care-of address. We assume the application of route optimization in this document. Mobile IPv6 uses a "return routability" procedure to verify a binding update with respect to authenticity and validity. The return routability encompasses two tests: A home-address test authenticates the mobile node. It provides reasonable assurance to the correspondent node that the mobile node is the legitimate owner of the IP address which the mobile node claims to own as its home address. A care-of-address test checks the validity of the new care-of address. It provides reasonable assurance to the correspondent node that the mobile node is reachable through the IP address which the mobile node wishes to register as its care-of address. The return routability requires a minimum of processing resources and state at both the mobile node and the correspondent node. Furthermore, it does not depend on a trusted infrastructure, which would be expensive to build and maintain. A shortfall, however, is that the two address tests, though typically performed in parallel, constitute a considerable fraction of the binding-update latency. Both tests are potentially run over very long distances. This makes it difficult for delay-sensitive applications to hold up service quality when the mobile node changes its point of network attachment. In this document, we propose a strategy, Early Binding Updates, to move both address tests out of the critical period during which a new care-of address cannot yet be used. We find that an Early Binding Update runs in half, or less, of the time that a binding update defined in [1] takes. Moreover, we show that an Early Binding Update is nearly equivalent to the standard procedure with respect to security, and that it increases the resources required at the correspondent node only marginally. To facilitate differentiation, we will henceforth call the binding update defined in [1] a "standard Vogt, Ed., et al. Expires August 4, 2004 [Page 3] Internet-Draft Early Binding Updates February 2004 binding update". Early Binding Updates are a minor extension to standard binding updates. They are fully compatible to the binding-update procedure defined in [1], in particular with the return routability. Early Binding Updates use two new messages, both of which have no effect if either communication end-point does not support them. All messages related to standard binding updates remain unchanged and retain their original meaning. We are currently working on a more detailed specification of Early Binding Updates including message formats and additions to [1]. The specification will be published in a future version of this Internet Draft. Section 2 provides a brief overview on Early Binding Updates. The overview is assumed to be sufficient for a hurried reader who does not want to read the in-depth discussion of the subsequent sections. Section 3 is a recap on the standard binding-update procedure defined in [1]. Section 4 provides the details of Early Binding Updates. We analyze the efficiency of Early Binding Updates in Section 5. Implications on security are examined in Section 6. We conclude in Section 7. 2. Overview In this section, we briefly describe Early Binding Updates. This section is assumed to be a sufficient survey for a hurried reader. We refer to Section 4 for more details on Early Binding Updates. Section 3 provides a recap on standard binding updates. Early Binding Updates are a strategy to move both address test out of the critical period during which a new care-of address cannot yet be used. With Early Binding Updates, a mobile node executes a home-address test whenever a handover is imminent. If handovers cannot be anticipated, the mobile node may periodically repeat the home-address test. Either way, the mobile node has at hand a fresh Home Keygen Token when it changes its point of network attachment, and it does not need to wait for a lengthy home-address test during the binding update. Furthermore, the care-of-address test is executed in parallel with sending data to and from the new care-of address. This way, the mobile node does not need to wait for a lengthy care-of-address test during the binding update either. Note that [1] suggests running both address tests after a handover. However, the mobile node may trigger a home-address test before it moves without violating the protocol procedure. We introduce two new messages: an Early Binding Update message and an Vogt, Ed., et al. Expires August 4, 2004 [Page 4] Internet-Draft Early Binding Updates February 2004 Early Binding Acknowledgement message. 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 to the correspondent node an Early Binding Update message in order to tentatively register the new care-of address with the correspondent node. The mobile node just needs a Home Keygen Token to authenticate the Early Binding Update message. The mobile node may request the correspondent node to return an Early Binding Acknowledgement message by raising a flag in the Early Binding Update message. A conservative mobile node would wait for the Early Binding Acknowledgement message before using its new care-of address. An optimistic mobile node would start using its new care-of address as soon as having dispatched the Early Binding Update message. Whether conservative or optimistic, with Early Binding Updates, the mobile node can use its new care-of address about one round-trip time sooner than with standard binding updates. Having sent the Early Binding Update message, the mobile node initiates a care-of-address test as defined in [1]. When the care-of-address test completes, the mobile node sends to the correspondent node a standard Binding Update message as defined in [1]. The Binding Update message is to have the correspondent node change the status of the care-of-address registration from tentative to regular. When the correspondent node receives the Early Binding Update message from the mobile node, it creates a tentative binding-cache entry with the mobile node's new care-of address. The correspondent node uses the mobile node's new care-of address as soon as the binding-cache entry is in place. Thus, with Early Binding Updates, the correspondent node can use the mobile node's new care-of address about one round-trip time sooner than with standard binding updates. A tentative binding-cache entry's lifetime is limited to a few seconds, within which the correspondent node expects the mobile node to run a successful care-of-address test. When the correspondent node receives the Binding Update message, it extends the lifetime of the mobile node's tentative binding-cache entry to the regular lifetime proposed in [1]. The tentative binding-cache entry will be deleted, if the Binding Update message fails to be delivered to the correspondent node during the binding-cache entry's lifetime - which clearly is the case if the mobile node fails to run a successful care-of-address test. Further data packets will then be sent via the mobile node's home agent. Early Binding Updates are a fully backward-compatible extension to the binding-update procedure defined in [1]. All messages related to standard binding updates remain unchanged and retain their original meaning. Moreover, a mobile node may initiate an Early Binding Update without knowing whether or not this optimization is supported by the Vogt, Ed., et al. Expires August 4, 2004 [Page 5] Internet-Draft Early Binding Updates February 2004 correspondent node. If the correspondent node does not support Early Binding Updates, the mobile node's Early Binding Update message has no effect, and the binding-update procedure is automatically reduced to the standard procedure. 3. Standard Binding Updates This section is a recap on the standard binding-update procedure, which allows a mobile node to register its care-of address with a correspondent node. The procedure is depicted in Figure 1. The complete definition can be found in [1]. Mobile Node Home Agent Correspondent Node ~~~~~ [Handover] Binding Update (1) |-------------------->| Home Test Init (2) |-------------------->|-------------------->| Care-of Test Init (3) |------------------------------------------>| Binding Acknowledgement (4) |<--------------------| Home Test (5) |<--------------------|<--------------------| Care-of Test (6) |<------------------------------------------| Binding Update (7) |------------------------------------------>| Binding Acknowledgement (8) |<------------------------------------------| Figure 1: Standard Binding Update When the mobile node detects that it has moved to a different network, it configures a new care-of address. The mobile node then Vogt, Ed., et al. Expires August 4, 2004 [Page 6] Internet-Draft Early Binding Updates February 2004 sends to its home agent a Binding Update message (1). The Binding Update message informs the home agent about the mobile node's new care-of address. It is authenticated by means of an IPsec security association between the mobile node and the home agent. After this, the mobile node sends to the correspondent node two messages in parallel: a Home Test Init message and a Care-of Test Init message. The Home Test Init message (2) is tunneled to the mobile node's home agent, and forwarded on to the correspondent node. The Home Test Init message includes a random Home Init Cookie. The Home Init Cookie will be returned by the correspondent node in the Home Test message. Both the Home Test Init message and the Home Test message are protected by IPsec on the path between the mobile node and the mobile node's home agent. They are unprotected on the path between the mobile node's home agent and the correspondent node. On the latter path, a malicious node may potentially eavesdrop on the Home Init Cookie and return it in a spoofed Home Test message. For this reason, having to return the cookie restricts the sender of the Home Test message to the path between the mobile node's home agent and the correspondent node. The mobile node considers this a sufficient proof that the Home Test message was generated by the correspondent node itself. The Care-of Test Init message (3) does not go through the mobile node's home agent. It takes the direct path to the correspondent node. The Care-of Test Init message includes a random Care-of Init Cookie. The Care-of Init Cookie will be returned by the correspondent node in the Care-of Test message. Both the Care-of Test Init and the Care-of Test messages are not protected by IPsec. A malicious node may potentially eavesdrop on the Care-of Init Cookie and return it in a spoofed Care-of Test message. For this reason, having to return the cookie restricts the sender of the Care-of Test message to the path between the mobile node and the correspondent node. The mobile node considers this a sufficient proof that the Care-of Test message was generated by the correspondent node itself. When the home agent receives the Binding Update message, it registers the mobile node's new care-of address. If the home agent maintains an IPsec tunnel to the mobile node, it also updates the corresponding security association to the new care-of address [2]. The home agent sends back to the mobile node a Binding Acknowledgement message (4) to indicate successful care-of-address registration. The Binding Acknowledgement message is authenticated by means of an IPsec security association between the mobile node and the home agent. When the correspondent node receives the Home Test Init message, it sends back to the mobile node a Home Test message (5). The Home Test message is directed to the mobile node's home address, hence passes Vogt, Ed., et al. Expires August 4, 2004 [Page 7] Internet-Draft Early Binding Updates February 2004 the mobile node's home agent. The Home Test message contains a Home Keygen Token, a Home Nonce Index, and the Home Init Cookie copied from the Home Test Init message. The Home Keygen Token will be used by the mobile node when producing the Binding Management Key, as described below. The Home Nonce Index identifies a random value based on which the correspondent node has computed the Home Keygen Token. The mobile node will include the Home Nonce Index in the subsequent Binding Update message to allow the correspondent node to reproduce the Home Keygen Token. Likewise, upon receiving the Care-of Test Init message, the correspondent node sends back to the mobile node a Care-of Test message (6). The Care-of Test message is directed to the mobile node's new care-of address, hence does not pass the mobile node's home agent. The Care-of Test message contains a Care-of Keygen Token, a Care-of Nonce Index, and the Care-of Init Cookie copied from the Care-of Test Init message. The Care-of Keygen Token will be used by the mobile node when producing the Binding Management Key, as described below. The Care-of Nonce Index identifies a random value based on which the correspondent node has computed the Care-of Keygen Token. The mobile node will include the Care-of Nonce Index in the subsequent Binding Update message to allow the correspondent node to reproduce the Care-of Keygen Token. The mobile node uses the Home Keygen Token and the Care-of Keygen Token to produce a secret key, the Binding Management Key, shared with the correspondent node. The Binding Management Key is a one-way hash on the concatenation of the Home Keygen Token and the Care-of Keygen Token. The mobile node then generates a Binding Update message (7) to be sent to the correspondent node. The Binding Update message contains a message-authentication code produced with the Binding Management Key. It also contains the Home Nonce Index and the Care-of Nonce Index. The mobile node may request the correspondent node to return a Binding Acknowledgement message by raising the A-flag in the Binding Update message. A conservative mobile node would wait for the Binding Acknowledgement message before using its new care-of address. An optimistic mobile node would start using its new care-of address as soon as having dispatched the Binding Update message. When the correspondent node receives the Binding Update message, it can reproduce the Home Keygen Token and the Care-of Keygen Token with the help of the two nonce indices. The tokens, in turn, allow the correspondent node to reproduce the Binding Management Key. The correspondent node can then compute what the message-authentication code in the Binding Update message should look like. If the result matches the message-authentication code in the Binding Update Vogt, Ed., et al. Expires August 4, 2004 [Page 8] Internet-Draft Early Binding Updates February 2004 message, the correspondent node can assume two things. First, the mobile node must have received the Home Keygen Token in order to construct the Binding Management Key with which the message-authentication code was produced. Therefore, the mobile node is the legitimate owner of the home address with high probability, since the Home Keygen Token was sent, as part of the Home Test message, to the mobile node's home address. Second, the mobile node must have received the Care-of Keygen Token in order to construct the Binding Management Key. Hence, the mobile node is apparently reachable through the new care-of address, since the Care-of Keygen Token was sent, as part of the Care-of Test message, to the mobile node's care-of address. Beyond this, the message-authentication code validates the Binding Update message's integrity. Provided that the message-authentication code coming along with the Binding Update message is correct, the correspondent node creates a binding-cache entry with the mobile node's new care-of address. The correspondent node uses the mobile node's new care-of address as soon as the binding-cache entry is in place. In case the A-flag in the Binding Update message is set, the correspondent node sends back to the mobile node a Binding Acknowledgement message (8) to indicate successful care-of-address registration. 4. Early Binding Updates In this section, we specify the procedure of Early Binding Updates, our proposed modification of the standard binding-update procedure. Early Binding Updates evade the latency of the two address tests associated with a standard binding update. For this, the two address tests are temporally decoupled. A mobile node executes a home-address test whenever a handover is imminent. If handovers cannot be anticipated, the mobile node may periodically repeat the home-address test. Either way, the mobile node has at hand a fresh Home Keygen Token when it changes its point of network attachment, and it does not need to wait for a lengthy home-address test during the binding update. The care-of-address test is performed after having signaled the new care-of address to the correspondent node, and in parallel with sending data to and from the new care-of address. [1] suggests running both tests in parallel and after a handover. However, the mobile node may trigger a home-address test before it moves without violating the protocol procedure. We introduce two new messages: an Early Binding Update message and an Early Binding Acknowledgement message. The mobile node sends to the correspondent node an Early Binding Update message when it wants to Vogt, Ed., et al. Expires August 4, 2004 [Page 9] Internet-Draft Early Binding Updates February 2004 register a new care-of address without yet having accomplished a care-of-address test. The mobile node may request the correspondent node to return an Early Binding Acknowledgement message. All messages of the standard binding-update procedure remain unchanged and retain their original meaning. Hence, a mobile node may initiate an Early Binding Update without knowledge of whether or not the correspondent node supports this. In case the correspondent node does not support Early Binding Updates, the binding update is automatically reduced to the standard procedure. We provide a detailed specification of Early Binding Updates in Section 4.1. We elaborate on the concurrent care-of-address test in Section 4.2. In Section 4.3, we discuss the special case of registering a care-of address without having done a home-address test in advance. 4.1 Protocol Specification This section provides a detailed specification of Early Binding Updates. The procedure is summarized in Figure 2. A mobile node triggers a home-address test, steps (1) and (2) in Figure 2, whenever a handover is imminent. If handovers cannot be anticipated, the mobile node may periodically repeat the home-address test. Either way, the mobile node has at hand a fresh Home Keygen Token when it changes its point of network attachment. The Home Test Init and Home Test messages used for an Early Binding Update are the same as the ones used for a standard binding update. The time after which the mobile node repeats the home-address test should be conservatively determined as the minimum time, MAX_TOKEN_LIFETIME [1], a token is expected to be valid. Alternatively, one might consider adding a Lifetime option to the Home Test message to explicitly indicate the time after which the Home Keygen Token becomes expired. The Lifetime option could help the mobile node determine when to initiate the next home-address test. The introduction of a new option would not interfere with Mobile IPv6 implementations that do not support Early Binding Updates. The new option would simply be ignored and skipped by a node that does not recognize the option. See section 6.1.5 of [1] for details on this. The Home Test Init and Home Test messages are typically protected by an IPsec tunnel between the home agent and the mobile node [2]. The home agent must update the corresponding security association to the mobile node's new care-of address when the mobile node changes its point of network attachment. With Early Binding Updates, the care-of-address change does not affect a home-address test, because Vogt, Ed., et al. Expires August 4, 2004 [Page 10] Internet-Draft Early Binding Updates February 2004 the home-address test is performed before the mobile node moves. This is a difference to a standard binding update, where a home agent must update the security association when it receives a Binding Update message from the mobile node. Otherwise, the Home Test message could not be delivered back to the mobile node through the IPsec tunnel [2]. Mobile Node Home Agent Correspondent Node Home Test Init (1) |-------------------->|-------------------->| Home Test (2) |<--------------------|<--------------------| ~~~~~ [Handover] Binding Update (3) |-------------------->| Early Binding Update (4) |------------------------------------------>| Care-of Test Init (5) |------------------------------------------>| Binding Acknowledgement (6) |<--------------------| Early Binding Acknowledgement (7) |<------------------------------------------| Care-of Test (8) |<------------------------------------------| Binding Update (9) |------------------------------------------>| Binding Acknowledgement (10) |<------------------------------------------| Figure 2: Early Binding Update 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 to its home agent a Binding Update message (3). The Binding Vogt, Ed., et al. Expires August 4, 2004 [Page 11] Internet-Draft Early Binding Updates February 2004 Update message informs the home agent about the mobile node's new care-of address. It is authenticated by means of an IPsec security association between the mobile node and the home agent. Having sent the Binding Update message to its home agent, the mobile node produces an Early Binding Management Key, which is a one-way hash on the Home Keygen Token from the most recently received Home Test message. The mobile node then generates an Early Binding Update message (4) to be sent to the correspondent node and to be authenticated with the Early Binding Management Key. The Early Binding Management Key does not incorporate a Care-of Keygen Token as the Binding Management Key used for a standard binding update does. However, since the Care-of Keygen Token is irrelevant for "authentication" purposes, but proves that some node can be reached given its care-of address, it stands to reason that the Early Binding Management Key is sufficient for authenticating the Early Binding Update message. The mobile node will provide proof of its reachability at the new care-of address at a later stage, when it sends to the correspondent node a standard Binding Update message. The mobile node will then need to generate an additional, standard Binding Management Key on the basis of both the Home Keygen Token and the Care-of Keygen Token. Note that [1] uses a key equivalent to the Early Binding Management Key when deleting an existing binding-cache entry. See section 5.2.5 of [1] for details on this. The Early Binding Update message contains a message-authentication code and the Home Nonce Index copied from the most recently received Home Test message. There are two differences between the Early Binding Update message and the Binding Update message used during a standard binding update. First, the message-authentication code in the Early Binding Update message is produced with the Early Binding Management Key, which does not incorporate a Care-of Keygen Token. Second, the Early Binding Update message does not contain a Care-of Nonce Index. Note that [1] uses a message similar to the Early Binding Update message when deleting an existing binding-cache entry. See sections 6.1.7 and 6.2.6 of [1] for details on this. The mobile node may request the correspondent node to return an Early Binding Acknowledgement message by raising the A-flag in the Early Binding Update message. A conservative mobile node would wait for the Early Binding Acknowledgement message before using its new care-of address. An optimistic mobile node would start using its new care-of address as soon as having dispatched the Early Binding Update message. Assuming that no packet reordering occurs on the path between the mobile node and the correspondent node, the Early Binding Update message will come in at the correspondent node ahead of all data packets which the mobile node has sent from its new care-of address. Whether conservative or optimistic, with Early Binding Updates, the mobile node can use its new care-of address about one round-trip time Vogt, Ed., et al. Expires August 4, 2004 [Page 12] Internet-Draft Early Binding Updates February 2004 sooner than with standard binding updates. See Section 5 for an efficiency analysis. The mobile node sends to the correspondent node a Care-of Test Init message (5) in parallel with sending the Early Binding Update message. The Care-of Test Init message used for an Early Binding Update is the same as the one used for a standard binding update. When the home agent receives the Binding Update message, it registers the mobile node's new care-of address. If the home agent maintains an IPsec tunnel to the mobile node, it also updates the corresponding security association to the new care-of address [2]. The home agent sends back to the mobile node a Binding Acknowledgement message (6) to indicate successful care-of-address registration. The Binding Acknowledgement message is authenticated by means of an IPsec security association between the mobile node and the home agent. When the correspondent node receives the Early Binding Update message, it can reproduce the Home Keygen Token with the help of the Home Nonce Index. The token, in turn, allows the correspondent node to reproduce the Early Binding Management Key. The correspondent node can then compute what the message-authentication code in the Early Binding Update message should look like. If the result matches the message-authentication code in the Early Binding Update message, the mobile node must have received the Home Keygen Token in order to construct the Early Binding Management Key with which the message-authentication code was produced. Therefore, the correspondent node can assume that the mobile node is the legitimate owner of the home address, since the Home Keygen Token was sent, as part of the Home Test message, to the mobile node's home address. Beyond this, the message-authentication code validates the Early Binding Update message's integrity. Provided that the message-authentication code coming along with the Early Binding Update message is correct, the correspondent node creates a tentative binding-cache entry with the mobile node's new care-of address. The correspondent node uses the mobile node's new care-of address as soon as the binding-cache entry is in place. Thus, with Early Binding Updates, the correspondent node can use the mobile node's new care-of address about one round-trip time sooner than with standard binding updates. See Section 5 for an efficiency analysis. Since a care-of-address test still has to be performed for the mobile node's new care-of address, the lifetime of the new binding-cache entry is limited to TENTATIVE_BINDING_LIFETIME. The lifetime will be extended when the correspondent node receives a standard Binding Update message from the mobile node. See Section 4.2 for details on the concurrent care-of-address test. In case the A-flag in the Early Vogt, Ed., et al. Expires August 4, 2004 [Page 13] Internet-Draft Early Binding Updates February 2004 Binding Update message is set, the correspondent node sends back to the mobile node an Early Binding Acknowledgement message (7) to indicate tentative care-of-address registration. When the correspondent node receives the Care-of Test Init message, it sends to the mobile node a Care-of Test message (8). The Care-of Test message used for an Early Binding Update is the same as the one used for a standard binding update. The Care-of Test message delivers to the mobile node a Care-of Keygen Token. The mobile node uses this Care-of Keygen Token together with the Home Keygen Token from the most recently received Home Test message to produce a standard Binding Management Key. This Binding Management Key is a one-way hash on the concatenation of the Home Keygen Token and the Care-of Keygen Token. It is equivalent to the Binding Management Key used for a standard binding update. The mobile node then generates a standard Binding Update message (9) to be sent to the correspondent node. This Binding Update message contains a message-authentication code produced with the Binding Management Key. It is equivalent to the Binding Update message used for a standard binding update. The mobile node may request the correspondent node to return a Binding Acknowledgement message by raising the A-flag in the Binding Update message. When the correspondent node receives the Binding Update message, it checks the message's authenticity as described in Section 3. Provided that the Binding Update message is properly authenticated, the correspondent node extends the lifetime of the mobile node's tentative binding-cache entry to the regular lifetime proposed in [1]. In case the A-flag in the Binding Update message is set, the correspondent node sends back to the mobile node a standard Binding Acknowledgement message (10) to indicate successful care-of-address registration. This Binding Acknowledgement message is equivalent to the one used for a standard binding update. 4.2 Concurrent Care-of Address Tests In this section, we elaborate on the concurrent care-of-address test. A concurrent care-of-address test is performed after a mobile node has signaled to the correspondent node a new care-of address. It runs in parallel with sending data to and from the new care-of address. The concurrent care-of-address test facilitates data transfer while testing a mobile node's reachability. It requires the correspondent node to create a tentative binding-cache entry with the mobile node's new care-of address before a care-of-address test has been accomplished. Vogt, Ed., et al. Expires August 4, 2004 [Page 14] Internet-Draft Early Binding Updates February 2004 Data transfer to and from a yet-unverified care-of address is limited to a tentative binding-cache entry's lifetime, TENTATIVE_BINDING_LIFETIME. On one hand, this lifetime is thought to be long enough to outlast the care-of-address test to be performed during that time. On the other hand, the lifetime is thought to be short enough to discourage the exploitation of concurrent care-of-address tests for flooding attacks. When the correspondent node receives a properly authenticated Binding Update message from the mobile node, it extends the lifetime of the tentative binding-cache entry to the regular lifetime proposed in [1]. If the Binding Update message arrives before the binding-cache entry expires, data transfer can continue without disruption. If the Binding Update message fails to arrive before the binding-cache entry expires, the correspondent node must stop sending further data packets to the mobile node's new care-of address. Subsequent data packets will then be sent to the mobile node's home address. See Section 6.2 for a discussion on why this is a feasible modus operandi. 4.3 Initial Care-of Address Registration In Section 4.1, a mobile node is expected to have acquired a valid Home Keygen Token prior to changing its point of network attachment. There are scenarios, however, in which this is not a feasible assumption. For example, the mobile may be connected to its home link before changing its point of network attachment. At home, the mobile node does not use Mobile IPv6. It hence does not run a home-address test, and it does not acquire a Home Keygen Token, before it moves to a foreign link. Also, when the mobile node powers on at a foreign link, it does not have a valid Home Keygen Token either. The mobile node may even be offline for a while and unable to run the home-address test. Any previously obtained Home Keygen Token is likely to be expired when the mobile node reconnects to a foreign link. One may consider letting the mobile node perform a home-address test even while being at home. This could accelerate handovers from the home link to a foreign link. The Home Test Init and Home Test messages would continue to obey to the rules defined in sections 9.4 and 11.6 of [1], except that they would not have to be tunneled between the mobile node and its home agent. Nonetheless, performing a home-address test from the home network does not help when a mobile node reconnects to a foreign network after an offline period or after booting up. Obviously, the mobile node must have a chance to register a care-of address with its correspondent node without having acquired a Home Keygen Token beforehand. Vogt, Ed., et al. Expires August 4, 2004 [Page 15] Internet-Draft Early Binding Updates February 2004 These observations lead to the following exception: When a mobile node wants to register a new care-of address with a correspondent node, and the mobile node does not yet know a valid Home Keygen Token, the mobile node runs a standard binding update instead of an Early Binding Update. When the standard binding update is complete, the mobile node can communicate through its new care-of address. The mobile node will henceforth trigger a home-address test whenever a handover is imminent. If handovers cannot be anticipated, the mobile node may periodically repeat the home-address test. Either way, the mobile node will have available a fresh Home Keygen Token when it changes its point of network attachment the next time so as to apply an Early Binding Update then. 5. Efficiency Considerations In this section, we consider the impact on efficiency that a binding update may have. We examine standard binding updates in Section 5.1, and we analyze Early Binding Updates in Section 5.2. 5.1 Standard Binding Updates When the mobile node detects that it has moved to a different network, it configures a new care-of address. [1] 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, the home-address test and, third, the care-of-address test must be executed. Fourth, the mobile node must register the new care-of address with its correspondent node. Registering the new care-of address with the home agent is a two-way message exchange between the mobile node and the mobile node's home agent. It consists of a Binding Update message and a Binding Acknowledgement message. Let RTT_HA be the round-trip time for the Binding Update and Binding Acknowledgement messages. Here, HA means "home agent". The home-address test is a two-way message exchange between the mobile node and the correspondent node. It consists of a Home Test Init message and a Home Test message, both of which are tunneled between the mobile node and the mobile node's home agent. Let the round-trip time for the Home Test Init and Home Test messages be RTT_BT. Here, BT means "bidirectional tunneling". The care-of-address test is a two-way message exchange between the Vogt, Ed., et al. Expires August 4, 2004 [Page 16] Internet-Draft Early Binding Updates February 2004 mobile node and the correspondent node. It consists of a Care-of Test Init message and a Care-of Test message, both of which are relayed on the direct path between the mobile node and the correspondent node. They do not pass the mobile node's home agent. Let the round-trip time for the Care-of Test Init and Care-of Test messages be RTT_RO. Here, RO means "route optimization". The mobile node may dispatch the Home Test Init and Care-of Test Init messages at any time after having sent the Binding Update message to the home agent. The mobile node may thus send out all three messages virtually in parallel. It takes approximately RTT_HA time until the mobile node receives the Binding Acknowledgement message from its home agent. The time until the mobile node receives the Home Test message from the correspondent node is approximately RTT_BT. Finally, it takes approximately RTT_RO time until the Care-of Test message arrives at the mobile node. The mobile node must wait for all three messages before it can register its new care-of address with the correspondent node. Registering the new care-of address with the correspondent node is a one-way or two-way message exchange between the mobile node and the correspondent node. It consists of a Binding Update message and an optional Binding Acknowledgement message. The mobile node may request the correspondent node to return a Binding Acknowledgement message by raising a flag in the Binding Update message. A conservative mobile node would wait for the Binding Acknowledgement message before using its new care-of address. An optimistic mobile node would start using its new care-of address as soon as having dispatched the Binding Update message. All things considered, a standard binding update's total latency with respect to sending data from a new care-of address can be approximated by STD_LATENCY_SEND_CONSERV = Max (RTT_HA, RTT_BT, RTT_RO) + RTT_RO STD_LATENCY_SEND_OPTIMST = Max (RTT_HA, RTT_BT, RTT_RO) Here, STD_LATENCY_SEND_CONSERV pertains to a conservative mobile node, which waits for the returning Binding Acknowledgement message before it uses its new care-of address. STD_LATENCY_SEND_OPTIMST pertains to an optimistic mobile node, which uses its new care-of address as soon as having dispatched the Binding Update message. Whether or not the mobile node waits for the returning Binding Acknowledgement message, the correspondent node starts using the mobile node's new care-of address upon receiving the mobile node's Binding Update message. When the correspondent node switches to the new care-of address, it takes another 0.5 RTT_RO time until the first Vogt, Ed., et al. Expires August 4, 2004 [Page 17] Internet-Draft Early Binding Updates February 2004 data packets arrive at the mobile node's new care-of address. Thus, a standard binding update's total latency with respect to receiving data at a new care-of address can be approximated by STD_LATENCY_RECV = Max (RTT_HA, RTT_BT, RTT_RO) + RTT_RO 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_BT reduces to zero, and Max (RTT_HA, RTT_BT, RTT_RO) = Max (RTT_HA, RTT_RO). 5.2 Early Binding Updates Moving from one point of network attachment to another involves a handover and a binding update. During the handover, the mobile node attaches to a new access point, re-authenticates itself, discovers a new default router, and configures a new care-of address. During the binding update, the mobile node signals to its correspondent node and its home agent the new care-of address. More specifically, the mobile node runs a home-address test and a care-of-address test, and it sends a Binding Update message to both its correspondent node and its home agent. One might consider three candidate periods during which to execute the home-address test and the care-of address test. These candidate periods are as follows. (1) Before handover (2) After handover, but before binding update (3) After binding update The home-address test is intended to authenticate a node's home address. For this reason, the home-address test must be performed at either (1) or (2), but cannot be performed at (3). In [1], the home-address test is preferably done at (2), but it may also take place at (1). Technically, there is nothing that prevents a mobile node from initiating the home-address test at (1). The mobile node just needs to make sure that the Home Keygen Token from the home-address test is still valid at the time the binding update is done. The care-of-address test is intended to prove that the mobile node is reachable at its new care-of address. Therefore, the care-of-address test obviously cannot be done at (1). In [1], the care-of-address test is done at (2), i.e., it runs in parallel with the home-address test. We claim that testing the mobile node's reachability at its new Vogt, Ed., et al. Expires August 4, 2004 [Page 18] Internet-Draft Early Binding Updates February 2004 care-of address may also be done at (3). Data transmission to and from the new care-of address may wait or, as with Early Binding Updates, start with appropriate restrictions until the mobile node has provided proof to the correspondent node that it is reachable at its new care-of address. With Early Binding Updates, the home-address test is moved to (1), and the care-of-address test is moved to (3). The home-address test does no longer delay the binding update, because it runs while the mobile node still uses a functioning, fully registered care-of address. The care-of-address test does no longer delay the binding update either, because it runs while the mobile node uses a new, tentatively registered care-of address. There are two things that remain to be done after a handover: First, the mobile node must register the new care-of address with its home agent. Second, the mobile node must tentatively register the new care-of address with the correspondent node. Registering the new care-of address with the home agent is a two-way message exchange between the mobile node and the mobile node's home agent. It consists of a Binding Update message and a Binding Acknowledgement message. Let RTT_HA be the round-trip time for the Binding Update and Binding Acknowledgement messages. Here, HA means "home agent". Tentatively registering the new care-of address with the correspondent node is a one-way or two-way message exchange between the mobile node and the correspondent node. It consists of an Early Binding Update message and an optional Early Binding Acknowledgement message. The mobile node may request the correspondent node to return an Early Binding Acknowledgement message by raising a flag in the Early Binding Update message. Let the round-trip time for the Early Binding Update and Early Binding Acknowledgement messages be RTT_RO. Here, RO means "route optimization". A conservative mobile node would wait for both the Binding Acknowledgement message from its home agent and the Early Binding Acknowledgement from its correspondent node before using its new care-of address. An optimistic mobile node would start using its new care-of address as soon as having dispatched the Binding Update and Early Binding Update messages. All things considered, an Early Binding Update's total latency with respect to sending data from a new care-of address can be approximated by NEW_LATENCY_SEND_CONSERV = Max (RTT_HA, RTT_RO) Vogt, Ed., et al. Expires August 4, 2004 [Page 19] Internet-Draft Early Binding Updates February 2004 NEW_LATENCY_SEND_OPTIMST = 0 Here, NEW_LATENCY_SEND_CONSERV pertains to a conservative mobile node, which waits for both the Binding Acknowledgement message returning from its home agent and the Early Binding Acknowledgement returning from its correspondent node before it uses its new care-of address. NEW_LATENCY_SEND_OPTIMST pertains to an optimistic mobile node, which uses its new care-of address as soon as having dispatched the Binding Update and Early Binding Update messages. Whether or not the mobile node waits for the returning Binding Acknowledgement and Early Binding Acknowledgement messages, the correspondent node starts using the mobile node's new care-of address upon receiving the mobile node's Early Binding Update message. When the correspondent node switches to the new care-of address, it takes another 0.5 RTT_RO time until the first data packets arrive at the mobile node's new care-of address. Thus, an Early Binding Update's total latency with respect to receiving data can be approximated by NEW_LATENCY_RECV = RTT_RO This evaluation shows that an Early Binding Update is about a round-trip time faster than a standard binding update. This is true even if the mobile node is able to reuse a previously acquired Home Keygen Token without running another home-address test. The new responsiveness to mobility will be of true benefit for delay-sensitive applications. Section 4.3 discusses the initial care-of-address registration, during which the mobile node does not yet know a valid Home Keygen Token. In this situation, the mobile node must perform a standard binding update, and there is no efficiency improvement. However, we point out that having to resort to a standard binding update is limited to only very few scenarios and will rather be an exception. 6. Security Considerations In this section, we elaborate on security implications that come along with using Early Binding Updates instead of standard binding updates. There are two conceptual differences between an Early Binding Update and a standard binding update. First, with the Early Binding Update, the home-address test is decoupled from the care-of-address test, and the Early Binding Management Key used to authenticate an Early Binding Update message is produced with the Home Keygen Token only. In contrast, the Binding Management Key used for a standard binding update is produced with both the Home Keygen Vogt, Ed., et al. Expires August 4, 2004 [Page 20] Internet-Draft Early Binding Updates February 2004 Token and the Care-of Keygen Token. We discuss this matter in Section 6.1. Second, we propose to execute the care-of-address test in parallel with sending data to and from the new care-of address. A malicious - yet properly authenticated - node can so wage a flooding attack for a limited time. We analyze this issue in Section 6.2. We also propose precautions against a flooding attack. For a comprehensive taxonomy of mobility-related attacks, we refer to the Mobile IPv6 Route Optimization Security Design Background [3]. The document provides a thorough understanding of what has guided the design of the standard binding-update procedure. 6.1 Decoupled Address Tests During a standard binding update, a mobile node must accomplish both the home-address test and the care-of-address test before it can signal to its correspondent node a new care-of address. During an Early Binding Update, the home-address test is sufficient to let the correspondent node tentatively register a new care-of address. The tentative registration becomes a regular one once the mobile node has provided proof to the correspondent node that it is reachable at its new care-of address. Temporally decoupling the home-address test from the care-of-address test means separating an authenticity check from a validity check. The authenticity check indicates that the mobile node is the legitimate owner of the IP address which the mobile node claims to own as its home address. The validity check indicates that the mobile node is reachable through the IP address which the mobile node wishes to register as its care-of address. The consequence is this: During the standard binding update, when a mobile node's Binding Update message arrives at a correspondent node, the correspondent node knows that the message is authentic and that the mobile node is reachable through its new care-of address. During the Early Binding Update, when a mobile node's Early Binding Update message arrives at a correspondent node, the correspondent node can trust in the message's authenticity, but it must wait until completion of the care-of-address test before it can assume that the mobile node is reachable through its new care-of address. The maximum time of uncertainty can be configured by the TENTATIVE_BINDING_LIFETIME protocol-configuration variable. The question is whether separating the two address tests makes authentication of binding updates less secure or not. Recall that an Early Binding Update message requires only a Home Keygen Token to be authenticated, whereas a Binding Update message requires both a Home Vogt, Ed., et al. Expires August 4, 2004 [Page 21] Internet-Draft Early Binding Updates February 2004 Keygen Token and a Care-of Keygen Token. The Home Keygen Token and the Care-of Keygen Token are likely to arrive at the mobile node via disjoint paths: The former passes through the mobile node's home agent, the latter does not. An attacker will thus have a hard time to capture both tokens. One might wonder whether the simpler authentication of an Early Binding Update message makes Early Binding Updates open to eavesdropping and man-in-the-middle attacks. Next, we argue that this is not the case. Consider an attacker who intends to exploit Early Binding Updates. The attacker may want to impersonate the mobile node or the correspondent node, sending messages on behalf of one or both of them. The attacker may also want to eavesdrop on signaling messages in order to gather the information it needs for a later strike. In either case, the attacker will have to get active on the home-address test, because the home-address test is decisive for the mobile node's authenticity. For this, the mobile node needs to be located on the path between the mobile node's home agent and the correspondent node, because data on the path between the mobile node and its home agent is protected by IPsec. The attacker thus has to be somewhere within the fixed Internet. Having to tamper with static infrastructure, however, is assumed to be an obstacle significant enough to prevent many such attacks [3]. Suppose that, in spite of hurdles, there is an attacker which has access to the path between the mobile node's home agent and the correspondent node. This attacker is in a position to listen to or intercept the Home Test Init and Home Test messages as well as to spoof these and other Mobile IPv6 messages. The likely purpose behind such an attack is to impersonate the mobile node, to install a false binding on behalf of the mobile node, and to divert the mobile node's data to an arbitrary location. The point is that, due to the attacker's position, such an attack can be accomplished even with the standard binding-update procedure. For this, the attacker listens to the Home Test message on its way from the correspondent node to the mobile node's home agent. It may also send to the correspondent node a spoofed Home Test Init message and intercept the returning Home Test message. The attacker then sends to the correspondent node a spoofed Care-of Test Init message. The attacker will probably use a care-of address through which it is reachable, for instance, its own current care-of address or its home address. This way, the attacker makes sure that it receives the returning Care-of Test message. The Care-of Test Init message can be sent from anywhere in the Internet unless prevented by ingress filtering. Since ingress filtering is not universally employed, sending the spoofed Care-of Test Init message is not difficult. Having the Home Test message and the Care-of Test message, the attacker can authenticate a fraud Binding Update message. Vogt, Ed., et al. Expires August 4, 2004 [Page 22] Internet-Draft Early Binding Updates February 2004 This discussion shows that eavesdropping and impersonation is not prevented by taking the disjoint-paths approach of the standard binding-update procedure. Instead, access to a particular path within the fixed Internet is already enough. We hence believe that an Early Binding Update is equally secure than a standard binding update with respect to these attacks. 6.2 Concurrent Care-of Address Tests A successful care-of-address test provides reasonable assurance to the correspondent node that the mobile node is reachable through the IP address which the mobile node wishes to register as its care-of address. This assurance is a necessary precaution against flooding attacks. If no care-of-address test was performed, a malicious mobile node could start downloading large volumes of data from multiple correspondent nodes and direct these data flows to an arbitrary IP address. Early Binding Updates allow a mobile node to use a new care-of address while the care-of-address test is in progress. This strategy reduces the latency associated with a binding update. Concerning security against flooding attacks, Early Binding Updates are at a minor disadvantage with standard binding updates, because a malicious node may exploit the time window during which a correspondent node sends data to a yet-unverified care-of address. We propose two ways to mitigate this threat. One way is to properly configure the lifetime of a tentative binding-cache entry. We propose the value, TENTATIVE_BINDING_LIFETIME, given in Section 8. In scenarios where flooding attacks cannot be ruled out, one should appropriately reduce TENTATIVE_BINDING_LIFETIME. Another way to mitigate the threat of flooding attacks is to grant Early Binding Updates to trusted nodes only. Recall that the correspondent node can authenticate a mobile node at the time it receives an Early Binding Update message from the mobile node. In other words, the correspondent node can assume that the mobile node is the legitimate owner of the IP address which the mobile node uses as its home address. This, in turn, allows the correspondent node to use the mobile node's home address as a criterion for deciding whether or not to install a tentative binding-cache entry with the mobile node's new care-of address. For instance, the correspondent node may be a corporate server which grants Early Binding Updates to mobile nodes from the corporate network only. Due to the ability to configure, and selectively apply, Early Binding Vogt, Ed., et al. Expires August 4, 2004 [Page 23] Internet-Draft Early Binding Updates February 2004 Updates, we believe that the optimization's disadvantage concerning security against flooding attacks is negligible in most practical scenarios. 7. Conclusion Mobile IPv6 defines two address tests that must be performed before a mobile node can register a new care-of address with its correspondent node: a home-address test and a care-of-address test. The long latency associated with the address tests makes it difficult for delay-sensitive applications to hold up service quality during a binding update. We propose a strategy, Early Binding Updates, to move both address test out of the critical period during which a new care-of address cannot yet be used. We perform the home-address test before the mobile node changes its point of network attachment. We execute the care-of-address test in parallel with sending data to and from the new care-of address. We evaluate Early Binding Updates with respect to the standard binding-update procedure. We find that an Early Binding Update can be accomplished in half, or less, of the time that a standard binding update takes. Moreover, we show that an Early Binding Update is nearly equivalent to a standard binding update with respect to security, and that it marginally increases the resources required at the correspondent node. 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. 8. Protocol Configuration Variables TENTATIVE_BINDING_LIFETIME 3 seconds (default) References [1] Johnson, D., Perkins, C. and J. Arkko, "Mobility Support in IPv6", draft-ietf-mobileip-ipv6-24 (work in progress), June 2003. Vogt, Ed., et al. Expires August 4, 2004 [Page 24] Internet-Draft Early Binding Updates February 2004 [2] Arkko, J., Devarapalli, V. and F. Dupont, "Using IPsec to Protect Mobile IPv6 Signaling between Mobile Nodes and Home Agents", draft-ietf-mobileip-mipv6-ha-ipsec-06 (work in progress), July 2003. [3] Nikander, P., "Mobile IP version 6 Route Optimization Security Design Background", draft-nikander-mobileip-v6-ro-sec-02 (work in progress), December 2003. Authors' Addresses Christian Vogt (Editor and Contact Person) Institute of Telematics University of Karlsruhe (TH) P.O. Box 6980 76128 Karlsruhe Germany Phone: +49-721-608-8282 Fax: +49-721-388-097 EMail: chvogt@tm.uka.de URI: http://www.tm.uka.de/~chvogt/ Roland Bless Institute of Telematics University of Karlsruhe (TH) P.O. Box 6980 76128 Karlsruhe Germany Phone: +49-721-608-6413 Fax: +49-721-388-097 EMail: bless@tm.uka.de URI: http://www.tm.uka.de/~bless/ Vogt, Ed., et al. Expires August 4, 2004 [Page 25] Internet-Draft Early Binding Updates February 2004 Mark Doll Institute of Telematics University of Karlsruhe (TH) P.O. Box 6980 76128 Karlsruhe Germany Phone: +49-721-608-6403 Fax: +49-721-388-097 EMail: doll@tm.uka.de URI: http://www.tm.uka.de/~doll/ Tobias Küfner Institute of Telematics University of Karlsruhe (TH) P.O. Box 6980 76128 Karlsruhe Germany Phone: +49-721-608-8282 Fax: +49-721-388-097 EMail: kuefner@tm.uka.de URI: http://www.tm.uka.de/~kuefner/ Vogt, Ed., et al. Expires August 4, 2004 [Page 26] Internet-Draft Early Binding Updates February 2004 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any intellectual property 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; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication 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 implementors or users of this specification can be obtained from the IETF Secretariat. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director. Full Copyright Statement Copyright (C) The Internet Society (2004). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assignees. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION Vogt, Ed., et al. Expires August 4, 2004 [Page 27] Internet-Draft Early Binding Updates February 2004 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Vogt, Ed., et al. Expires August 4, 2004 [Page 28]