Network Working Group J. Arkko Internet-Draft Ericsson Research NomadicLab Expires: December 25, 2006 C. Vogt Universitaet Karlsruhe (TH) W. Haddad Ericsson Research June 23, 2006 Applying Cryptographically Generated Addresses and Credit-Based Authorization to Mobile IPv6 draft-arkko-mipshop-cga-cba-04.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 December 25, 2006. 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 December 25, 2006 [Page 1] Internet-Draft CGA and CBA for Mobile IPv6 June 2006 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Objectives . . . . . . . . . . . . . . . . . . . . . . . . . 3 2.1 Handoff Latency . . . . . . . . . . . . . . . . . . . . . 4 2.2 Security . . . . . . . . . . . . . . . . . . . . . . . . . 5 2.3 Signaling Overhead . . . . . . . . . . . . . . . . . . . . 6 3. Protocol Design . . . . . . . . . . . . . . . . . . . . . . 6 4. Protocol Operation . . . . . . . . . . . . . . . . . . . . . 9 4.1 Sending Binding Update messages . . . . . . . . . . . . . 9 4.2 Receiving Binding Update messages . . . . . . . . . . . . 12 4.3 Sending Binding Acknowledgment messages . . . . . . . . . 14 4.4 Receiving Binding Acknowledgment messages . . . . . . . . 15 4.5 Sending CGA Parameters . . . . . . . . . . . . . . . . . . 15 4.6 Receiving CGA Parameters . . . . . . . . . . . . . . . . . 15 4.7 Renewing a Permanent Home Keygen Token . . . . . . . . . . 15 4.8 Handling Payload Packets . . . . . . . . . . . . . . . . . 16 4.9 Credit Aging . . . . . . . . . . . . . . . . . . . . . . . 17 4.10 Cryptographic Calculations . . . . . . . . . . . . . . . 18 4.11 Simultaneous Movements . . . . . . . . . . . . . . . . . 18 5. Option Formats and Status Codes . . . . . . . . . . . . . . 19 5.1 CGA Parameters Option . . . . . . . . . . . . . . . . . . 19 5.2 Permanent Home Keygen Token Option . . . . . . . . . . . . 20 5.3 Signature Option . . . . . . . . . . . . . . . . . . . . . 20 5.4 Care-of Test Init Option . . . . . . . . . . . . . . . . . 21 5.5 Care-of Test Option . . . . . . . . . . . . . . . . . . . 22 5.6 Status Codes . . . . . . . . . . . . . . . . . . . . . . . 22 6. Security Considerations . . . . . . . . . . . . . . . . . . 23 7. Performance Considerations . . . . . . . . . . . . . . . . . 24 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . 25 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 25 9.1 Normative References . . . . . . . . . . . . . . . . . . . 25 9.2 Informative References . . . . . . . . . . . . . . . . . . 26 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 27 A. Acknowledgment . . . . . . . . . . . . . . . . . . . . . . . 28 B. Overview of CGA . . . . . . . . . . . . . . . . . . . . . . 28 C. Overview of Credit-Based Authorization . . . . . . . . . . . 30 Intellectual Property and Copyright Statements . . . . . . . 32 Arkko, et al. Expires December 25, 2006 [Page 2] Internet-Draft CGA and CBA for Mobile IPv6 June 2006 1. Introduction Mobile IPv6 [1] includes a mode for route optimization that allows nodes to communicate with reduced latency via a direct routing path. Route optimization is protected through a "return routability procedure", which serves essentially two purposes: o A correspondent node can (weakly) authenticate a mobile node based on a verification of the mobile node's reachability at its home address. o A correspondent node can verify that the mobile node is reachable at the claimed care-of address. While authentication prevents impersonation threats, the reachability verification for the care-of address protects against "redirection- based flooding attacks" [8]. Standard route optimization is limited by the capabilities of the return routability procedure. For one thing, the procedure does not protect against an impersonator on the path between the mobile node's home agent and the correspondent node. This vulnerability may oftentimes be acceptable, given that it already exists in the non- mobile Internet of today. But scenarios with higher security needs are also conceivable. Second, the return routability procedure consumes a significant of the overall handoff delay. Since route optimization was orignally developed with an intent to improve support for interactive real-time applications, it is exactly those applications that suffer from prolonged handoff delays. This document amends the Mobile IPv6 base specification by two optional, interrelated, yet orthogonal optimizations to the return routability procedure. The first optimization enables unidirectional or mutual authentication based on a cryptographically generated home address [9]. This replaces the weaker authentication through pure reachability verification at a home address. The second optimization allows a correspondent node to securely verify a mobile node's reachability at a new care-of address while it already sends data packets to that care-of address [10]. The two optimizations 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 Arkko, et al. Expires December 25, 2006 [Page 3] Internet-Draft CGA and CBA for Mobile IPv6 June 2006 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. 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 [11]. 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. Arkko, et al. Expires December 25, 2006 [Page 4] Internet-Draft CGA and CBA for Mobile IPv6 June 2006 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. 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 [12]. 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 [13] 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. Arkko, et al. Expires December 25, 2006 [Page 5] Internet-Draft CGA and CBA for Mobile IPv6 June 2006 2.3 Signaling Overhead A complete correspondent registration involves 6 message transmissions at the mobile node, totaling about 376 bytes (cf. [14]). 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. 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 [14]. 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 Arkko, et al. Expires December 25, 2006 [Page 6] Internet-Draft CGA and CBA for Mobile IPv6 June 2006 this document features this through the application of cryptographically generated home addresses [15][16]. In general, a cryptographically generated address [9] 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 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 [17]. 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- Arkko, et al. Expires December 25, 2006 [Page 7] Internet-Draft CGA and CBA for Mobile IPv6 June 2006 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 [17]. 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 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 [10] 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. Arkko, et al. Expires December 25, 2006 [Page 8] Internet-Draft CGA and CBA for Mobile IPv6 June 2006 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 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.7). 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. Arkko, et al. Expires December 25, 2006 [Page 9] Internet-Draft CGA and CBA for Mobile IPv6 June 2006 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 addess 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.3). 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 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.7). 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: Arkko, et al. Expires December 25, 2006 [Page 10] Internet-Draft CGA and CBA for Mobile IPv6 June 2006 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 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. Arkko, et al. Expires December 25, 2006 [Page 11] Internet-Draft CGA and CBA for Mobile IPv6 June 2006 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 options 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. 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 Arkko, et al. Expires December 25, 2006 [Page 12] Internet-Draft CGA and CBA for Mobile IPv6 June 2006 authenticator of the Binding Update message. If the correspondent node does not have a permanent home keygen token for the mobile node in its Binding Cache, the correspondent node MUST reject the Binding Update message. 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 message. In case the correspondent node does have a permanent home keygen token in its Binding Cache entry for the mobile node, it MUST reject the Binding Update message. This is necessary to ensure that an attacker cannot bid down the authentication method to hijack a mobile node's legitimate binding. 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 rules described in [1]. 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 Arkko, et al. Expires December 25, 2006 [Page 13] Internet-Draft CGA and CBA for Mobile IPv6 June 2006 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 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 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. Arkko, et al. Expires December 25, 2006 [Page 14] Internet-Draft CGA and CBA for Mobile IPv6 June 2006 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 TBD. 4.6 Receiving CGA Parameters TBD. 4.7 Renewing a Permanent Home Keygen Token A mobile node MAY request a correspondent node to renew an existing Arkko, et al. Expires December 25, 2006 [Page 15] Internet-Draft CGA and CBA for Mobile IPv6 June 2006 permanent home kegen token at any time, but it MUST do so in the imminent event of a sequence number rollover, or when the lifetime of the binding at the correspondent node is about to expire. 4.8 Handling Payload Packets A 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 to a VERIFIED care-of address of that mobile node. Figure 1 depicts the actions taken by the correspondent node when a packet is received. Figure 2 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 1: Receiving Packets with Credit-Based Authorization Arkko, et al. Expires December 25, 2006 [Page 16] Internet-Draft CGA and CBA for Mobile IPv6 June 2006 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 2: Sending Packets with Credit-Based Authorization 4.9 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 Arkko, et al. Expires December 25, 2006 [Page 17] Internet-Draft CGA and CBA for Mobile IPv6 June 2006 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.10 Cryptographic Calculations The Signature option is calculated with the mobile node's private key over the following sequence of octets: Mobility Data = care-of address | correspondent | MH Data Where | denotes concatenation and "correspondent" is the correspondent node's IPv6 address. Note that in case the correspondent node is mobile, correspondent refers to the correspondent node's home address. MH Data is the content of the mobility message including the MH header. The Authenticator within the Binding Authorization Data option is zeroed for purposes of calculating the signature. The RSA signature is generated by using the RSASSA-PKCS1-v1_5 [2] signature algorithm with the SHA-1 hash algorithm. When the SKey option is used, the correspondent node MUST encrypt the Kbm with the MN's public key using the RSAES-PKCS1-v1_5 format [2]. 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. Arkko, et al. Expires December 25, 2006 [Page 18] Internet-Draft CGA and CBA for Mobile IPv6 June 2006 5. Option Formats and Status Codes 5.1 CGA Parameters Option Options of this type are used to carry the mobile node's public key and the CGA parameters needed by the correspondent node to check the validity of the mobile node's CGA. 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 entire CGA information, which is likely to exceed the limit specified in RFC 3775. The format of the 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. Option Data 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 December 25, 2006 [Page 19] Internet-Draft CGA and CBA for Mobile IPv6 June 2006 5.2 Permanent Home Keygen Token Option As it has been mentioned above, the correspondent node MUST send a new Kbm each time it receives a Binding Update message containing the CGA Parameter option. For this purpose, this proposal uses a new option called SKey option, which MUST be inserted in the Binding Acknowledgment message. The format of the 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 | Length = 16 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + Semi-Permanent Key for Binding Management (Kbmperm) + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Option Type . Option Length Length of the option. Option Data This field contains the Kbmperm value. Note that the content of this field MUST be encrypted with the mobile node's public key as defined in Section 4.10. The length of Kbmperm value is 20 octets (before encryption or padding possibly involved [2]). 5.3 Signature Option When the mobile node signs the Binding Update message with its CGA private key, it MUST insert the signature in the SIG option. Such scenario occurs when the mobile node sends its first Binding Update message to the correspondent node and if the mobile node reboots during an ongoing session. Arkko, et al. Expires December 25, 2006 [Page 20] Internet-Draft CGA and CBA for Mobile IPv6 June 2006 The option format 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. Option Data This field contains the signature of the MH message it is contained within. 5.4 Care-of Test Init Option A mobile node that wishes to employ the care-of address test optimization MAY employ this option in Binding Update message sent to a correspondent node in which it has previously established a Binding Cache entry. When received by such a correspondent node, it SHOULD return a Care-of Keygen Token option in the Binding Acknowledgement message. The option format 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 December 25, 2006 [Page 21] Internet-Draft CGA and CBA for Mobile IPv6 June 2006 Option Type . Option Length Length of the option = 0. 5.5 Care-of Test Option This option is returned by a correspondent node upon seeing a Care-of Test Init option in a Binding Update. The option format 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 = 8. Care-of Keygen Token A care-of keygen token, calculated as in RFC 3775. 5.6 Status Codes The following new Status codes are allocated: Arkko, et al. Expires December 25, 2006 [Page 22] Internet-Draft CGA and CBA for Mobile IPv6 June 2006 Lost Kbmperm State () This code is returned when the correspondent node does not have a Binding Cache Entry, Kbmperm, or has an invalid Binding Authorization Data option. The code MUST only be used in to respond to Binding Updates that contain one of the mobility options defined in this document. 6. Security Considerations This draft describes a method to exploit the CGA features in order to authenticate route optimization signaling. In fact, the CGA replaces the authentication by providing a proof of ownership while the RR procedure replaces the authentication by a routing property. This proof of ownership ensures that only the mobile node will be able to change the routing of packets destined to it, modulo exhaustive attacks on the CGA mechanism itself. The feasibility of such attacks and the defenses against them have been discussed in [18]. Note that, as specified, the proof of ownership protection applies only to the correspondent node believing the statements made by the mobile node. There is no guarantee that the answers from the correspondent node truly come from that correspondent node and not from someone who was on the path to the correspondent node during the initial contact phase. This is because we do not require correspondent nodes to have CGAs, and as a result, they can not make any statements that are authenticated in the strong sense. We chose not to protect against this, because this attack is something that already exists in plain IPv6, as is explained in the following. Lets assume that the correspondent node does not care about the IP address of the peers contacting it and that it does not protect its payload packets cryptographically. Then, a man-in-the-middle can always use its own address when communicating to the correspondent node, and the correspondent node's address when communicating to the mobile node. Philosophically, one can also argue that since the problem we attempt to solve here is routing modifications for the mobile node's address, it is sufficient to ensure that these modifications are protected. It should be mentioned that while the CGA can provide a protection against unauthenticated Binding Update messages, it can expose the involved nodes to denial-of-service attacks since it is computationally expensive. The draft limits the use of CGA to only the first registration and if/when re-keying is needed. In addition, Arkko, et al. Expires December 25, 2006 [Page 23] Internet-Draft CGA and CBA for Mobile IPv6 June 2006 it is RECOMMENDED that nodes track the amount of resources spent to the CGA processing, and disable the processing of new requests when these resources exceed a predefined limit. The protocol specified in this document relies on standard 16-bit Mobile IPv6 sequence numbers and periodic rekeying to avoid replay attacks. Nodes rekey at least once every 24 hours. Nodes also rekey whenever a rollover in the available sequence-number space becomes imminent. Rekeying allows the nodes to reuse sequence numbers without exposing themselves to replay attacks. This protocol is secure against flooding attacks due to the use of care-of-address tests, Credit-Based Authorization, and the use of an initial home address test. 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 [14] 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. Arkko, et al. Expires December 25, 2006 [Page 24] Internet-Draft CGA and CBA for Mobile IPv6 June 2006 8. IANA Considerations This document defines a new CGA Message Type name space for use as type tags in messages that may be signed using CGA signatures. The values in this name space are 128-bit unsigned integers. Values in this name space are allocated on a First Come First Served basis [3]. IANA assigns new 128-bit values directly without a review. CGA Message Type values for private use MAY be generated with a strong random-number generator without IANA allocation. This document defines a new 128-bit value under the CGA Message Type [18] namespace, 0x5F27 0586 8D6C 4C56 A246 9EBB 9B2A 2E13. 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 also allocates a new Status code value. 9. References 9.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] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998. [4] 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. [5] 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. [6] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [7] Narten, T., Nordmark, E., and W. Simpson, "Neighbor Discovery for IP Version 6 (IPv6)", RFC 2461, December 1998. Arkko, et al. Expires December 25, 2006 [Page 25] Internet-Draft CGA and CBA for Mobile IPv6 June 2006 9.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] Aura, T., "Cryptographically Generated Addresses (CGA)", IETF Request for Comments 3972, March 2005. [10] Vogt, C., "Credit-Based Authorization for Mobile IPv6 Early Binding Updates", draft-vogt-mipv6-credit-based-authorization-00 (work in progress), May 2004. [11] 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. [12] 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. [13] 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. [14] Arkko, J. and C. Vogt, "Credit-Based Authorization for Binding Lifetime Extension", draft-arkko-mipv6-binding-lifetime-extension-00 (work in progress), May 2004. [15] 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. [16] 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. [17] Haddad, W. and S. Krishnan, "Optimizing Mobile IPv6 (OMIPv6)", draft-haddad-mipv6-omipv6-01 (work in progress), February 2004. [18] Aura, T., "Cryptographically Generated Addresses (CGA)", draft-ietf-send-cga-06 (work in progress), April 2004. Arkko, et al. Expires December 25, 2006 [Page 26] Internet-Draft CGA and CBA for Mobile IPv6 June 2006 [19] Roe, M., "Authentication of Mobile IPv6 Binding Updates and Acknowledgments", draft-roe-mobileip-updateauth-02 (work in progress), March 2002. [20] Haddad, W., "Applying Cryptographically Generated Addresses to Optimize MIPv6 (CGA-OMIPv6)", draft-haddad-mip6-cga-omipv6-04 (work in progress), May 2005. [21] Vogt, C., "Early Binding Updates for Mobile IPv6", draft-vogt-mip6-early-binding-updates-00 (work in progress), February 2004. [22] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure Neighbor Discovery (SEND)", RFC 3971, March 2005. [23] Nikander, P., "Mobile IP version 6 Route Optimization Security Design Background", draft-ietf-mip6-ro-sec-03 (work in progress), May 2005. [24] Dupont, F. and J. Combes, "Using IPsec between Mobile and Correspondent IPv6 Nodes", draft-dupont-mipv6-cn-ipsec-01 (work in progress), June 2004. [25] Perkins, C., "Preconfigured Binding Management Keys for Mobile IPv6", draft-ietf-mip6-precfgKbm-00 (work in progress), April 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 Arkko, et al. Expires December 25, 2006 [Page 27] Internet-Draft CGA and CBA for Mobile IPv6 June 2006 Wassim Haddad Ericsson Research 8400, Decarie Blvd Town of Mount Royal Quebec H4P 2N2, Canada Email: wassim.haddad@ericsson.com Appendix A. 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 Greg Daley, Samita Chakrabarti, Marcelo Bagnulo, Suresh Krishnan, Mohan Parthasarathy, Lila Madour, Francis Dupont, Roland Bless, Mark Doll, and Tobias Kuefner for their review and comments on the predecessors of this document. Finally, the authors would also like to emphasize that [19] pioneered the use of cryptographically generated addresses in the context of Mobile IPv6 route optimization, and that this document consists largely of material from [20], [21], and [10] and the contributions of their authors. Appendix B. 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 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 Arkko, et al. Expires December 25, 2006 [Page 28] Internet-Draft CGA and CBA for Mobile IPv6 June 2006 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 [4] ASN.1 structure of the type SubjectPublicKeyInfo defined in the Internet X.509 certificate profile [5]. 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. 2. Generate the RSA signature. The inputs to the generation procedure are the private key and the concatenation created in a). Arkko, et al. Expires December 25, 2006 [Page 29] Internet-Draft CGA and CBA for Mobile IPv6 June 2006 Appendix C. 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 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 Arkko, et al. Expires December 25, 2006 [Page 30] Internet-Draft CGA and CBA for Mobile IPv6 June 2006 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. Arkko, et al. Expires December 25, 2006 [Page 31] Internet-Draft CGA and CBA for Mobile IPv6 June 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 December 25, 2006 [Page 32] Internet-Draft CGA and CBA for Mobile IPv6 June 2006 Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Arkko, et al. Expires December 25, 2006 [Page 33]