Mobility Optimizations J. Arkko Internet-Draft Ericsson Research Expires: January 19, 2006 C. Vogt University of Karlsruhe W. Haddad Ericsson Research July 18, 2005 Applying Cryptographically Generated Addresses and Credit-Based Authorization to Optimize Mobile IPv6 (OMIPv6) draft-arkko-mipshop-cga-cba-01 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 January 19, 2006. Copyright Notice Copyright (C) The Internet Society (2005). Abstract This memo suggests a new and enhanced route optimization security mechanism for Mobile IPv6 (MIPv6). The primary motivation for this new mechanism is the reduction of signaling load and handoff delay. The performance improvement achieved is elimination of all signaling Arkko, et al. Expires January 19, 2006 [Page 1] Internet-Draft CGA and CBA for MIPv6 July 2005 while not moving, and most of the per-movement signaling can be done when payload traffic flow has already been moved. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Efficiency of Base Mobile IPv6 . . . . . . . . . . . . . . . 3 3. Overview of CGA . . . . . . . . . . . . . . . . . . . . . . 5 4. Overview of Credit-Based Authorization . . . . . . . . . . . 7 5. Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . 8 5.1 Requirements . . . . . . . . . . . . . . . . . . . . . . 8 5.2 Design Rationale . . . . . . . . . . . . . . . . . . . . 9 5.3 Overview of Signaling . . . . . . . . . . . . . . . . .10 5.4 Handling Payload Packets . . . . . . . . . . . . . . . .13 5.5 Credit Aging . . . . . . . . . . . . . . . . . . . . . .14 5.6 Cryptographic Calculations . . . . . . . . . . . . . . .15 5.7 Simultaneous Movements . . . . . . . . . . . . . . . . .16 6. Option Formats and Status Codes . . . . . . . . . . . . . . 16 6.1 The CGA Key Option . . . . . . . . . . . . . . . . . . .16 6.2 The Shared Key Option . . . . . . . . . . . . . . . . .17 6.3 The Extended Sequence Number Option . . . . . . . . . .17 6.4 The Signature (SIG) Option . . . . . . . . . . . . . . .18 6.5 The Care-of Test Init Option . . . . . . . . . . . . . .19 6.6 The Care-of Keygen Token Option . . . . . . . . . . . .19 6.7 Status Codes . . . . . . . . . . . . . . . . . . . . . .20 7. Security Considerations . . . . . . . . . . . . . . . . . . 20 8. Performance Considerations . . . . . . . . . . . . . . . . . 21 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . 22 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 22 10.1 Normative References . . . . . . . . . . . . . . . . .22 10.2 Informative References . . . . . . . . . . . . . . . .23 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 24 A. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 25 B. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 25 Intellectual Property and Copyright Statements . . . . . . . 26 Arkko, et al. Expires January 19, 2006 [Page 2] Internet-Draft CGA and CBA for MIPv6 July 2005 1. Introduction This document describes a new and enhanced route optimization (RO) security mechanism for Mobile IPv6 [6], based on providing a home address ownership proof via Cryptographically Generated Addresses (CGAs) [11]. This document uses also a new care-of address- verification procedure, Credit-Based Authorization (CBA) [20], to protect against redirection-based flooding attacks. The main goals of this protocol are the reduction of the signaling load and the handoff delay times. In addition, the protocol offers additional security benefits. This document is a complete specification of an optional, alternative mechanism to the standard scheme, and can be applied independently of other specifications. This rest of this document is structured as follows. Section 2 discusses the performance of the base Mobile IPv6 route optimization mechanisms, Section 3 introduces the concept of CGAs, and Section 4 explains how CBA operates. Section 5 gives an overview of our new mechanism and describes its design rationale. Section 6 describes detailed message formats. Finally, Section 7 and Section 8 analyze the security and performance properties of the mechanism. 2. Efficiency of Base Mobile IPv6 This section discusses the efficiency of the base Mobile IPv6 route optimization mechanisms defined in RFC [6]. Note that when evaluating the impact of signaling on performance, one should take into account the whole stack and not inspect just one layer or task. For instance, when a mobile node actually moves, the Mobile IPv6 signaling has to be compared to the link layer signaling, access control and authentication signaling, and IPv6 tasks such as router discovery, neighbor discovery, and duplicate address detection. Such other signaling introduces delays, in many cases significantly larger delays than exists in Mobile IPv6. In this document we ignore these other delays, however, and concentrate on making the mobility signaling as efficient as possible. But given this, an improvement of, say, 50% in mobility signaling may become just 10% unless other delays are also addressed. Other optimization work is ongoing in other parts of the stack, however. The performance of the base route optimization mechanism can be evaluated according to its impact on handover delay, the amount of bandwidth it uses per movement, the amount of bandwidth it uses when not moving, and the overhead it causes for payload traffic. These Arkko, et al. Expires January 19, 2006 [Page 3] Internet-Draft CGA and CBA for MIPv6 July 2005 are discussed in the following: Payload traffic overhead The primary reason for using route optimization is to avoid routing all traffic through a home agent. We assume that this benefit is significant, particularly when two mobile nodes communicate with each other. However, an overhead is associated both with packets sent via bidirectional tunneling (tunnel) and directly (options for carrying home addresses). A more detailed analysis of the benefits and drawbacks are outside the scope of this document, however, as we concentrate on the signaling aspects only. Latency Basic home registration introduces a latency of zero to one roundtrips before payload traffic can flow, depending on which direction of traffic is looked at and whether the mobile node chooses to wait for an acknowledgement. With route optimization, the combined latency is one to three roundtrips, depending again on the direction of packets and waiting for acknowledgements. More specifically, RFC 3775 allows mobile nodes to send data packets after having sent the home registration Binding Update message. (If the Binding Update message is lost or packets get reordered, the data packets can be lost as well. But this may happen in any case.) Home agents and correspondent nodes can start to send data packets once they have sent the Binding Acknowledgement. The overall latency until inbound traffic can start flow to the mobile is therefore at least 1.5 roundtrips. RFC 3775 assumes also that the home and care-of tests are run in parallel. Some implementations may perform poorly, however. We have seen implementations that do not run the home and care-of tests in parallel, resulting in an overall delay of 3.5 to 4 roundtrips. But even when parallelism is employed, the latency across the two different paths can be different. When two mobile nodes are located close to each other, the home test exchange typically takes longer than the rest of the messaging. Arkko, et al. Expires January 19, 2006 [Page 4] Internet-Draft CGA and CBA for MIPv6 July 2005 Bandwidth usage upon movement As discussed in [12], one full run of the return routability and binding update procedures is about 376 bytes. Assuming relatively infrequent movements, for instance, every half hour, this corresponds to about 1.7 bits/second average bandwidth usage. The situation changes when more frequent movements are assumed. Using a cell size of 100 meters and the speed of 120 km/h, there will be one movement every 3 seconds. This amounts to a constant route optimization-related signaling of about 1,000 bits/second. This can be compared to a highly compressed voice stream which typically have a rate about 10,000 to 30,000 bits/second. Bandwidth usage when not moving Base specification requires a periodic return routability test and the re-establishment of the binding at the correspondent node. This results in an average bandwidth of about 7 bits/second, if performed every seven minutes as required in RFC 3775. While this is an insignificant bandwidth for nodes that are actually communicating, it can still represent a burden for hosts that just have the bindings ready for a possible packet but are not currently communicating. This can be problematic for hosts in standby mode, for instance. In summary, setting up the route optimization requires some signaling and causes some latency. The latency issue is perhaps more critical than the amount of signaling. This is because internet-wide RTTs are typically much longer (some hundreds of milliseconds) than desired latencies for real-time applications such as voice over IP (tens of milliseconds). On the other hand, frequent signaling can also be a substantial burden on low-powered mobile nodes, particularly if they wish to stay in sleep mode for long periods of time. 3. Overview of CGA As described in [11], 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. Arkko, et al. Expires January 19, 2006 [Page 5] Internet-Draft CGA and CBA for MIPv6 July 2005 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. For OMIPv6, the public key MUST be formatted as a DER-encoded [7] 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. 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 January 19, 2006 [Page 6] Internet-Draft CGA and CBA for MIPv6 July 2005 4. 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 1 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 January 19, 2006 [Page 7] Internet-Draft CGA and CBA for MIPv6 July 2005 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 1: 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. 5. Protocol This section discusses first the requirements of the protocol and its design rationale. An overview of the signaling is given after this, followed by the rules regarding the cryptographic calculations and a discussion of behaviour during simultaneous movements of two mobile nodes. 5.1 Requirements The desired characteristics of the protocol involve as small latency as possible upon movements, and the avoidance of signaling for non- moving hosts. Other things being equal, a protocol which uses the smallest amount of bandwidth for signaling should be chosen. The security requirements for the protocol are discussed in more Arkko, et al. Expires January 19, 2006 [Page 8] Internet-Draft CGA and CBA for MIPv6 July 2005 depth below: o Attackers should not be able to redirect communication flows of legitimate hosts to themselves, at least not beyond what is already possible in plain IPv6. This requirement applies both to ongoing and future communication flows. o Attackers should not be able to redirect communication flows to third parties. Otherwise, denial-of-service vulnerabilities exist; while such vulnerabilities already exist in the current Internet, we would like to avoid amplification possibilities introduced through mobility mechanisms. Note that this requirement applies even to attackers who are themselves parties in a legitimate communication with another node. o Attackers should not be able to cause denial-of-service through the potentially expensive computations involved in the route optimization protocol itself. 5.2 Design Rationale The design of the protocol follows the same principles as in the original return routability protocol, but adds the following mechanisms in order to make it more efficient: CGA CGA provides more assurance about the correctness of claimed address than the pure use of routing paths. This makes it possible to have a significant decrease in the signaling frequency. In addition, the public keys used in the CGA technique allow certain data to be communicated privately between the nodes, which makes some of our other techniques possible. This technique is taken from appeared originally in [9] and in [8]. Semi-permanent security associations CGA alone is not very efficient, due to its reliance public key computations and its need for relatively long messages. We employ semi-permanent security associations, created with the help of the CGA public keys. After an initial CGA exchange, this makes Arkko, et al. Expires January 19, 2006 [Page 9] Internet-Draft CGA and CBA for MIPv6 July 2005 subsequent signaling efficient. This technique appeared originally in [15]. Minimal address testing CGA is unable to guarantee that a particular address is actually reachable at a given prefix. For this reason there is a need for both home and care-of address tests. However, due to the higher security of the CGA technique we can make these test much less frequent. The home address test is necessary, because otherwise a malicious mobile node could create a CGA for the victim network prefix, request a stream of packets to its current location from a public server, and then let the binding expire. The result would be a flooding attack against the victim network. In order to avoid this, we require an initial home address test at the same time as the CGA technique is applied. Signaling on subsequent movements does not need to repeat this test, however. This technique appeared originally in [15]. . CBA CBA allows payload traffic to flow before all signaling related to the movement has been completed. Extended Sequence Numbers In Secure Neighbor Discovery (SEND), CGA has been applied using time stamps. However, this requires that the mobile nodes have somewhat accurate clocks. In our application the concept of sequence numbers is more appropriate, although the base Mobile IPv6 sequence numbers have to be extended. Upon initial contact the mobile node may send its current sequence number value to the correspondent node, and the mobile is expected to increase this value on every new signaling message to avoid replay attacks. 5.3 Overview of Signaling The protocol consists of two individually applicable optimizations for the home and care-of address tests. The home address test optimization requires an additional initial establishment phase. For convenience, this overview shows both optimizations applied together. Arkko, et al. Expires January 19, 2006 [Page 10] Internet-Draft CGA and CBA for MIPv6 July 2005 The initial phase can be rerun at any time, if either node loses its state, but it should be rerun at least once every 24 hours. The following figure shows the signaling diagram for the initial contact. The options shown MUST be included in the messages, where conformance to this document is claimed. 1a. MN to CN (via HA): Home Address Test Init 1b. MN to CN (directly): Care-of Address Test Init 2a. CN to MN (via HA): Home Address Test 2b. CN to MN (directly): Care-of Address Test 3. MN to CN (directly): Binding Update + ESN + CGA Key + SIG + NI + BAD 4. CN to MN (directly): Binding Acknowledgment + ESN + SKey + BAD (The mobile node may start sending payload packets in parallel with Step 3. The correspondent node may start sending payload packets in parallel with Step 4.) Steps 1a, 1b, 2a, and 2b execute the standard return routability procedure from RFC 3775, ensuring that the home and care-of addresses are reachable. It is also needed in order to guard against CPU consumption attacks against CGA RSA computations. Steps 2a and 2b provide keygen tokens which are used to construct a Kbm according to the usual RFC 3775 rules. Step 3 is the usual Binding Update message including additional options for the mobile node's public key, signature, and extended sequence number. At the same time, these three options tell the correspondent node that the mobile node supports this optimization. The Binding Authorization Data option is calculated using the standard RFC 3775 rules. A correspondent node that does not implement the optimization will simply fallback to a regular route optimization mechanism. Otherwise, in Step 4, the correspondent node returns the semi- permanent security association key in the SKey option, encrypted with the mobile node's public key. It also returns the Extended Sequence Number option. As a result of the initial procedure, the following state has been established in both nodes: o A standard Binding Cache Entry with a care-of address in state VERIFIED. The lifetime of the binding is not as limited as it is in standard Mobile IPv6. The maximum allowed lifetime is 24 Arkko, et al. Expires January 19, 2006 [Page 11] Internet-Draft CGA and CBA for MIPv6 July 2005 hours. o The current extended sequence number value of the mobile node node. o A semi-permanent security association with a key, Kbmperm. o The public keys and other parameters (see [11]) associated with the addresses. Security-wise, we know that the parties own their addresses (via CGA), and we have some assurance that they are currently at the locations they claim to be (via address tests). The two endpoints MUST silently discard any Binding Update or Acknowledgement message not signed with the Kbmperm, or when the Extended Sequence Number or Mobile IPv6 sequence number values are incorrect. This is not done, however, for a valid Binding Update messages that contains a CGA Key option, as that is used to re-initialize the state. Note that the initial phase serves to bootstrap the optimizations described in this document, but is not optimized itself. When it is desired that the optimizations described in this document are immediately effective, the initial phase MAY be proactively performed, without having to perform it upon first movement and possibly causing delay for payload packet transmission. The following figure shows the signaling diagram for subsequent movements. 1. MN to CN (directly): Binding Update + CTI + ESN + BAD 2. CN to MN (directly): Binding Acknowledgment + CKGT + ESN + BAD 3. MN to CN (directly): Binding Update + ESN + BAD 4. CN to MN (directly): Binding Acknowledgment + ESN + BAD (The mobile node may start sending payload packets in parallel with step 1. The correspondent node may start sending payload packets, subject to credit limitations (cf. Section 5.4), in parallel with step 2. If no credit is available, the correspondent node may start sending payload packets in parallel with step 4.) Steps 1 through 2 implement an "early" Binding Update, where the Care-of Test Init (CTI) option instructs the correspondent node to re-direct the traffic to the mobile node's new care-of address. This request can be honored only if the mobile node has sufficient credit, however (cf. Section 5.4). The Binding Authorization Data option is calculated in these messages using the key Kbmperm. Arkko, et al. Expires January 19, 2006 [Page 12] Internet-Draft CGA and CBA for MIPv6 July 2005 Steps 1 and 2 have also another purpose, namely to request the correspondent node to send a care-of keygen token to the mobile node using the Care-of Keygen Token (CKGT) option. This provides the same functionality as separate Care-of Test Init and Care-of Test messages, but reduces the number of messages sent. Step 3 and 4 are the final Binding Update and Acknowledgement messages. They are authenticated via Kbmperm' defined as HMAC_SHA1(care-of keygen token | Kbmperm). The correspondent node MUST use the extended sequence number sent in the Binding Update message to prevent against replay attacks that use past Binding Update messages. Security-wise, at this point we know that we are still talking between the same nodes as during the initial contact, since the Kbmperm is not known to outsiders. We have also verified the care-of address, to prevent malicious packet redirection. 5.4 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 4 depicts the actions taken by the correspondent node when a packet is received. Figure 5 shows the decision chain in the event a packet is sent. Arkko, et al. Expires January 19, 2006 [Page 13] Internet-Draft CGA and CBA for MIPv6 July 2005 Inbound packet | | +-----------------+ +-----------------+ | | Increase the | | Deliver the | +-----> | credit counter |---------------> | packet to the | | by packet size | | application | +-----------------+ +-----------------+ Figure 4: 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 5: Sending Packets with Credit-Based Authorization 5.5 Credit Aging A correspondent node ensures that the credit counters it maintains Arkko, et al. Expires January 19, 2006 [Page 14] Internet-Draft CGA and CBA for MIPv6 July 2005 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. 5.6 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 [5] 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 [5]. Arkko, et al. Expires January 19, 2006 [Page 15] Internet-Draft CGA and CBA for MIPv6 July 2005 5.7 Simultaneous Movements As specified in RFC 3775 [6], 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. 6. Option Formats and Status Codes 6.1 The CGA Key Option This option is used to carry the mobile node's CGA public key and other parameters. It SHOULD be inserted in any Binding Update message sent by the mobile node and signed with its CGA corresponding private key. This option contains also all CGA parameters needed by the correspondent node to check the validity of the mobile node's CGA. 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 the mobile node's CGA public key and other parameters, in the format defined in [11]. Arkko, et al. Expires January 19, 2006 [Page 16] Internet-Draft CGA and CBA for MIPv6 July 2005 6.2 The Shared Key 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 5.6. The length of Kbmperm value is 20 octets (before encryption or padding possibly involved [5]). 6.3 The Extended Sequence Number Option The nodes MUST use the Extended Sequence Number option in all Binding Update and Acknowledgment messages The option format is as follows: Arkko, et al. Expires January 19, 2006 [Page 17] Internet-Draft CGA and CBA for MIPv6 July 2005 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + Extended Sequence Number + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Option Type . Option Length Length of the option = 8. Option Data A 64 bit unsigned integer, representing the extended sequence number value. The mobile node MUST increase this value every time it sends a new message to the correspondent node. The correspondent node MUST return the most recent value it has seen. 6.4 The Signature (SIG) 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. 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 . . . | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Arkko, et al. Expires January 19, 2006 [Page 18] Internet-Draft CGA and CBA for MIPv6 July 2005 Option Type . Option Length Length of the option. Option Data This field contains the signature of the MH message it is contained within. 6.5 The 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Option Type . Option Length Length of the option = 0. 6.6 The Care-of Keygen Token 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: Arkko, et al. Expires January 19, 2006 [Page 19] Internet-Draft CGA and CBA for MIPv6 July 2005 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. 6.7 Status Codes The following new Status codes are allocated: 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. 7. 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 Arkko, et al. Expires January 19, 2006 [Page 20] Internet-Draft CGA and CBA for MIPv6 July 2005 [11]. 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, 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 method specified in this document is secure against replay and flooding attacks, due to the introduction of the Extended Sequence Number option, the use of care-of address tests, and the use of an initial home address test. 8. 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. Arkko, et al. Expires January 19, 2006 [Page 21] Internet-Draft CGA and CBA for MIPv6 July 2005 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. 9. 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 [2]. 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 [11] 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 [6]. This document also allocates a new Status code value. 10. References 10.1 Normative References [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [2] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998. [3] Narten, T., Nordmark, E., and W. Simpson, "Neighbor Discovery for IP Version 6 (IPv6)", RFC 2461, December 1998. [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. Arkko, et al. Expires January 19, 2006 [Page 22] Internet-Draft CGA and CBA for MIPv6 July 2005 [5] Jonsson, J. and B. Kaliski, "Public-Key Cryptography Standards (PKCS) #1: RSA Cryptography Specifications Version 2.1", RFC 3447, February 2003. [6] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in IPv6", RFC 3775, June 2004. [7] 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. 10.2 Informative References [8] O'Shea, G. and M. Roe, "Child-proof Authentication for MIPv6", Computer Communications Review, April 2001. [9] Nikander, P., "Denial-of-Service, Address Ownership, and Early Authentication in the IPv6 World", Proceedings of the Cambridge Security Protocols Workshop, April 2001. [10] Nikander, P., "Mobile IP version 6 Route Optimization Security Design Background", draft-ietf-mip6-ro-sec-00 (work in progress), April 2004. [11] Aura, T., "Cryptographically Generated Addresses (CGA)", draft-ietf-send-cga-04 (work in progress), December 2003. [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] Dupont, F. and J. Combes, "Using IPsec between Mobile and Correspondent IPv6 Nodes", draft-dupont-mipv6-cn-ipsec-00 (work in progress), April 2004. [14] Haddad, W., Madour, L., Arkko, J., and F. Dupont, "Applying Cryptographically Generated Addresses to OMIPv6 (OMIPv6+)", draft-haddad-mip6-cga-omipv6-00 (work in progress), April 2004. [15] Haddad, W. and S. Krishnan, "Optimizing Mobile IPv6 (OMIPv6)", draft-haddad-mipv6-omipv6-01 (work in progress), February 2004. [16] Haddad, W., "Applying Cryptographically Generated Addresses to BUB (BUB+)", draft-haddad-mip6-cga-bub-00 (work in progress), May 2004. Arkko, et al. Expires January 19, 2006 [Page 23] Internet-Draft CGA and CBA for MIPv6 July 2005 [17] Haddad, W., "BUB: Binding Update Backhauling", draft-haddad-mipv6-bub-01 (work in progress), February 2004. [18] Roe, M., "Authentication of Mobile IPv6 Binding Updates and Acknowledgments", draft-roe-mobileip-updateauth-02 (work in progress), March 2002. [19] Vogt, C., Bless, R., Doll, M., and T. Kuefner, "Early Binding Updates for Mobile IPv6", draft-vogt-mip6-early-binding-updates-00 (work in progress), February 2004. [20] Vogt, C., Arkko, J., Bless, R., Doll, M., and T. Kuefner, "Credit-Based Authorization for Mobile IPv6 Early Binding Updates", draft-vogt-mipv6-credit-based-authorization-00 (work in progress), May 2004. [21] 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 FI-02420 Jorvas Finland Email: jari.arkko@ericsson.com Christian Vogt Institute of Telematics University of Karlsruhe (TH) P.O. Box 6980 76128 Karlsruhe Germany Phone: +49-721-608-8282 Fax: +49-721-388-097 Email: chvogt@tm.uka.de URI: http://www.tm.uka.de/~chvogt/ Arkko, et al. Expires January 19, 2006 [Page 24] Internet-Draft CGA and CBA for MIPv6 July 2005 Wassim Haddad Ericsson Research 8400, Decarie Blvd Town of Mount Royal Quebec H4P 2N2, Canada Email: wassim.haddad@ericsson.com Appendix A. Contributors The authors would like to acknowledge that this document consists largely of material from [14] and [20] and the contributions of their authors, including Lila Madour, Francis Dupont, Roland Bless, Mark Doll and Tobias Kuefner. Appendix B. Acknowledgments The authors would like to thank Pekka Nikander, Tuomas Aura, Greg O'Shea, Mike Roe, Gabriel Montenegro, and Vesa Torvinen for interesting discussions around CGA. The authors would also like to acknowledge that [18] pioneered the work in the use of CGA for Mobile IPv6. Finally, we would like to thank Greg Daley, Samita Chakrabarti, Marcelo Bagnulo, Suresh Krishnan and Mohan Parthasarathy for their review and comments on earlier versions of this document. Arkko, et al. Expires January 19, 2006 [Page 25] Internet-Draft CGA and CBA for MIPv6 July 2005 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. 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 (2005). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. Arkko, et al. Expires January 19, 2006 [Page 26] Internet-Draft CGA and CBA for MIPv6 July 2005 Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Arkko, et al. Expires January 19, 2006 [Page 27]