Mobility Optimizations J. Arkko
Internet-Draft Ericsson Research
Expires: January 12, 2006 C. Vogt
University of Karlsruhe
W. Haddad
Ericsson Research
July 11, 2005
Applying Cryptographically Generated Addresses and Credit-Based
Authorization to Optimize Mobile IPv6 (OMIPv6)
draft-arkko-mipshop-cga-cba-00
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 12, 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 12, 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 12, 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 12, 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 12, 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 12, 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 12, 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 get verified concurrently. 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
Arkko, et al. Expires January 12, 2006 [Page 7]
Internet-Draft CGA and CBA for MIPv6 July 2005
verification completes.
+-------------+ +--------------------+
| Mobile Node | | Correspondent Node |
+-------------+ +--------------------+
| |
address |------------------------->| credit += size(packet)
verified | |
|------------------------->| credit += size(packet)
|<-------------------------| don't change credit
| |
+ address change |
address |<-------------------------| credit -= size(packet)
unverified|------------------------->| credit += size(packet)
|<-------------------------| credit -= size(packet)
| |
|<-------------------------| credit -= size(packet)
| X credit < size(packet) ==> drop
| |
+ address change |
address | |
verified |<-------------------------| don't change credit
| |
Figure 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 12, 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 12, 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 12, 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 12, 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 12, 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 12, 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 12, 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 12, 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
<To Be Assigned By IANA>.
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 12, 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
<To Be Assigned By IANA>.
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 12, 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
<To Be Assigned By IANA>.
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 12, 2006 [Page 18]
Internet-Draft CGA and CBA for MIPv6 July 2005
Option Type
<To Be Assigned By IANA>.
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
<To Be Assigned By IANA>.
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 12, 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
<To Be Assigned By IANA>.
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 (<To Be Allocated By IANA>)
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 12, 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 12, 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 12, 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 12, 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 12, 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 12, 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 12, 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 12, 2006 [Page 27]