Network Working Group J. Arkko Internet-Draft Ericsson Research NomadicLab Expires: March 29, 2007 C. Vogt Universitaet Karlsruhe (TH) W. Haddad Ericsson Research September 25, 2006 Applying Cryptographically Generated Addresses and Credit-Based Authorization to Mobile IPv6 draft-ietf-mipshop-cga-cba-01.txt Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on March 29, 2007. Copyright Notice Copyright (C) The Internet Society (2006). Abstract This document proposes an enhanced security mechanism for Mobile IPv6 route optimization, providing lower handoff delays, increased security, and reduced signaling overhead. Arkko, et al. Expires March 29, 2007 [Page 1] Internet-Draft CGA and CBA for Mobile IPv6 September 2006 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Objectives . . . . . . . . . . . . . . . . . . . . . . . . . 4 2.1 Handoff Latency . . . . . . . . . . . . . . . . . . . . . 5 2.2 Security . . . . . . . . . . . . . . . . . . . . . . . . . 5 2.3 Signaling Overhead . . . . . . . . . . . . . . . . . . . . 6 3. Protocol Design . . . . . . . . . . . . . . . . . . . . . . 7 4. Protocol Operation . . . . . . . . . . . . . . . . . . . . . 9 4.1 Sending Binding Update Messages . . . . . . . . . . . . . 9 4.2 Receiving Binding Update Messages . . . . . . . . . . . . 13 4.3 Sending Binding Acknowledgment messages . . . . . . . . . 15 4.4 Receiving Binding Acknowledgment Messages . . . . . . . . 16 4.5 Sending CGA Parameters . . . . . . . . . . . . . . . . . . 16 4.6 Receiving CGA Parameters . . . . . . . . . . . . . . . . . 18 4.7 Sending Permanent Home Keygen Tokens . . . . . . . . . . . 19 4.8 Receiving Permanent Home Keygen Tokens . . . . . . . . . . 19 4.9 Handling Payload Packets . . . . . . . . . . . . . . . . . 20 4.10 Credit Aging . . . . . . . . . . . . . . . . . . . . . . 22 4.11 Simultaneous Movements . . . . . . . . . . . . . . . . . 22 5. Option Formats and Status Codes . . . . . . . . . . . . . . 22 5.1 CGA Parameters Option . . . . . . . . . . . . . . . . . . 23 5.2 Signature Option . . . . . . . . . . . . . . . . . . . . . 24 5.3 Permanent Home Keygen Token Option . . . . . . . . . . . . 24 5.4 Care-of Test Init Option . . . . . . . . . . . . . . . . . 25 5.5 Care-of Test Option . . . . . . . . . . . . . . . . . . . 26 5.6 Status Codes . . . . . . . . . . . . . . . . . . . . . . . 26 6. Security Considerations . . . . . . . . . . . . . . . . . . 27 6.1 Home Address Ownership . . . . . . . . . . . . . . . . . . 28 6.2 Care-of Address Ownership . . . . . . . . . . . . . . . . 29 6.3 Time Shifting Attacks . . . . . . . . . . . . . . . . . . 31 6.4 Replay Attacks . . . . . . . . . . . . . . . . . . . . . . 32 6.5 Resource Exhaustion . . . . . . . . . . . . . . . . . . . 33 6.6 IP Address Ownership of Correspondent Node . . . . . . . . 33 7. Performance Considerations . . . . . . . . . . . . . . . . . 34 8. Protocol Constants . . . . . . . . . . . . . . . . . . . . . 34 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . 35 10. Acknowledgment . . . . . . . . . . . . . . . . . . . . . . . 35 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 36 11.1 Normative References . . . . . . . . . . . . . . . . . . 36 11.2 Informative References . . . . . . . . . . . . . . . . . 36 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 38 A. Overview of CGA . . . . . . . . . . . . . . . . . . . . . . 38 B. Overview of Credit-Based Authorization . . . . . . . . . . . 40 C. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 41 Intellectual Property and Copyright Statements . . . . . . . 44 Arkko, et al. Expires March 29, 2007 [Page 2] Internet-Draft CGA and CBA for Mobile IPv6 September 2006 1. Introduction Mobile IPv6 route optimization [1] allows mobile nodes to communicate with correspondent nodes via a direct path in spite of changes in IP connectivity. Route optimization reduces the latency of packet propagation to a minimum, in opposition to the default approach of routing all packets via a stationary home agent. It was designed in an effort to accommodate real-time and interactive applications in the presence of IP mobility. Mobile and correspondent nodes use a stable "home address" in identifying the mobile node at stack layers above IP, while packets are sent or received via a "care-of address" that routes to the mobile node's current network attachment. The Mobile IPv6 protocol swaps the IP addresses when a packet traverses the IP layer. Both end nodes maintain a binding between the home address and the care-of address. It is the mobile node's responsibility to update the binding at the correspondent node when it changes IP connectivity. From a security perspective, the request for a binding update requires a correspondent node to verify a mobile node's ownership of both the home and the care-of address. Unprecedented attack possibilities [8] would arise if correspondent nodes took liberties with respect to these obligations: An impersonator could claim a victim's IP address and request a correspondent node to bind this, as a home address, to its own care-of address. The impersonator could then communicate on behalf of the victim. A flooding attacker could use its own home address in combination with a care-of address that in fact would belong to a victim. This victim would receive packets that should actually be routed to the attacker. A fundamental constraint for the security design of route optimization is that it must do without a pre-existing relationship between a mobile node and a correspondent node. Reliance on a PKI is likewise assessed unsuitable given a number of intrinsic problems [9] that PKIs would entail in the context of mobility. The default mechanism to authorize a binding update for a correspondent node is instead based on a preceding return routability procedure. This allows the correspondent node to verify the mobile node's reachability at the home and care-of addresses in an ad-hoc, non- cryptographic manner. Reachability at both IP addresses indicates (though it does not guarantee) the mobile node's ownership of the IP addresses, and hence that binding these IP addresses is secure. Unfortunately, the home and care-of address tests of the return routability procedure are still vulnerable to those impersonators and flooding attackers which can interpose in the respective test. This may be considered acceptable for the care-of address test given that Arkko, et al. Expires March 29, 2007 [Page 3] Internet-Draft CGA and CBA for Mobile IPv6 September 2006 a flooding attacker capable of compromising the test would expose itself to the same packet flood that also befalls the victim. Yet impersonation is a more intractable threat, which constitutes an obstacle for the deployment of route optimization. Besides security- related drawbacks, performance-wise, both IP address tests have the disadvantage of increasing handoff delays. The protocol defined in this document amends Mobile IPv6 route optimization in two ways: A mobile node's home address is secured against impersonation through an interface identifier that is cryptographically and verifiably bound to the mobile node's public/ private-key pair. The mobile node proves ownership of the home address by providing evidence that it knows the correct private key. An initial home address test confirms the home address prefix, but subsequent tests can be spared. This alone would leave the latency of the care-of address test, so in addition, correspondent nodes allow this test to proceed in parallel with regular data traffic. To preclude the threat of redirection-based flooding until the test succeeds, the amount of data sent to the care-of address is bound by a dynamically determined limit. These two optional enhancements can be applied separately or, preferably, in conjunction. 2. Objectives The design of Mobile IPv6 route optimization is in may ways conservative, leaving room to optimize handoff delay, security, and signaling overhead. The protocol defined in this document tackles these issues and thus constitutes a more progressive variant of the base mobility protocol. In spite of any improvements in the mobility protocol, it is important to take into account that other mobility-related activities in the protocol stack may have their own impact, in particular on handoff delay. E.g., attachment procedures, access control, and authentication at the link layer contribute their own delay. So do IPv6 tasks such as router discovery, neighbor discovery, movement detection, and address configuration. These other delays are in many cases significantly larger than the handoff delay of Mobile IPv6 route optimization. The protocol defined in this document concentrates on making the mobility signaling as efficient as possible, ignoring mobility-related functions elsewhere in the protocol stack. The improvements that the protocol facilitates hence ought to be seen in view of the entire protocol stack. Arkko, et al. Expires March 29, 2007 [Page 4] Internet-Draft CGA and CBA for Mobile IPv6 September 2006 2.1 Handoff Latency The typical handoff delay in Mobile IPv6 route optimization is 1 round-trip time between the mobile node and the home agent for the home registration, 1 round-trip time between the mobile node and the home agent plus 1 round-trip time between the home agent and the correspondent node for the return routability procedure, and 1 one- way time from the mobile node to the correspondent node for the propagation of the Binding Update message. (The assumption here is that the latency of the return routability procedure is dominated by the home-address test.) The first packet sent to the new care-of address requires 1 additional one-way time to propagate from the correspondent node to the mobile node. The mobile node can resume transmissions right after it has dispatched the Binding Update message. But if it requests a Binding Acknowledgment message from the correspondent node, communications are usually delayed until this is received. Handoff delays in Mobile IPv6 route optimization are additive to other delays at IP layer or link layer. They can cause perceptible quality degradations for interactive and real-time applications. TCP bulk-data transfers are likewise affected since long handoff latencies may lead to successive retransmission timeouts and degraded throughput [10]. This protocol eliminates the additional handoff delay induced by Mobile IPv6 route optimization for packets that a mobile node sends, and it reduces the delay to 1 round-trip time between the mobile node and the correspondent node for packets that the mobile node receives. 2.2 Security Given that mobile and correspondent nodes with support for Mobile IPv6 route optimization form a true subset of all Internet nodes, the security design of the mobility protocol cannot make the Internet any safer than it is without the mobility protocol. The return routability procedure was therefore designed with the objective to provide a level of security which compares to that of today's non- mobile Internet [8]. As such, it protects against impersonation and denial of service that an insecure mobility protocol may be vulnerable to. In particular, the return routability procedure satisfies the following key requirements for mobility protocols: o An attacker should not be able to redirect a third node's communication flow to itself or to another IP address, at least not beyond what is already possible in plain IPv6. This requirement applies both to ongoing and future communication flows. Arkko, et al. Expires March 29, 2007 [Page 5] Internet-Draft CGA and CBA for Mobile IPv6 September 2006 o An attacker should not be able to redirect its own communication flows to a third party, flooding the victim with unrequested packets. Such redirection-based flooding attack would provide substantial amplification that is today only possible through a network of compromised nodes [11]. E.g., an attacker could accomplish the initial TCP handshake for a voluminous file download through its own address (or home address, for that matter), and then redirect the flow to the address of its victim. The attacker could spoof acknowledgments on behalf of the victim based on the sequence numbers it learned from the initial handshake, but those would be small compared to the full-sized segments that the correspondent node generates. o Attackers should not be able to cause denial-of-service through potentially expensive computations involved in the mobility protocol. Applications that require a higher security level than the return routability procedure can provide are generally advised to use end- to-end protection such as IPsec or TLS. But even then are they vulnerable to denial of service. Furthermore, these mechanisms either require end nodes to be preconfigured with credentials for mutual authentication, or they depend on a public-key infrastructure. Either approache impedes [9] wide deployment of Mobile IPv6 route optimization. The protocol defined in this document permits end nodes to authenticate each other by means of a cryptographic property of their home addresses. It neither depends on preconfiguration nor on a public-key infrastructure, and yet it conforms to the key requirements listed above. 2.3 Signaling Overhead A complete correspondent registration involves 6 message transmissions at the mobile node, totaling about 376 bytes (cf. [12]). This signaling overhead may be acceptable if movements are infrequent. E.g., a mobile node that moves once every 30 minutes generates an average of 1.7 bits/second of signaling traffic. Higher mobility causes more serious overhead, however. A cell size of 100 meters and a speed of 120 km/h yields 1 movement every 3 seconds and about 1,000 bits/second of signaling traffic. This compares to a highly compressed voice stream with a typical data rate of 10,000 to 30,000 bits/second. The protocol defined in this document introduces a new message exchange between mobile and correspondent nodes in order to accomplish the desired improvements in handoff delay. The implied new signaling overhead is compensated for by verifying reachability of the care-of address in-band, sparing a separate message exchange. Arkko, et al. Expires March 29, 2007 [Page 6] Internet-Draft CGA and CBA for Mobile IPv6 September 2006 Standard Mobile IPv6 requires mobile nodes to renew a binding at a correspondent node at least every 7 minutes. The signaling overhead amounts to 7.16 bits per second if the mobile node communicates with a stationary node [12]. It doubles if both peers are mobile. This overhead may be negligible when the nodes communicate, but it can be an issue for mobile nodes that are inactive and stay at the same location for a while. These nodes typically prefer to go to standby mode to conserve battery power. Also, the periodic refreshments consume a fraction of the wireless bandwidth that one could use more efficiently. The protocol defined in this document allows correspondent nodes to specify a binding lifetime much larger than 7 minutes. It thereby reduces the signaling overhead generated by mobile nodes that do not change their care-of address for a while. 3. Protocol Design The protocol defined in this document applies a set of techniques in order to meet the objectives discussed in Section 2. These are summarized in the following: Cryptographically generated home addresses A Mobile IPv6 binding is conceptually a packet redirection from a home address to a care-of address. The home address is the source of the redirection, whereas the care-of address is the destination. The packets to be redirected can hence be identified based on the home address. This motivates a strong, cryptographic ownership proof for the home address. The protocol defined in this document features this through the application of cryptographically generated home addresses [13][14]. In general, a cryptographically generated address [15] provides a strong, cryptographic binding between the interface identifier of the address and the address owner's public key. This enables other nodes to securely authenticate the owner as such, modulo the correctness of the address prefix. Cryptographically generated home addresses can supersede home address tests with the exeption of an initial test for validating the home address prefix. This facilitates lower handoff delays as well as longer binding lifetimes and, consequently, reduced signaling overhead for nodes which temporarily do not move. Non-cryptographic care-of addresses In contrast to a home address, a care-of address does not have identifying functionality. There is hence little benefit in a cryptographic ownership proof of a care-of address. Given that Arkko, et al. Expires March 29, 2007 [Page 7] Internet-Draft CGA and CBA for Mobile IPv6 September 2006 the care-of address is the destination of a packet redirection, it is rather the mobile node's reachability at the care-of address which matters. The protocol defined in this document uses care-of address tests for this purpose, but allows correspondent nodes to send packets to a new care-of address already before the mobile node has been found to be reachable at the address. Semi-permanent security associations Cryptographically generated addresses involve public-key cryptography and are computationally inefficient to validate. Further, the technique requires a significant amount of supplementary data to be piggybacked onto protected messages. The protocol defined in this document therefore leverages the cryptographic property of home addresses to securely exchange a secret shared key between a mobile node and a correspondent node [16]. This key is used to authenticate subsequent signaling messages efficiently. Initial home address tests An initial home address test is necessary in order to prevent redirection-based flooding attacks against an alleged home network. Specifically, in the absence of a home address test, a malicious node can cryptographically generate a home address with the prefix of a targeted victim network, and register a binding between this spoofed home address and its own IP address at a correspondent node. The attacker proceeds to request the correspondent node, which may be a public server, to send a stream of packets to its current location. The attacker then de- registers the binding, or lets it expire, with the consequence of having the correspondent node redirect the packet stream "back" to the victim network. The result is a flooding attack against the victim network. To avoid such misuse, the initial home address test is executed at the same time as the semi-permanent security association is being established [16]. The test does not need to be repeated upon subsequent movements, however. Concurrent care-of address tests The protocol defined in this document allows a correspondent node to send packets to a new care-of address already before a proof of reachability at that address has been received from the mobile node. Specifically, when the mobile node moves to a different link, it first registers its new care-of address without providing a proof of reachability. The correspondent node registers the unverified care-of address on a tentative basis and sends a token to the mobile node based on which the latter can follow up with a Arkko, et al. Expires March 29, 2007 [Page 8] Internet-Draft CGA and CBA for Mobile IPv6 September 2006 proof of reachability. This completes the binding update. Credit-Based Authorization Concurrent care-of address tests without additional protection would enable an attacker to temporarily redirect its own communication flows to a spoofed, unverified care-of address. This introduces a vulnerability to redirection-based flooding attacks and is hence in conflict with the security requirements defined in Section 2.2. Recall that the appeal of redirection- based flooding attacks is the potential for significant amplification. Credit-Based Authorization [17] guarantees that malicious packet redirection cannot generate amplification. This defeats the purpose of redirection-based flooding: Any attacker could more effectively flood its victim by sending bogus packets directly. Reduced reachability verification A cryptographically generated home address does not tell whether its prefix is correct, so there is still need for a home address test. Reachability verification is also required for care-of addresses since those are not cryptographically protected. The protocol defined in this document executes a home address test during the initial key establishment procedure and a care-of address test upon each handoff. However, due to the strong, cryptographic address ownership authentication of the home address, binding lifetimes can be much longer than in standard Mobile IPv6 route optimization, and reachability tests may occur on a less frequent basis. 4. Protocol Operation The protocol defined in this document features a variety of possible message exchanges. These are described below, packaged by the type of message processing operation. 4.1 Sending Binding Update Messages A mobile node may initiate a correspondent registration for any of the following reasons: o To establish a new binding at a correspondent node so that further packets can be route-optimized and do no longer need to be routed Arkko, et al. Expires March 29, 2007 [Page 9] Internet-Draft CGA and CBA for Mobile IPv6 September 2006 through the mobile node's home agent. o To update an existing binding at the correspondent node while moving from one point of IP attachment to another. o To follow up an early Binding Update message with a complete Binding Update message after receiving a Binding Acknowledgment message with a Care-of Test option. o To refresh an existing binding at the correspondent node without changing its point of IP attachment. o To request the correspondent node to renew an existing permanent home keygen token shared between the mobile node and the correspondent node (cf. Section 4.5). In any of these cases, the mobile node sends a Binding Update message to the correspondent node. The Binding Update message MUST be authenticated either through the CGA property of the mobile node's home address, or through a proof of reachability at the home address. The appropriate authentication method is selected as follows: o If the mobile node's home address is a CGA, and the mobile node has a permanent home keygen token in its Binding Update List entry for the correspondent node, the mobile node MUST authenticate the Binding Update message with the CGA property of its home address. o If the mobile node's home address is a CGA, but the mobile node does not have a permanent home keygen token in its Binding Update List entry for the correspondent node, the mobile node MUST authenticate the Binding Update message with a proof of reachability at its home address. o If the mobile node's home address is not a CGA, the mobile node MUST authenticate the Binding Update message with a proof of reachability at its home address. The mobile node SHOULD request the correspondent node to accept its CGA parameters for future CGA-based authentication if its home address is a CGA, but it does not yet have a permanent home keygen token from the correspondent node. The mobile node then includes its CGA parameters in the Binding Update message by adding one or more CGA Parameters options (cf. Section 5.1) followed by a Signature option (cf. Section 5.2). Once a permanent home keygen token has been obtained from the correspondent node, the mobile node MUST authenticate all subsequent Binding Update messages with the CGA property of its home address until either the binding lifetime expires, or the mobile node explicitly de-registers from the Arkko, et al. Expires March 29, 2007 [Page 10] Internet-Draft CGA and CBA for Mobile IPv6 September 2006 correspondent node. The mobile node MAY choose to ignore the CGA property of its home address and continue authenticating Binding Update messages through a proof of reachability at the home address, but this behavior is NOT RECOMMENDED. The mobile node also includes its CGA parameters in the Binding Update message if it intends to renew an existing permanent home keygen token shared with the correspondent node (cf. Section 4.5). This is accomplished, as before, by adding to the message one or more CGA Parameters options and a Signature option. The authenticator for the Binding Update message is calculated based on a permanent or temporary home keygen token. Which type of home keygen token the mobile node uses in calculating the authenticator depends on the authentication method: o If the Binding Update message is to be authenticated through the CGA property of the mobile node's home address, the mobile node MUST use the permanent home keygen token that is has in its Binding Update List entry for the correspondent node. o If the Binding Update message is to be authenticated through a proof of reachability at the home address, the mobile node MUST use a temporary home keygen token from the correspondent node. The mobile node may already have a valid temporary home keygen token in its Binding Update List entry for the correspondent node, or it may retrieve one through the exchange of a Home Test Init message and a Home Test message as defined in [1]. The authenticator for the Binding Update message is further calculated based on a care-of keygen token. The care-of keygen token to be used is selected as follows: o If the mobile node has a valid care-of keygen token in its Binding Update List entry for the correspondent node, the mobile node MUST use this in calculating the authenticator for the Binding Update message. The Binding Update message is in this case "complete". o If the mobile node does not have a valid care-of keygen token in its Binding Update List entry for the correspondent node, the mobile node SHOULD define the care-of keygen token to be zero and use this in calculating the authenticator for the Binding Update message. The Binding Update message is in this case "early". o If the mobile node does not have a valid care-of keygen token in its Binding Update List entry for the correspondent node, the mobile node MAY choose to retrieve a care-of keygen token through the exchange of a Care-of Test Init message and a Care-of Test Arkko, et al. Expires March 29, 2007 [Page 11] Internet-Draft CGA and CBA for Mobile IPv6 September 2006 message, as defined in [1], without sending an early Binding Update message. In this case, the mobile node waits for receipt of the Care-of Test message and uses the care-of keygen token contained therein in calculating the authenticator for a complete Binding Update message. This approach is NOT RECOMMENDED, however. If the Binding Update message is early, the mobile node MUST add a Care-of Test Init option to the message, requesting the correspondent node to return a new care-of keygen token. Once a responding Binding Acknowledgment message with a Care-of Test option is received, the mobile node MUST use the care-of keygen token contained therein in calculating the authenticator for a complete Binding Update message and send this message to the correspondent node. The mobile node includes the nonce indices associated with the selected home and care-of keygen tokens in the Binding Update message using a Nonce Indices option [1]. These nonce indices are determined as follows: o The home nonce index is defined to be zero if the Binding Update message is to be authenticated through the CGA property of the mobile node's home address. (In this case, the mobile node uses a permanent home keygen token to calculate the authenticator for the Binding Update message.) o If the Binding Update message is to be authenticated through a proof of reachability at the home address, the mobile node uses a temporary home keygen token to calculate the authenticator for the Binding Update message, and the associated home nonce index is taken from the Home Test message with which the home keygen token was obtained. o The care-of nonce index is zero if the Binding Update message is early. o If the Binding Update message is complete, the associated nonce index is taken from the Care-of Test message with which the care-of keygen token was obtained. The Nonce Indices option follows the CGA Parameters and Signature options, if any. The mobile node finally calculates an authenticator for the Binding Update message based on the selected home and care-of keygen tokens, following the rules described in [1]. The authenticator is placed into a Binding Authorization Data option [1], which the mobile node adds to the Binding Update message as the last option. Arkko, et al. Expires March 29, 2007 [Page 12] Internet-Draft CGA and CBA for Mobile IPv6 September 2006 4.2 Receiving Binding Update Messages When the correspondent node receives a Binding Update message, it must first verify whether the sending mobile node is the legitimate owner of the home address specified in the message. This is accomplished either through the CGA property of the home address, or through verification of the mobile node's reachability at the home address. The correspondent node selects the authentication method based on the home nonce index given in the Nonce Indices option of the Binding Update message: o If the home nonce index is zero, the correspondent node MUST authenticate the Binding Update message through the CGA property of the home address. o If the home nonce index is set to a non-null value, the correspondent node MUST authenticate the Binding Update message through verification of the mobile node's reachability at the home address. The authenticator for the Binding Update message is calculated based on a permanent or temporary home keygen token. Which type of home keygen token the correspondent node uses in validating the authenticator, and how to retrieve or recompute the home keygen token, depends on the authentication method: o If the Binding Update message is to be authenticated through the CGA property of the mobile node's home address, the correspondent node should have a permanent home keygen token in its Binding Cache entry for the mobile node. If so, the correspondent node MUST use this permanent home keygen token in validating the authenticator of the Binding Update message. If the correspondent node does not have a Binding Cache entry for the mobile node or the existing Binding Cache entry for the mobile node does not include a permanent home keygen token, the correspondent node MUST reject the Binding Update message by sending a Binding Acknowledgment message with status code TBD ("Permanent Home Keygen Token Unavailable"). o If the Binding Update message is to be authenticated through verification of the mobile node's reachability at the home address, the correspondent node MUST verify that it does not have a permanent home keygen token in its Binding Cache entry for the mobile node. Provided that no permanent home keygen token is found, the correspondent node MUST recompute the temporary home keygen token defined by the (non-null) home nonce index in the Nonce Indices option of the Binding Update message, and it MUST use this recomputed token in validating the authenticator of the Arkko, et al. Expires March 29, 2007 [Page 13] Internet-Draft CGA and CBA for Mobile IPv6 September 2006 message. On the other hand, in case the correspondent node does have a permanent home keygen token in its Binding Cache entry for the mobile node, further action depends on whether the Binding Update message includes a CGA Parameters option. If the message does not include a CGA Parameters option, the correspondent node MUST reject the message by sending a Binding Acknowledgment message with status code TBD ("Conflicting Permanent Home Keygen Token"). This is necessary to ensure that an attacker cannot bid down the authentication method to hijack a mobile node's legitimate binding. However, if a CGA Parameters option is included in the Binding Update message, the message is processed further. The sending mobile node is in this case requesting a new permanent home keygen token. Binding Update messages sent for the purpose of renewing an existing permanent home keygen token are usually authenticated through the CGA property of the mobile node's home address, based on the existing permanent home keygen token. However, a mobile node may authenticate the Binding Update message through verification of its reachability at the home address when it has lost the permanent home keygen token, for instance, due to a reboot. The correspondent node MUST then recompute the temporary home keygen token defined by the (non- null) home nonce index in the Nonce Indices option of the Binding Update message and use this recomputed token in validating the authenticator of the message. Note that the Binding Update message will still be rejected eventually should the authentication through the CGA property of the mobile node's home address fail during processing of the CGA Parameters option. The authenticator for the Binding Update message is further calculated based on a care-of keygen token. Which care-of keygen token the correspondent node uses in validating the authenticator depends on whether the Binding Update message is complete or early: o If the care-of nonce index in the Nonce Indices option of the Binding Update message is set to a non-null value, the Binding Update message is complete. In this case, the correspondent node MUST recompute the care-of keygen token defined by the index, and it MUST use this recomputed token in validating the authenticator of the message. o If the care-of nonce index is zero, the Binding Update message is early. In this case, the correspondent node uses a value of zero in validating the authenticator of the Binding Update message. The correspondent node finally validates the authenticator in the Binding Update message based on the selected home and care-of keygen tokens, following the algorithm described in [1]. Arkko, et al. Expires March 29, 2007 [Page 14] Internet-Draft CGA and CBA for Mobile IPv6 September 2006 If the validation fails, the correspondent node MUST discard the Binding Update message. The correspondent node may have to send a Binding Acknowledgment message with a negative status code as described in [1]. Provided that the validation of the authenticator in the Binding Update message succeeds, the correspondent node registers the mobile node's new care-of address, either updating an existing Binding Cache entry, if one exists, or creating a new Binding Cache entry. The state of the new care-of address depends on whether the Binding Update message is complete or early: o If the Binding Update message is complete, the new care-of address is set to VERIFIED state. The correspondent node may then immediately send packets to the new care-of address without restrictions. o If the Binding Update message is early, the new care-of address is set to UNVERIFIED state. The correspondent node MUST then follow the rules defined in section 5.4 for sending packets to this care-of address until the care-of address is set in VERIFIED state. If the Binding Update message contains a CGA Parameters option, the mobile node is requesting the correspondent node to accept the included CGA parameters either for establishing a new, or for renewing an existing permanent home keygen token shared between the mobile node and the correspondent node. The correspondent node MUST in this case check if the CGA Parameters option is directly followed by a Signature option and, if so, validate the signature included in the latter. This is done as described in Section 4.6. If the CGA Parameters option is not directly followed by a Signature option, or the validation of the signature included in the Signature option fails, the correspondent node MUST silently discard the Binding Update message. Provided that the signature included in the Signature option is correct, the correspondent node generates a permanent home keygen token to be shared with the mobile node and stores it in its Binding Cache entry for the mobile node. The permanent home keygen token is sent to the mobile node within a Binding Acknowledgment message as described in Section 4.3. 4.3 Sending Binding Acknowledgment messages Upon receipt of a valid Binding Update message, the correspondent Arkko, et al. Expires March 29, 2007 [Page 15] Internet-Draft CGA and CBA for Mobile IPv6 September 2006 node returns to the mobile node a Binding Acknowledgment message in any of the following cases: o The Acknowledge flag in the Binding Update message is set. o The Binding Update message is early and includes a Care-of Test Init option. o The Binding Update message contains a CGA Parameters option followed by a Signature option, and the signature included in the latter was determined to be correct. If the Binding Update message is early, the Binding Acknowledgment message MUST contain a Care-of Test option with a pseudo-random value in the Care-of Keygen Token field. If the Binding Update message contains a CGA Parameters option followed by a Signature option, and the signature included in the latter was determined to be correct, the Binding Acknowledgment message MUST include a Permanent Home Keygen Token option with the permanent home keygen token stored in the correspondent node's Binding Cache entry for the mobile node. 4.4 Receiving Binding Acknowledgment Messages A mobile node verifies a received Binding Acknowledgment message according to the rules specified in [1]. If the Binding Acknowledgment message contains a Care-of Test option, the mobile node extracts the care-of keygen token included in this option, stores this token in the appropriate entry of its Binding Update List, and sends the correspondent node a complete Binding Update message as defined in section Section 4.1. If the Binding Acknowledgment message contains a Permanent Home Keygen Token option, the mobile node extracts the permanent home keygen token included in this option and stores it in the appropriate entry of its Binding Update List. Future Binding Update messages will then be authenticated based on the CGA property of the mobile node's home address. 4.5 Sending CGA Parameters A mobile node SHOULD send its CGA parameters to the correspondent node in any of the following situations: Arkko, et al. Expires March 29, 2007 [Page 16] Internet-Draft CGA and CBA for Mobile IPv6 September 2006 o To acquire a permanent home keygen token if the mobile node's home address is a CGA, and the mobile node does not yet have a permanent home keygen token from the correspondent node. o To extent the lifetime of an existing binding if the mobile node already has a permanent home keygen token from the correspondent node, and the lifetime of the binding at the correspondent node is about to expire. o To reinitialize the available sequence number space if the mobile node already has a permanent home keygen token from the correspondent node, and a sequence number rollover is imminent. In addition, a mobile node that already has a permanent home keygen token from the correspondent node MAY renew this token at any time by sending its CGA parameters to the correspondent node. Periodic renewal of the permanent home keygen token provides increased protection against cryptanalysis. The mobile node sends its CGA parameters to the correspondent node within a Binding Update message in the format of the CGA Parameters data structure defined in [18]. The CGA Parameters data structure is split over one or more CGA Parameters options as described in Section 5.1. The last CGA Parameters option MUST be directly followed by a Signature option (see Section 5.2). The Nonce Indices and Binding Authorization Data options MUST appear after the Signature option. The mobile node calculates the value for the Signature field in the Signature option according to the signature generation algorithm defined in section 6 of [18]. The value is calculated with the mobile node's private CGA key over the following sequence of octets: mobility data = care-of address | correspondent node IP address | MH data where "|" denotes concatenation. "Care-of address" is the mobile node's care-of address, and "correspondent node IP address" is the IP address of the correspondent node that the mobile node uses. In case the correspondent node is mobile, "correspondent node IP address" refers to the correspondent node's home address. "MH data" is the content of the Binding Update message including the mobility header and all options up to the last CGA Parameters option. That is, "MH data" excludes the IPv6 header and any IPv6 extension headers other than the mobility header itself. The "mobility data" constitutes what is referred to as the "message" in section 6 of [18]. The value for the Signature field is calculated as if the Checksum Arkko, et al. Expires March 29, 2007 [Page 17] Internet-Draft CGA and CBA for Mobile IPv6 September 2006 field in the mobility header was zero. The Checksum field in the transmitted packet is still calculated in the usual manner, with the calculated value in the Signature field being a part of the packet protected by the checksum. 4.6 Receiving CGA Parameters A correspondent node that receives a Binding Update message first processes the message as described in [1], even if the message includes CGA Parameters and Signature options. This includes a verification of the Authenticator value in the Binding Authorization Data option. If the Binding Update message is rejected due to an incorrect Authenticator value or for any other reason, the correspondent node does not process the message further. Otherwise, if the correspondent node accepts the Binding Update message and the message includes one or more CGA Parameters options directly followed by a Signature option, the correspondent node proceeds to verify the cryptographic properties of the mobile node's home address in the Binding Update message. It reassembles the CGA Parameters data structure from the CGA Parameters options included in the Binding Update message as described in Section 5.1, and executes the CGA verification algorithm defined in [18]. The CGA verification algorithm takes the home address and the reassembled CGA Parameters data structure as input. If the home address fails the CGA verification, the correspondent node skips the steps below and sends a Binding Acknowledgment message with status code TBD (CGA and signature verification failed) to the mobile node. If the cryptographic properties of the mobile node's home address are verified to be correct, the correspondent node performs the more time-consuming check of the signature. It extracts the signature from the Signature field in the Signature option and executes the signature verification algorithm defined in [18]. The signature verification algorithm takes as input the home address, the reassembled CGA Parameters data structure, the MH data as defined in Section 4.5, and the CGA Message Type tag for this protocol as defined in Section 8, and the signature itself. If the signature verification fails, the correspondent node skips the steps below and sends a Binding Acknowledgment message with status code TBD (CGA and signature verification failed) to the mobile node. The correspondent node does not accept the mobile node's home address as a CGA if either the CGA verification or the signature verification fails. However, in both cases, the correspondent node still accepts the contents of the Binding Update message excluding the CGA Parameters and Signature options, but does not provide a permanent Arkko, et al. Expires March 29, 2007 [Page 18] Internet-Draft CGA and CBA for Mobile IPv6 September 2006 home keygen token in the Binding Acknowledgment message. The correspondent node in particular follows the rules in [1] for sending a Binding Acknowledgment message to the mobile node. If both the CGA verification and the signature verification are successful, the correspondent node sends a Binding Acknowledgment message with an included Permanent Home Keygen Token option to the mobile node as described in Section 4.7. 4.7 Sending Permanent Home Keygen Tokens A correspondent node assigns a mobile node a new permanent home keygen token after it has received from the mobile node a Binding Update message with included CGA Parameters and Signature options, and these options have been successfully validated as described in Section 4.6. The permanent home keygen token is a 64-bit value, randomly generated by the correspondent node. The correspondent node stores the permanent home keygen token in the binding cache entry that it maintains for the mobile node. The correspondent node sends the permanent home keygen token to the mobile node in encrypted form within a Permanent Home Keygen Token option in a Binding Acknowledgment message. It sends this message even if the Acknowledge flag in the Binding Update message was clear. The Binding Acknowlegment message is built according to the rules in [1], except that it includes the Permanent Home Keygen Token option. The correspondent node encrypts the permanent home keygen token with the mobile node's public key using the RSAES-PKCS1-v1_5 format [2], and places the ciphertext into the Permanent Home Keygen Token field of the Permanent Home Keygen Token option. The Binding Authorization Data option MUST be the last option in the Binding Acknowledgment message. That is, the Authenticator value in the Binding Authorization Data option covers the Permanent Home Keygen Token option. 4.8 Receiving Permanent Home Keygen Tokens A mobile node that receives a Binding Acknowledgment message first processes the message as described in [1], even if the message includes a Permanent Home Keygen Token option. This includes a verification of the Authenticator value in the Binding Authorization Data option. If the Binding Acknowledgment message is rejected due to an incorrect Authenticator value or for any other reason, the mobile node does not process the message further. Arkko, et al. Expires March 29, 2007 [Page 19] Internet-Draft CGA and CBA for Mobile IPv6 September 2006 Otherwise, if the mobile node accepts the Binding Acknowledgment message and the message includes a Permanent Home Keygen Token option, the mobile node extracts the ciphertext from the Permanent Home Keygen Token field in this option and decrypts it with its private CGA key using the RSAES-PKCS1-v1_5 format [2]. The result of the encryption is the permanent home keygen token to be used in further registrations with the correspondent node. The mobile node stores the permanent home keygen token in the binding update list entry that it maintains for the correspondent node. 4.9 Handling Payload Packets The immediate exchange of an early Binding Update message after a handoff on the mobile node side enables mobile and correspondent nodes to quickly reestablish route-optimized communications via the mobile node's new care-of address. The mobile node may send payload packets to the correspondent node from the new care-of address as soon as the early Binding Update message has been transmitted. Like all other route-optimized payload packets that originate from the mobile node, these packets have the new care-of address in the Source Address field of the IPv6 header and the home address in the Home Address option of the IPv6 Destination Options extension header. The correspondent node redirects outgoing payload packets for the mobile node to the new care-of address once it has received the early Binding Update message and registered the new care-of address. These payload packets have the new care-of address in the Destination Address field of the IPv6 header and the home address in the IPv6 Routing extension header. The correspondent node limits the amount of data it sends to the mobile node while the new care-of address is UNVERIFIED to prevent amplified, redirection-based flooding attacks. This is specifically realized as follows: The correspondent node maintains a "credit counter" for each mobile nodes with which it uses the protocol specified in this document. Whenever a packet arrives from one of these mobile nodes, the correspondent node SHOULD increase that mobile node's credit counter by the size of the received packet. When the correspondent node has a packet to be sent to the mobile node, if the mobile node's care-of address is labeled UNVERIFIED, the correspondent node checks whether it can send the packet to the UNVERIFIED care-of address: The packet SHOULD be sent if the value of the credit counter is higher than the size of the outbound packet. If the credit counter is too low, the packet MUST be discarded or buffered until address verification succeeds. When a packet is sent to a mobile node at an UNVERIFIED care-of address, the mobile node's credit counter MUST be reduced by the size of the packet. The mobile node's credit counter is not affected by packets that the host sends Arkko, et al. Expires March 29, 2007 [Page 20] Internet-Draft CGA and CBA for Mobile IPv6 September 2006 to a VERIFIED care-of address of that mobile node. Figure 2 depicts the actions taken by the correspondent node when a packet is received. Figure 3 shows the decision chain in the event a packet is sent. Inbound packet | | +-----------------+ +-----------------+ | | Increase the | | Deliver the | +-----> | credit counter |---------------> | packet to the | | by packet size | | application | +-----------------+ +-----------------+ Figure 2: Receiving Packets with Credit-Based Authorization Outbound packet | _________________ | / \ +-----------------+ | / Is the \ No | Send the packet | +-----> | care-of address |-------------> | to the care-of | \ UNVERIFIED? / | address | \_________________/ +-----------------+ | | Yes | v _________________ / \ +-----------------+ / Credit counter \ No | | | >= |-------------> | Drop the packet | \ packet size? / | | \_________________/ +-----------------+ | | Yes | v +-----------------+ +-----------------+ | Reduce the | | Send the packet | | credit counter |---------------> | to the care-of | | by packet size | | address | +-----------------+ +-----------------+ Figure 3: Sending Packets with Credit-Based Authorization Arkko, et al. Expires March 29, 2007 [Page 21] Internet-Draft CGA and CBA for Mobile IPv6 September 2006 4.10 Credit Aging A correspondent node ensures that the credit counters it maintains for its mobile nodes gradually decrease over time. Such "credit aging" prevents a malicious node from building up credit at a very slow speed and using this, all at once, for a severe burst of redirected packets. Credit aging SHOULD be implemented by multiplying credit counters with a factor, CreditAgingFactor, less than one in fixed time intervals of CreditAgingInterval length. Choosing appropriate values for CreditAgingFactor and CreditAgingInterval is important to ensure that the correspondent node can send packets to an address in state UNVERIFIED even when the mobile node sends at a lower rate than the correspondent node itself. When CreditAgingFactor or CreditAgingInterval are too small, the mobile node's credit counter might be too low to continue sending packets until address verification concludes. The following values are used for the credit-aging parameters defined in this document: CreditAgingFactor 7/8 CreditAgingInterval 5 seconds Note: These parameter values work well when the correspondent node transfers a file to the mobile node via a TCP connection and the end- to-end round-trip time does not exeed 500 milliseconds. 4.11 Simultaneous Movements As specified in RFC 3775 [1], Mobility Header messages are generally sent via the mobile node's home agent and to the peer's home address, if it is also mobile. This makes it possible for two mobile nodes to communicate even if they are moving simultaneously. 5. Option Formats and Status Codes The protocol specified in this document introduces a set of new mobility options and status codes. These are described below. Arkko, et al. Expires March 29, 2007 [Page 22] Internet-Draft CGA and CBA for Mobile IPv6 September 2006 5.1 CGA Parameters Option Options of this type are used to carry the mobile node's public key and the parameters needed by the correspondent node to check the CGA property of the mobile node's home address. RFC 3775 [1] limits mobility header options to a maximum length of 255 bytes, excluding the Option Type and Option Length fields. For this reason, multiple options of this type are used to carry the all parameters, which are likely to exceed the limit specified in RFC 3775. The format of the CGA Parameters option is the following: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Option Type | Option Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | : : : CGA Parameters : : : | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Option Type Option Length Length of the option CGA Parameters This field contains up to 255 bytes of the string holding the mobile node's CGA public key and other CGA parameters in the format defined in [18]. The concatenation of all options of this type in the order they appear in the Binding Update message MUST result in the string defined in [18]. All options of this type carried in the Binding Update message except the last one MUST contain exactly 255 bytes in the Option Data field, and the Option Length field MUST be set to 255 accordingly. All options of this type MUST appear one after another, i.e., an option of a different type MUST NOT be placed in between two options of this type. Arkko, et al. Expires March 29, 2007 [Page 23] Internet-Draft CGA and CBA for Mobile IPv6 September 2006 5.2 Signature Option The mobile node MUST provide a signature generated with its private CGA key if it includes a CGA Parameters option in a Binding Update message. The signature MUST be inserted into a Signature option that follows the CGA Parameters option. The format of the Signature option is as follows: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Option Type | Option Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | : : : Signature : : : | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Option Type Option Length Length of the option Signature This field contains the signature generated as specified in Section 4.5. 5.3 Permanent Home Keygen Token Option A correspondent node MUST send a new permanent home keygen token to a mobile node each time it receives a Binding Update message containing the CGA Parameters option from the mobile node. The permanent home keygen token is carried in a Permanent Home Keygen Token option, which the correspondent node MUST insert in the Binding Acknowledgment message for the mobile node. The format of the Permanent Home Keygen Token option is as follows: Arkko, et al. Expires March 29, 2007 [Page 24] Internet-Draft CGA and CBA for Mobile IPv6 September 2006 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Option Type | Length = 16 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + Permanent Home Keygen Token + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Option Type Option Length Length of the option Permanent Home Keygen Token This field contains the permanent home keygen token generated by the correspondent node. The content of this field MUST be encrypted with the mobile node's public key as defined in Section 4.7. The length of the permanent home keygen token is 8 octets (before encryption or padding possibly involved [2]). 5.4 Care-of Test Init Option The Care-of Test Init option is included in a Binding Update message to request the correspondent node to return a Care-of Test option with a fresh care-of keygen token in the Binding Acknowledgment message. The format of the Care-of Test Init option is as follows: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Option Type | Option Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Arkko, et al. Expires March 29, 2007 [Page 25] Internet-Draft CGA and CBA for Mobile IPv6 September 2006 Option Type Option Length Length of the option 5.5 Care-of Test Option A correspondent node sends a Binding Acknowledgment message with a Care-of Test option when it receives a valid Binding Update message that includes a Care-of Test Init message. The Care-of Test message contains a fresh care-of keygen token. The format of the Care-of Test option is as follows: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Option Type | Option Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + Care-of Keygen Token + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Option Type Option Length Length of the option Care-of Keygen Token A care-of keygen token, generated as defined in RFC 3775. 5.6 Status Codes The protocol defined in this document uses the following new status code for Binding Acknowledgment messages: Arkko, et al. Expires March 29, 2007 [Page 26] Internet-Draft CGA and CBA for Mobile IPv6 September 2006 Permanent Home Keygen Token Unavailable () A correspondent node returns a Binding Acknowledgment message with this status code to a mobile node if it has received from the mobile node a Binding Update message that was authenticated through the CGA property of the mobile node's home address, but the correspondent node either does not have a Binding Cache entry for the mobile node, or the existing Binding Cache entry for the mobile node does not include a permanent home keygen token. A Binding Acknowledgment message with this status code allows the mobile node to quickly request a new permanent home keygen token from the correspondent node in case of state loss at the correspondent node. Standard Mobile IPv6 does not allow a correspondent node to send a negative Binding Acknowledgment message when the authenticator of a received Binding Update message turns out to be incorrect. This is likely to cause additional handoff latency because the mobile node can detect the problem only after the expiration of a retransmission timer. The mobile node is furthermore likely to assume packet loss and resend the incorrectly authenticated Binding Update message additional times. A negative Binding Acknowledgment message with the status code helps the mobile node to identify the underlying problem much more efficiently. Conflicting Permanent Home Keygen Token () A correspondent node returns a Binding Acknowledgment message with this status code to a mobile node if it has received from the mobile node a Binding Update message that was authenticated through verification of the mobile node's reachability at the home address and does not include a CGA Parameters option, but the correspondent node has a permanent home keygen token in its Binding Cache entry for the mobile node. The Binding Update message is processed further if it includes a CGA Parameters option. This is necessary to enable a mobile node to obtain a new permanent home keygent token from the correspondent node in case it has lost the existing one, for instance, due to a reboot. Whether the correspondent node accepts the Binding Update message in this case depends on the verification of the signature provided for the CGA parameters included in the message. 6. Security Considerations The protocol defined in this document makes the following conceptual Arkko, et al. Expires March 29, 2007 [Page 27] Internet-Draft CGA and CBA for Mobile IPv6 September 2006 changes to the base protocol specified in RFC 3775: o RFC 3775 uses periodic tests of a mobile node's reachability at the home address as a proof of home address ownership. This protocol uses an initial cryptographic home address ownership proof in combination with a verification of the mobile node's reachability at the home address in order to securely exchange a secret permanent home keygen token. The permanent home keygen token is used for cryptographic authentication of the mobile node during subsequent binding updates, so that these later binding updates can be securely bound to the initial home address ownership proof. No further, periodic reachability verification at the home address tests is performed. o RFC 3775 requires a mobile node to prove its reachability at a new care-of address when updating a binding at a correspondent node. This implies that the mobile node and the correspondent node must exchange Care-of Test Init and Care-of Test messages before the mobile node can initiate the binding update proper. This protocol allows the mobile node to initiate the binding update first and then follow up with a proof of reachability at the care-of address. Mobile and correspondent nodes can so resume communications early on after a handoff, while reachability verification proceeds concurrently. o The maximum binding lifetime for correspondent registrations is 7 minutes in RFC 3775. A mobile node must hence periodically refresh a correspondent registration in cases where it does not change IP connectivity for a while. This protocol increases the maximum binding lifetime to 24 hours, eliminating the need for periodic refreshes. The following subsections discuss the implications that these changes have on security. The discussion ought to be seen in context with the security considerations of [1], [18], and [8]. 6.1 Home Address Ownership The protocol defined in this document requires a mobile node to deliver a strong cryptographic proof that it is the owner of the home address it wishes to use. The proof requires knowledge of a private key for which the corresponding public key will, as an input to the CGA generation algorithm along with suitable other parameters, result in the desired home address. Spoofing another node's home or regular IPv6 address, so-called "IP address stealing" [8], hence requires an attacker to find a suitable public/private key pair in a brute-force manner. The effort for doing so successfully is very high [18]. Arkko, et al. Expires March 29, 2007 [Page 28] Internet-Draft CGA and CBA for Mobile IPv6 September 2006 This makes the attack, which would otherwise permit impersonation and denial of service, extremely unlikely. While the CGA generation algorithm cryptographically ties the interface identifier of the CGA to the prefix, the algorithm accepts any prefix and hence does not prevent a node from generating a CGA from a different network. As a consequence, the cryptographic property of a CGA does not guarantee that the alledged CGA owner is indeed reachable at the IP address. An attacker could in fact use its own public key to generate a CGA-based home address with an incorrect prefix, request a correspondent node to bind this to the attacker's true care-of address, request a stream of packets via the care-of address, and then let the binding expire. The result would be a "return-to-home flooding" [8] attack against the victim network for which the home address was generated. The protocol defined in this document performs a reachability test for the home address at the time the home address is first registered with the correspondent node. This precludes return-to-home flooding. During the initial registration, the correspondent node assigns the mobile node a permanent home keygen token for use during subsequent binding updates. The permanent home keygen token is a symmetric secret key that allows for computationally more efficient authentication than a reapplied public-key-based home address ownership proof. Authentication of the mobile node allows the correspondent node to securely bind a subsequent binding update back to the home address ownership proof and reachability verification performed during the first registration. The permanent home keygen token is never sent in plain text; it is encrypted with the mobile node's public key when initially assigned, and irreversibly hashed during subsequent binding updates. Both mobile and correspondent nodes can therefore trust that the permanent home keygen token is known to only itself and the mobile node. 6.2 Care-of Address Ownership A secure proof of home address ownership can mitigate the threat of IP address stealing, but a malicious node may still bind a correct home address to a false care-of address and thereby redirect packets, which would otherwise be delivered to the node itself, to a third party. Neglection to verify a given care-of address could therefore cause one or multiple correspondent nodes to unknowingly contribute to a "redirection-based flooding" [8] attack against a victim chosen by the attacker. A redirection-based flooding attack may target an entire network, rather than a single node, either by loading the network with Arkko, et al. Expires March 29, 2007 [Page 29] Internet-Draft CGA and CBA for Mobile IPv6 September 2006 packets, or by overwhelming a router or other critical network device further upstream. The attacker in this case directs the flooding packets against an arbitrary IP address matching a prefix of the victim network or, respectively, against the IP address of the network device in focus. An attack against a network potentially impacts a larger number of nodes than an attack against a specific node, although neighbors of a victim node on a broadcast link typically suffer the same damage as the victim itself. A common misconception is that a strong proof of home address ownership would mitigate the threat of redirection-based flooding and consequently eliminate the need for a verification of the care-of address. This notion may originate from the specification of a home registration in RFC 3775, which authenticates a mobile node based on an IPsec security association, but does not supplement this by an ownership proof of the care-of address. Yet the waiver for the care-of address test is in this case not justified by the fact that the home agent can securely verify the mobile node's home address ownership, or that the home registration is IPsec-protected. It is rather based a prerequired administrative relationship between the home agent and the mobile node that allows the home agent, first, to trust in the correctness of a mobile node's care-of address and, second, to quickly identify the mobile node should it still start behaving maliciously, e.g., due to compromise by malware. Section 15.3 in [1] and section 1.3.2 in [8] explain these prerequisites. Assuming trust and an administrative relationship between the mobile node and its home agent is viable given that the home agent is an integral part of the mobility services which the mobile node's user typically has subscribed to, has set up her- or himself, or is receiving based on a business relationship. A Mobile IPv6 extension [19] that leverages a shared authentication key, pre-configured on the mobile node and the correspondent node, preassumes the same relationship between the mobile node and a correspondent node. While this assumption limits the applicability of the protocol (section 2 of [19] acknowledges this), it permits omission of care-of address reachability verification as in the case of the home registration. The protocol defined in this document does not make assumptions on the relationship between mobile and correspondent nodes and thence applies to arbitrary scenarios. The implication of the lack of trust is that correspondent nodes must verify a mobile node's reachability at every new care-of address. Requiring mobile nodes to cryptographically generate care-of addresses would mitigate the threat of redirection-based flooding only marginally. While it would prevent an attacker from registering as its care-of address the IP address of a specific victim node, the attacker could still generate a new CGA-based care-of address with a Arkko, et al. Expires March 29, 2007 [Page 30] Internet-Draft CGA and CBA for Mobile IPv6 September 2006 prefix from the victim network. Directing a packet flood towards this care-of address would then not require any specific node to actually receive and process the packets, but it would impact an entire link or network and thus cause comparable damage. CGA-based care-of addresses are therefore little effective with respect to flooding protection, but would on the other hand require a computationally expensive, public-key-based ownership proof upon every binding update. The protocol described in this document uses regular IPv6 care-of addresses for these reasons. Concurrent verification of a mobile node's reachability at a new care-of address would in the absence of appropriate protection mechanisms re-introduce the threat of redirection-based flooding: An attacker could register a false care-of address, thereby trick its correspondent node into sending packets to a victim, delay the rechability verification process as much as possible, and finally register a different, possibly also spoofed care-of address. The attacker may in fact iterate through multiple incorrect care-of addresses which all route to the victim's link. Since even a legitimate mobile node may at times undergo two handoffs shortly after one another so that no time is left to finish reachability verification, it is in general impossible to decide at the correspondent node side whether a failed reachability verification is due to malicious intents or to other reasons. The protocol defined in this document uses Credit-Based Authorization to protect against misuse of concurrent reachability verification. Credit-Based Authorization does not prevent malicious packet redirection itself, but rather reduces the effectiveness of such an attack to that of a simple, direct flooding attack where the perpetrator itself sends packets to the victim. The ability to send unrequested packets is an inherent property of packet-oriented networks, and direct flooding is a threat that results from this. Since direct flooding exists with and without mobility support, it constitutes a reasonable measure in comparing the security provided by Credit-Based Authorization to the security of the non-mobile Internet. Through the use of Credit-Based Authorization, the protocol defined in this document hence satisfies the objective to provide a security level comparable to the non-mobile Internet. 6.3 Time Shifting Attacks RFC 3775 limits the lifetime of a correspondent registration to 7 minutes and so arranges that a mobile node's reachability at its home and care-of addresses is re-verified periodically. This ensures that the return routability procedure's vulnerability to eavesdropping cannot be exploited by an attacker which is only temporarily on the Arkko, et al. Expires March 29, 2007 [Page 31] Internet-Draft CGA and CBA for Mobile IPv6 September 2006 path between the correspondent node and the spoofed home or care-of address. Such "time shifting attacks" [8] could otherwise be misused for off-path IP address stealing, return-to-home flooding, or flooding of care-of addresses. The protocol defined in this document neither repeats the initial home address test nor any care-of address test in order to decrease handoff delays and signaling overhead. This does not limit the protocol's robustness to IP address stealing attacks because the protection of existing IP addresses solely rests on the required CGA- based ownership proof for home addresses, and it does not gain further strength through reachability testing. But the restriction to a single reachability test does facilitate time-shifted, off-path flooding attacks---either against home addresses with incorrect prefixes, or against spoofed care-of addresses---, if the perpetrator can interpose in the initial reachability test before it moves to a different location. The design choice against repeated IP address tests was made based on the observation that time shifting attacks are already an accepted threat in the non-mobile Internet of today. Specifically, an attacker can temporarily move onto the path between a victim and a correspondent node, request a stream of packets from the correspondent node on behalf of the victim, and then move to a different location. While a well-heeded responsibility of transport protocols and applications is to verify an initiator's IP address during connection establishment, subsequent verification typically takes place only by means of forgeable acknowledgments for received data. Participation in the initial handshake is then sufficient to spoof acknowledgments from an off-path position later on and thus feign continued presence at the victim's IP address. The threat of time shifting hence already applies to the non-mobile Internet. It should still be acknowledged that the time at which the mobility protocol verifies reachability of a home or care-of address may well antecede the establishment of any transport-layer connection. This gives an attacker more time to move away from the path between the correspondent node and the victim and so makes a time shifting attack more practicable. If the lack of periodic reachability verification is considered too risky, a correspondent node can enforce reruns of an home or care-of address test by limiting the registration lifetime or sending Binding Refresh Request messages to a mobile node. 6.4 Replay Attacks The protocol specified in this document relies on standard 16-bit Mobile IPv6 sequence numbers and periodic rekeying to avoid replay Arkko, et al. Expires March 29, 2007 [Page 32] Internet-Draft CGA and CBA for Mobile IPv6 September 2006 attacks. Rekeying allows the nodes to reuse sequence numbers without exposing themselves to replay attacks. Mobile and correspondent nodes rekey at least once every 24 hours due to the maximum permitted lifetime of a correspondent registration. The nodes also rekey whenever a rollover in sequence number space becomes imminent. This is unlikely to happen frequently, however, given that available sequence numbers are sufficient for up to 32768 binding updates, each consisting of an early and a full Binding Update message. The sequence number space thus permits an average rate of 22 binding updates per minute without exposing a need to rekey throughout the 24-hour registration lifetime. 6.5 Resource Exhaustion While a CGA-based home address ownership proof provides protection against unauthenticated Binding Update messages, it can expose the involved nodes to denial-of-service attacks since it requires computationally expensive public-key cryptography. The protocol defined in this document limits the use of public-key cryptography to only the first registration and if/when re-keying is needed. It is RECOMMENDED that nodes in addition track the amount of processing resources they spend on CGA-based home address ownership verification, and that they reject new requests when these resources exceed a predefined limit. [18] discusses the feasibility of CGA- based resource exhaustion attacks in depth. 6.6 IP Address Ownership of Correspondent Node The protocol defined in this document does not verify ownership of a correspondent node's IP address. A mobile node has hence no guarantee that a received permanent home keygen token indeed originates with the correspondent node. In particular, a man-in-the- middle attacker could interpose during the initial correspondent registration, pretend to be the correspondent node, and deliver its own permanent home keygen token to the mobile node. This attacker would have to be able to send both a Home Test message as well as a Binding Acknowledgment message on behalf of the correspondent node, and it may have to intercept the mobile node's Home Test Init and Binding Update messages. This potentially requires presence on separate paths. A successully spoofed inital registration would allow the attacker to impersonate the correspondent node also during subsequent binding updates of the mobile node, as long as it remains in a position to intercept and respond to the mobile node's Binding Update messages. The primary reason not to protect ownership of the correspondent Arkko, et al. Expires March 29, 2007 [Page 33] Internet-Draft CGA and CBA for Mobile IPv6 September 2006 node's IP address is that the threat emanating from a man in the middle on the path between two communicating nodes already exists in the non-mobile Internet. The threat can therefore more effectively be eliminated in a mobility-independent manner. This design choice also reduces the complexity of the protocol defined in this document and curtails the requirements imposed on the correspondent node. 7. Performance Considerations Performance of our protocol depends on whether we look at the initial or subsequent runs. The number of messages in the initial run is one less as in base Mobile IPv6, but the size of the messages is increased somewhat. On a mobile node that does not move that often, there is a significant signaling reduction, as the lifetimes can be set higher than in return routability. For instance, a mobile node that stays in the same address for a day will get a 99.52% signaling reduction. Such long lifetimes can be achieved immediately, as opposed to methods like [12] that grow them gradually. On a mobile node that moves fast, the per-movement signaling is reduced by 33%. Latency on the initial run is not affected, but on the subsequent movements there's a significant impact. This is because the home address test is eliminated. The exact effect depends on network topology, but if the home agent is far away and the correspondent node is on the same link, latency is almost completely eliminated. Additional latency and signaling improvements could be achieved through mechanisms that optimize the care-of address tests in some way. This is outside the scope of this document, however. 8. Protocol Constants The CGA specification defines a CGA Message Type name space from which CGA applications draw CGA Message Type tags to be used in signature calculations. This protocol uses a CGA Message Type tag of 0x5F27 0586 8D6C 4C56 A246 9EBB 9B2A 2E13. The tag value has been generated randomly. Arkko, et al. Expires March 29, 2007 [Page 34] Internet-Draft CGA and CBA for Mobile IPv6 September 2006 9. IANA Considerations This document defines a set of new mobility options, which must be assigned Option Type values within the mobility option numbering space of [1]. This document allocates two new status codes, "Permanent Home Keygen Token Unavailable" and "Conflicting Permanent Home Keygen Token", for Binding Acknowledgment messages. The value to be assigned for both status codes must be greater than or equal to 128, indicating that the respective Binding Update message was rejected by the receiving correspondent node. This document also defines a new 128-bit value under the CGA Message Type name space [18]. 10. Acknowledgment The authors would like to thank Pekka Nikander, Tuomas Aura, Greg O'Shea, Mike Roe, Gabriel Montenegro, Vesa Torvinen for interesting discussions around cryptographically generated addresses. The authors would also like to thank Vidya Narayanan and Lakshminath Dondeti for their reviews of and comments on this document, as well as Greg Daley, Samita Chakrabarti, Marcelo Bagnulo, Suresh Krishnan, Mohan Parthasarathy, Lila Madour, Francis Dupont, Roland Bless, Mark Doll, and Tobias Kuefner for their reviews of and comments on the predecessors of this document. Finally, the authors would also like to emphasize that [20] pioneered the use of cryptographically generated addresses in the context of Mobile IPv6 route optimization, and that this document consists largely of material from [21], [22], and [17] and the contributions of their authors. Arkko, et al. Expires March 29, 2007 [Page 35] Internet-Draft CGA and CBA for Mobile IPv6 September 2006 11. References 11.1 Normative References [1] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in IPv6", RFC 3775, June 2004. [2] Jonsson, J. and B. Kaliski, "Public-Key Cryptography Standards (PKCS) #1: RSA Cryptography Specifications Version 2.1", RFC 3447, February 2003. [3] International Telecommunications Union, "Information Technology - ASN.1 encoding rules: Specification of Basic Encoding Rules (BER), Canonical Encoding Rules (CER) and Distinguished Encoding Rules (DER)", ITU-T Recommendation X.690, July 2002. [4] 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. [5] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [6] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998. [7] Narten, T., Nordmark, E., and W. Simpson, "Neighbor Discovery for IP Version 6 (IPv6)", RFC 2461, December 1998. 11.2 Informative References [8] Nikander, P., Arkko, J., Aura, T., Montenegro, G., and E. Nordmark, "Mobile IP Version 6 Route Optimization Security Design Background", IETF Request for Comments 4225, December 2005. [9] Vogt, C. and J. Arkko, "Taxonomy and Analysis of Enhancements to Mobile IPv6 Route Optimization", IETF Internet Draft draft-irtf-mobopts-ro-enhancements-08.txt (work in progress), May 2006. [10] Vogt, C. and M. Doll, "Efficient End-to-End Mobility Support in IPv6", Proceedings of the IEEE Wireless Communications and Networking Conference, IEEE, April 2006. [11] Mirkovic, J. and P. Reiher, "A Taxonomy of DDoS Attack and DDoS Defense Mechanisms", ACM SIGCOMM Computer Communication Review, Vol. 34, No. 2, ACM Press, April 2004. Arkko, et al. Expires March 29, 2007 [Page 36] Internet-Draft CGA and CBA for Mobile IPv6 September 2006 [12] Arkko, J. and C. Vogt, "Credit-Based Authorization for Binding Lifetime Extension", draft-arkko-mipv6-binding-lifetime-extension-00 (work in progress), May 2004. [13] O'Shea, G. and M. Roe, "Child-Proof Authentication for MIPv6 (CAM)", ACM SIGCOMM Computer Communication Review, ACM Press, Vol. 31, No. 2, April 2001. [14] Nikander, P., "Denial-of-Service, Address Ownership, and Early Authentication in the IPv6 World", Revised papers from the International Workshop on Security Protocols, Springer-Verlag, April 2002. [15] Aura, T., "Cryptographically Generated Addresses (CGA)", IETF Request for Comments 3972, March 2005. [16] Haddad, W. and S. Krishnan, "Optimizing Mobile IPv6 (OMIPv6)", draft-haddad-mipv6-omipv6-01 (work in progress), February 2004. [17] Vogt, C., "Credit-Based Authorization for Mobile IPv6 Early Binding Updates", draft-vogt-mipv6-credit-based-authorization-00 (work in progress), May 2004. [18] Aura, T., "Cryptographically Generated Addresses (CGA)", draft-ietf-send-cga-06 (work in progress), April 2004. [19] Perkins, C., "Preconfigured Binding Management Keys for Mobile IPv6", draft-ietf-mip6-precfgKbm-00 (work in progress), April 2004. [20] Roe, M., "Authentication of Mobile IPv6 Binding Updates and Acknowledgments", draft-roe-mobileip-updateauth-02 (work in progress), March 2002. [21] Haddad, W., "Applying Cryptographically Generated Addresses to Optimize MIPv6 (CGA-OMIPv6)", draft-haddad-mip6-cga-omipv6-04 (work in progress), May 2005. [22] Vogt, C., "Early Binding Updates for Mobile IPv6", draft-vogt-mip6-early-binding-updates-00 (work in progress), February 2004. [23] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure Neighbor Discovery (SEND)", RFC 3971, March 2005. [24] Nikander, P., "Mobile IP version 6 Route Optimization Security Arkko, et al. Expires March 29, 2007 [Page 37] Internet-Draft CGA and CBA for Mobile IPv6 September 2006 Design Background", draft-ietf-mip6-ro-sec-03 (work in progress), May 2005. [25] Dupont, F. and J. Combes, "Using IPsec between Mobile and Correspondent IPv6 Nodes", draft-dupont-mipv6-cn-ipsec-01 (work in progress), June 2004. Authors' Addresses Jari Arkko Ericsson Research NomadicLab FI-02420 Jorvas Finland Email: jari.arkko@ericsson.com Christian Vogt Institute of Telematics Universitaet Karlsruhe (TH) P.O. Box 6980 76128 Karlsruhe Germany Email: chvogt@tm.uka.de Wassim Haddad Ericsson Research 8400, Decarie Blvd Town of Mount Royal Quebec H4P 2N2, Canada Email: wassim.haddad@ericsson.com Appendix A. Overview of CGA As described in [18], a Cryptographically Generated Address (CGA) is an IPv6 address, which contains a set of bits generated by hashing the IPv6 address owner's public key. Such feature allows the user to provide a "proof of ownership" of its IPv6 address. The CGA offers three main advantages: it makes the spoofing attack against the IPv6 address much harder and allows to sign messages with the owner's private key. CGA does not require any upgrade or Arkko, et al. Expires March 29, 2007 [Page 38] Internet-Draft CGA and CBA for Mobile IPv6 September 2006 modification in the infrastructure. The CGA offers a method for binding a public key to an IPv6 address. The binding between the public key and the address can be verified by re-computing and comparing the hash value of the public key and other parameters sent in the specific message with the interface identifier in the IPv6 address belonging to the owner. Note that an attacker can always create its own CGA address but he will not be able to spoof someone else's address since he needs to sign the message with the corresponding private key, which is supposed to be known only by the real owner. CGA assures that the interface identifier part of the address is correct, but does little to ensure that the node is actually reachable at that identifier and prefix. As a result, CGA needs to be employed together with a reachability test where redirection denial-of-service attacks are a concern. Each CGA is associated with a public key and auxiliary parameters. In this protocol, the public key MUST be formatted as a DER-encoded [3] ASN.1 structure of the type SubjectPublicKeyInfo defined in the Internet X.509 certificate profile [4]. The CGA verification takes as input an IPv6 address and auxiliary parameters. These parameters are the following: o a 128-bit modifier, which can be any value, o a 64-bit subnet prefix, which is equal to the subnet prefix of the CGA, o an 8-bit collision count, which can have values 0, 1 and 2. If the verification succeeds, the verifier knows that the public key in the CGA parameters is the authentic public key of the address owner. In order to sign a message, a node needs the CGA, the associated CGA parameters, the message and the private cryptographic key that corresponds to the public key in the CGA parameters. The node needs to use a 128 bit type tag for the message from the CGA Message Type name space. The type tag is an IANA-allocated 128 bit integer. To sign a message, a node performs the following two steps: 1. Concatenate the 128 bit type tag (in the network byte order) and message with the type tag to the left and message to the right. The concatenation is the message to be signed in the next step. Arkko, et al. Expires March 29, 2007 [Page 39] Internet-Draft CGA and CBA for Mobile IPv6 September 2006 2. Generate the RSA signature. The inputs to the generation procedure are the private key and the concatenation created in a). Appendix B. Overview of Credit-Based Authorization To prevent redirection-based flooding attacks, the easiest way would be not to use a new care-of address until it has been verified. This could proceed unnoticed when the mobile node can meanwhile communicate through a second interface. However, many situations are conceivable in which mobile nodes have a single interface only. The care-of-address test would increase signaling delays by one round- trip time in such cases. To avoid this additional delay, a new care-of address is used as soon as possible, and the correspondent node verifies the mobile node's reachability at that care-of address concurrently. Credit-Based Authorization for concurrent care-of- address tests prevents illegitimate packet redirection until the validity of the address has been established. This is accomplished based on the following three hypotheses: 1. A flooding attacker typically seeks to somehow multiply the packets it generates itself for the purpose of its attack because bandwidth is an ample resource for many attractive victims. 2. An attacker can always cause unamplified flooding by sending packets to its victim directly. 3. Consequently, the additional effort required to set up a redirection-based flooding attack would pay off for the attacker only if amplification could be obtained this way. On this basis, rather than eliminating malicious packet redirection in the first place, Credit-Based Authorization prevents any amplification that can be reached through it. This is accomplished by limiting the data a correspondent node can send to an unverified care-of address of a mobile node by the data recently received from that mobile node. Redirection-based flooding attacks thus become less attractive than, e.g., pure direct flooding, where the attacker itself sends bogus packets to the victim. Figure 10 illustrates Credit-Based Authorization: The correspondent node measures the bytes received from the mobile node. When the mobile node changes to a new care-of address, the correspondent node labels this address UNVERIFIED and sends packets there as long as the sum of the packet sizes does not exceed the measured, received data Arkko, et al. Expires March 29, 2007 [Page 40] Internet-Draft CGA and CBA for Mobile IPv6 September 2006 volume. The mobile node's reachability at the new care-of address meanwhile gets verified When the care-of-address test completes with success, the correspondent node relabels the care-of address from UNVERIFIED to VERIFIED. As of then, packets can be sent to the new care-of address without restrictions. When insufficient credit is left while the care-of address is still UNVERIFIED, the correspondent node stops sending further packets until address verification completes. +-------------+ +--------------------+ | Mobile Node | | Correspondent Node | +-------------+ +--------------------+ | | address |------------------------->| credit += size(packet) verified | | |------------------------->| credit += size(packet) |<-------------------------| don't change credit | | + address change | address |<-------------------------| credit -= size(packet) unverified|------------------------->| credit += size(packet) |<-------------------------| credit -= size(packet) | | |<-------------------------| credit -= size(packet) | X credit < size(packet) ==> drop | | + address change | address | | verified |<-------------------------| don't change credit | | Figure 10: Credit-Based Authorization The correspondent node ensures that the mobile node's acquired credit gradually decrease over time. Such "credit aging" prevents a malicious node from building up credit at a very slow speed and using this, all at once, for a severe burst of redirected packets. Appendix C. Change Log The following is a list of technical changes that were made from version 00 to version 01 of this document. Editorial revisions are not explicitly mentioned. Arkko, et al. Expires March 29, 2007 [Page 41] Internet-Draft CGA and CBA for Mobile IPv6 September 2006 o Revised Section 1 to reflect the comments from Vidya and Lakshminath. The text now makes it much clearer that there are two individual optimizations for home and care-of address verification. o Added Section 4.5 describing when the mobile node sends CGA parameters to the correspondent node and how the CGA Parameters and Signature options are used to accomplish this. o Added Section 4.6 describing the correspondent node's operation upon receiving a Binding Update message with included CGA Parameters and Signature options. o Added Section 4.7 describing how a correspondent node generates and encrypts a permanent home keygen token and sends the token in a Permanent Home Keygen Token option within a Binding Acknowledgment message to the mobile node. o Added Section 4.8 describing how a mobile node decrypts a permanent home keygen token received in a Binding Acknowledgment message with a Permanent Home Keygen Token option. o Removed Section "Renewing a Permanent Home Keygen Token" (formerly Section 4.7). The section described when the mobile node should renew an existing permanent home keygen token. This is now explained in Section 4.5. o Section 4.9 now also describes when mobile and correspondent nodes resume route-optimized payload transmission after handoff on the mobile node side. o Removed Section "Cryptographic Calculations" (formerly Section 4.10). The section described how the signature in a Signature option and the contents of the former SKey option are calculated. The signature calculation is now described in Section 4.5. The SKey option was replaced by the Permanent Home Keygen Token option, and the contents of this are now described in Section 4.7. o Cleaned up section Section 5. o Replaced status code "Lost Kbmperm State" in Section 5.6 with a new status code, "Permanent Home Keygen Token Unavailable". Added a second status code "Conflicting Permanent Home Keygen Token". Section 4 ("Protocol Operation") and Section 9 ("IANA Considerations") were modified accordingly. o Revised Section 6 so that it now addresses the comments made by Vidya and Lakshminath. In particular, the text now explains why a Arkko, et al. Expires March 29, 2007 [Page 42] Internet-Draft CGA and CBA for Mobile IPv6 September 2006 care-of address test is required in spite of the more secure, CGA- based home address verification. The section also starts with an overview of the conceptual changes that the proposed protocol applies to RFC 3775. o Added Section 8 defining the CGA Message Type tag to be allocated for this protocol. Arkko, et al. Expires March 29, 2007 [Page 43] Internet-Draft CGA and CBA for Mobile IPv6 September 2006 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. The IETF has been notified of intellectual property rights claimed in regard to some or all of the specification contained in this document. For more information consult the online list of claimed rights. Disclaimer of Validity This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Copyright Statement Copyright (C) The Internet Society (2006). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. Arkko, et al. Expires March 29, 2007 [Page 44] Internet-Draft CGA and CBA for Mobile IPv6 September 2006 Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Arkko, et al. Expires March 29, 2007 [Page 45]