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