Network Working Group C. Vogt
Internet-Draft University of Karlsruhe
Expires: November 19, 2004 J. Arkko
Ericsson Research NomadicLab
R. Bless
M. Doll
T. Kuefner
University of Karlsruhe
May 21, 2004
Credit-Based Authorization for Mobile IPv6 Early Binding Updates
draft-vogt-mipv6-credit-based-authorization-00
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026.
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 November 19, 2004.
Copyright Notice
Copyright (C) The Internet Society (2004). All Rights Reserved.
Abstract
The latency associated with Mobile IPv6's Return Routability test can
have an adverse impact on delay-sensitive applications. Early
Binding Updates mitigate this issue by already using a new care-of
address in parallel with testing it. We propose and analyze a
credit-based mechanism that prevents misuse of Early Binding Updates
for amplified flooding attacks and discourages such misuse for
non-amplified flooding attacks.
Vogt, et al. Expires November 19, 2004 [Page 1]
Internet-Draft Credit-Based Authorization May 2004
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Flooding Attacks . . . . . . . . . . . . . . . . . . . . . . . 6
4. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
4.1 Early Binding Updates . . . . . . . . . . . . . . . . . . 8
4.2 Credit-Based Authorization . . . . . . . . . . . . . . . . 10
4.3 Variants of Credit-Based Authorization . . . . . . . . . . 11
5. Detailed Description . . . . . . . . . . . . . . . . . . . . . 13
5.1 State at the Correspondent Node . . . . . . . . . . . . . 13
5.2 Exponential Aging . . . . . . . . . . . . . . . . . . . . 15
5.3 Sending Packets to a Mobile Node . . . . . . . . . . . . . 16
5.4 Receiving Packets from a Mobile Node . . . . . . . . . . . 18
5.5 Handling Clock Ticks . . . . . . . . . . . . . . . . . . . 19
6. Care-of-Address Spot Checks . . . . . . . . . . . . . . . . . 20
6.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . 20
6.2 Overview . . . . . . . . . . . . . . . . . . . . . . . . . 22
6.3 Generating Random Strings . . . . . . . . . . . . . . . . 23
6.4 Spot Check Frequency . . . . . . . . . . . . . . . . . . . 24
6.5 State at the Correspondent Node . . . . . . . . . . . . . 24
6.6 Sending Packets to a Mobile Node . . . . . . . . . . . . . 26
6.7 Receiving Packets from a Mobile Node . . . . . . . . . . . 27
6.8 Handling Clock Ticks . . . . . . . . . . . . . . . . . . . 29
7. Security Considerations . . . . . . . . . . . . . . . . . . . 30
7.1 Scope of Protection . . . . . . . . . . . . . . . . . . . 30
7.2 Attacks on the Routing Infrastructure . . . . . . . . . . 31
7.3 Limiting Packet Rate . . . . . . . . . . . . . . . . . . . 32
7.4 Asymmetric Network Attachment . . . . . . . . . . . . . . 34
7.5 Resource Exhaustion Attacks . . . . . . . . . . . . . . . 35
7.6 Alternatives to Credit-Based Authorization . . . . . . . . 36
8. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 37
9. Protocol Configuration Variables . . . . . . . . . . . . . . . 38
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 38
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 39
11.1 Normative References . . . . . . . . . . . . . . . . . . . . 39
11.2 Informative References . . . . . . . . . . . . . . . . . . . 39
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 40
Intellectual Property and Copyright Statements . . . . . . . . 42
Vogt, et al. Expires November 19, 2004 [Page 2]
Internet-Draft Credit-Based Authorization May 2004
1. Introduction
Along with the introduction of mobility support in the Internet comes
the concern about a new family of previously unknown attacks. The
potential misuse of mobility-management protocols is multifold,
ranging from resource-exhaustion attacks and redirection-based
flooding attacks to masquerading attacks and attacks against data
confidentiality or integrity [4]. Mobility-related attacks are of
great concern because any node in the Internet is a potential victim.
A victim does not even have to be mobile. The problem is that the
victim has little means to protect itself, whereas the party that is
in a position to build an effective security mechanism does not
directly benefit from its investments into this mechanism [8].
There is hence a strong need that a mobility-management protocol,
like Mobile IPv6, incorporates the required security mechanisms in
the first place. Mobile IPv6 has been carefully designed with regard
to this. Malicious binding updates with home agents are discouraged
by a mandatory security and trust relationship between a mobile node
and its home agent. Since neither a security nor a trust
relationship can be presupposed to exist between a mobile node and a
correspondent node, Mobile IPv6 prevents malicious binding updates
with correspondent nodes, when using Route Optimization, through a
home-address test and a care-of-address test. A mobile node must
pass both tests in order to authenticate its home address and care-of
address during the binding-update phase. Home-address authentication
verifies that the mobile node is the legitimate owner of the home
address. It prevents masquerading attacks and attacks against data
confidentiality or integrity. Care-of-address authentication
verifies that the mobile node is actually present at the new care-of
address. It prevents a malicious node from flooding a third party
with a stream of redirected packets.
A disadvantage of Mobile IPv6's home-address and care-of-address
tests is that both tests have to be accomplished before a mobile node
can initiate a binding update. The latency of registering a new
care-of address with a correspondent node can therefore be
significant, and it can have an adverse impact on delay-sensitive
applications. Early Binding Updates for Mobile IPv6 [2], an optional
extension to Mobile IPv6 Route Optimization, reduce this latency by
moving both tests out of the critical period during which a new
care-of address cannot yet be used: A "prophylactic home-address
test" is accomplished before the mobile node changes its point of
network attachment, and a "concurrent care-of-address test" runs in
parallel with data transfer to and from the new care-of address. The
new care-of address is said to be "unconfirmed" until the mobile node
authenticates the care-of address to the correspondent node, and it
is called "confirmed" thereafter.
Vogt, et al. Expires November 19, 2004 [Page 3]
Internet-Draft Credit-Based Authorization May 2004
Section 7 of [2] furnishes evidence that the security of Early
Binding Updates is equivalent to that of standard Mobile IPv6 except
for a new vulnerability to flooding attacks based on packet
redirection towards an unconfirmed care-of address. We show in
Section 3 that the data volume and rate of a redirection-based
flooding attack can be substantially higher than the data volume and
rate generated by the attacker itself. No such "amplification" can
be achieved through flooding attacks that exist in today's Internet.
With the objective that a mobility-management protocol does not
introduce new threats in addition to those that already exist,
flooding-attack amplification, be it with respect to data volume or
data rate, is certainly unacceptable. In this document, we propose a
mechanism, Credit-Based Authorization, that prevents misuse of Early
Binding Updates for amplified, redirection-based flooding attacks.
Through proper parameterization, Credit-Based Authorization can
discourage misuse of Early Binding Updates even for non-amplified,
redirection-based flooding attacks.
Credit-Based Authorization limits the data volume that a
correspondent node can send to a mobile node's unconfirmed care-of
address, and it limits the data rate at which the correspondent node
can send this data. The maximum data volume and rate depend on how
much data the mobile node has sent to, or received from, the
correspondent node during the last few seconds. With Credit-Based
Authorization, a correspondent node measures the "effort" that a
mobile node spends for sending or receiving packets, and it grants
"credit" for this effort. The mobile node needs credit during the
binding-update phase: If it has enough credit, the mobile node can
use a new, unconfirmed care-of address for both sending and receiving
packets. Without sufficient credit, the mobile node can use a new,
unconfirmed care-of address only for packets that it sends to the
correspondent node. The correspondent node then sends packets for
the mobile node to the mobile node's home address until the mobile
node authenticates its care-of address, and the care-of address
becomes confirmed. We show that Credit-Based Authorization can be
realized at reasonable deployment costs.
The applicability of Credit-Based Authorization goes beyond the
protection against misuse of Early Binding Updates. In [5], a
credit-based approach is used to incrementally extend binding
lifetimes. This reduces the signaling overhead required for binding
refreshes. We are also working on an extended version of Early
Binding Updates which allows a mobile node to already register a new
care-of address from its old point of network attachment. Such
"Anticipated Binding Updates" would naturally depend on something
similar to Mobile IPv6's Alternate Care-of-Address option. We
believe that Credit-Based Authorization can help to make Anticipated
Binding Updates a secure and, thus, realistic option.
Vogt, et al. Expires November 19, 2004 [Page 4]
Internet-Draft Credit-Based Authorization May 2004
The rest of this document is structured as follows: We define a set
of key terms in Section 2. In Section 3, we compare the types of
flooding attacks that already exist in today's Internet to those that
could become possible by the introduction of mobility support if no
preventive measures are taken. In Section 4, we describe Early
Binding Updates in a nutshell, and we sketch the idea of Credit-Based
Authorization. We show that there are two variants of Credit-Based
Authorization: The first variant measures a mobile node's effort for
sending packets to the correspondent node, the second variant
measures a mobile node's effort for receiving packets from the
correspondent node. Either variant comes with its particular
advantages and drawbacks. We detail both variants in Section 5. In
section Section 6, we discuss potential security concerns which one
might have with measuring a mobile node's effort for receiving
packets from the correspondent node. We propose a mechanism,
periodic care-of-address spot checks, which can disperse these
concerns. Security considerations follow in Section 7. We conclude
in Section 8.
2. Terminology
Effort
Effort is a mobile node's investment in terms of bandwidth,
processing power, and memory. There are two types of effort which
a mobile node typically spends: effort for sending packets to the
correspondent node and effort for receiving packets from the
correspondent node.
Credit
Credit is a unit used by a correspondent node to determine how
much data it can send to a particular mobile node. A mobile node
earns credit by investing effort.
Amplification
Amplification describes the severity of a flooding attack. It is
defined as the ratio between the data volume and rate that the
attacked victim is exposed to and the data volume and rate that
the attacker itself generates.
Early Binding Update message
An Early Binding Update message equals a standard Binding Update
message except that it only authenticates the mobile node's home
address. When a mobile node changes its point of network
attachment and configures a new care-of address, the mobile node
sends to the correspondent node an Early Binding Update message in
order to tentatively register the new care-of address with the
Vogt, et al. Expires November 19, 2004 [Page 5]
Internet-Draft Credit-Based Authorization May 2004
correspondent node [2].
Early Binding Acknowledgement message
A correspondent node sends to a mobile node an Early Binding
Acknowledgement message in order to indicate successful reception
of an Early Binding Update message [2].
Prophylactic home-address test
A prophylactic home-address test is a home-address test which a
mobile node performs before it changes its point of network
attachment. The mobile node executes a prophylactic home-address
test whenever a handover is imminent. Alternatively, if handovers
cannot be anticipated, the mobile node should do a prophylactic
home-address test periodically [2].
Concurrent care-of-address test
A concurrent care-of-address test is a care-of-address test which
is performed in parallel with data transfer to and from the tested
care-of address [2].
Confirmed care-of address
A confirmed care-of address is a care-of address which a mobile
node has registered with a correspondent node by means of a
properly authenticated standard Binding Update message [2].
Unconfirmed care-of address
An unconfirmed care-of address is a care-of address which a mobile
node has registered with a correspondent node by means of a
properly authenticated Early Binding Update message and which has
not yet been confirmed by means of a properly authenticated
standard Binding Update message [2].
3. Flooding Attacks
Flooding attacks are a variant of denial-of-service attacks. They
are characterized by a victim being bombarded with unwanted packets
at a rate that the victim, and possibly the victim's access network,
cannot handle. In this section, we compare the types of flooding
attacks that already exist in today's Internet to those that could
become possible by the introduction of mobility support if no
preventive measures are taken. We show that the latter are
potentially much more severe due to a significantly higher
amplification. "Amplification" is the ratio between the data volume
and rate that the victim is exposed to and the data volume and rate
that the attacker itself generates.
Vogt, et al. Expires November 19, 2004 [Page 6]
Internet-Draft Credit-Based Authorization May 2004
There are essentially two types of flooding attacks that are already
possible in today's Internet: direct flooding attacks and reflection
attacks. In a direct flooding attack, the attacker itself sends
unwanted packets to the victim. In an indirect reflection attack, a
third node, the reflection point, sends the packets. The attacker
typically uses a known protocol vulnerability to make the reflection
point generate these packets [7]. One example is that the attacker
sends ICMP Echo Request packets to the reflection point with the
packets' source addresses set to the victim's IP address. The
reflection point, in turn, sends ICMP Echo Reply packets "back" to
the victim. Another example is that the attacker sends TCP SYN
packets, again with false source addresses, to the reflection point,
which in turn sends TCP SYN-ACK packets to someone who does not
expect these packets. Since most TCP servers are configured so that
they re-send a TCP SYN packet multiple times when failing to receive
an acknowledgement, this reflection attack can even produce a small
amplification. Gaining more significant amplification in today's
Internet typically requires more complex attack strategies like
taking over control of other nodes by spreading compromised code.
Such attacks are of a different quality because they change the
behavior of infected nodes. We do not discuss these attacks in this
document. Instead, we focus on attacks that are based on misuse of
vulnerable, but uncompromised protocol behavior. Note that
vulnerable protocol behavior could be misused by infected nodes to
substantially increase the damage each of them causes.
Given uncompromised behavior of Internet protocols, we make the
following two observations: First, both in a direct flooding attack
and in a reflection attack, the attacker can conceal its identity by
spoofing its packets' source addresses. Reflection attacks are
purely based on source-address spoofing. Ingress filtering [6] in
the attacker's access network may prevent source-address spoofing,
but more than a few access networks do not employ ingress filtering.
Second, what limits a flooding attack in today's Internet is the
minimum bandwidth along the path from the attacker to the victim,
possibly through a reflection point. The data volume and rate that
the flooding attack comes to is by and large determined by the data
volume and rate that the attacker itself generates, i.e., there is no
significant amplification.
The situation can change when we introduce mobility. Suppose a node
is allowed to change its IP address without having to evidence that
it is present at the new IP address. Then, an attacker can
subscribe, through its own IP address, to a large data flow (e.g., a
video stream) offered by some server on the Internet. The attacker
can easily accomplish the initial handshake procedure with the server
while it uses its own IP address. Once data is flowing, the attacker
can redirect the flow to the IP address of an arbitrary third party,
Vogt, et al. Expires November 19, 2004 [Page 7]
Internet-Draft Credit-Based Authorization May 2004
the victim. The attacker can use the sequence numbers learned during
the initial handshake procedure in order to spoof acknowledgements
for packets that it assumes the server has sent to the victim.
The unprecedented severity of redirection-based flooding attacks is
that not the attacker, but a faithful server on the Internet can be
made generate packets used for an attack. The server does not have
to be infected with compromised code, and neither the victim nor the
server has to be mobile. The attacker produces as little as spoofed
feedback information to keep the data flow alive. To make matters
worse, the attacker can redirect to the victim data flows from
multiple servers. We observe that the scope of a redirection-based
flooding attack is only limited by the data volume and rate that one,
or even multiple, servers can generate, as well as the cumulative
minimum bandwidths of the paths from each server to the victim. The
associated amplification is much higher than in the discussed ICMP
and TCP flooding attacks. Hence, there is a strong need that a
mobility-management protocol cannot be misused for amplified,
redirection-based flooding attacks. In fact, since non-amplified
flooding attacks are already possible in today's Internet, protection
against non-amplified, redirection-based flooding attacks is less
important.
4. Overview
In this section, we provide a brief description of Early Binding
Updates for Mobile IPv6, and we sketch the idea of Credit-Based
Authorization. We explain how Credit-Based Authorization can
discourage misuse of Early Binding Updates for redirection-based
flooding attacks, and how it can prevent such misuse for
flooding-attack amplification. We show that there are two variants
of Credit-Based Authorization: The first variant measures a mobile
node's effort for sending packets to the correspondent node, the
second variant measures a mobile node's effort for receiving packets
from the correspondent node. We discuss the particular advantages
and drawbacks of either variant.
We refer to Section 5 for more details on Credit-Based Authorization,
and we refer to [2] for a thorough specification of Early Binding
Updates.
4.1 Early Binding Updates
When a mobile node recognizes that it is about to change its point of
network attachment, the mobile node initiates a prophylactic
Vogt, et al. Expires November 19, 2004 [Page 8]
Internet-Draft Credit-Based Authorization May 2004
home-address test. Alternatively, if the mobile node cannot
anticipate handovers, it should periodically repeat the home-address
test. When the mobile node eventually moves, the mobile node
configures a new care-of address and sends to the correspondent node
an Early Binding Update message. The prophylactic home-address test
allows the mobile node to authenticate its home address in this
message.
The mobile node initiates a concurrent care-of-address test as soon
as it has dispatched the Early Binding Update message. The mobile
node can start using its new care-of address as of then. The
correspondent node starts using the mobile node's new care-of address
as soon as it receives the Early Binding Update message from the
mobile node. Hence, both the mobile node and the correspondent node
use the mobile node's new care-of address in parallel with the
concurrent care-of-address test being executed.
When the correspondent node receives the Early Binding Update message
from the mobile node, it can be confident that the mobile node is the
legitimate owner of the home address advertised in this message due
to the home-address authentication. Since there is no
care-of-address authentication in the Early Binding Update message,
the correspondent node does not know at this point whether the mobile
node is actually present at its new care-of address. The new care-of
address is therefore said to be "unconfirmed". The binding lifetime
for an unconfirmed care-of address is limited to a few seconds,
TENTATIVE_BINDING_LIFETIME [2].
When the concurrent care-of-address test concludes, the mobile node
sends to the correspondent node a standard Binding Update message.
This message obeys the formats and semantics defined in [1], i.e., it
authenticates both the mobile node's home address and the mobile
node's new care-of address. Hence, when the correspondent node
receives the standard Binding Update message, it can be confident
that the mobile node uses the correct home address, and that the
mobile node is actually present at the new care-of address. The
correspondent node then changes the status of the new care-of address
from "unconfirmed" to "confirmed", and it extends the lifetime of the
associated binding to the smaller of the lifetime requested by the
mobile node and the maximum lifetime, MAX_RR_BINDING_LIFETIME,
according to Section 9.5.1 and Section 9.5.2 of [1].
Due to the lack of care-of-address authentication in the Early
Binding Update message, there needs to be additional protection while
a mobile node's care-of address is unconfirmed. If no such
protection is provided, a malicious node may misuse Early Binding
Updates to register, as an unconfirmed care-of address, the IP
address of a third party. The correspondent node would then redirect
Vogt, et al. Expires November 19, 2004 [Page 9]
Internet-Draft Credit-Based Authorization May 2004
the attacker's packets to the third party without knowing it.
Credit-Based Authorization provides the additional protection that is
needed while a mobile node's care-of address is unconfirmed.
4.2 Credit-Based Authorization
Credit-Based Authorization limits the data volume that a
correspondent node can send to a mobile node's unconfirmed care-of
address, and it limits the rate at which the correspondent node can
send this data. Credit-Based Authorization is transparent to the
mobile node. There are two variants of Credit-Based Authorization,
which determine the maximum data volume and rate in different ways:
The first variant limits the data volume and rate according to how
much data the mobile node has sent to the correspondent node during
the last few seconds. The second variant limits the data volume and
rate according to how much data the mobile node has received from the
correspondent node during the last few seconds. We will compare both
variants in Section 4.3.
The correspondent node measures the "effort" that a mobile node
spends for sending or receiving packets, depending on which variant
of Credit-Based Authorization is used. Effort is measured in terms
of the size of packets recently sent or received. The product of
effort and a factor, EFFORT_QUENCH_FACTOR, of less than 1.0 yields
the mobile node's "credit". Credit, in turn, authorizes the mobile
node to receive packets at an unconfirmed care-of address. For each
packet that the correspondent node sends to an unconfirmed care-of
address of the mobile node, the correspondent node charges the mobile
node credit in the amount of the size of the packet. Through
exponential aging, we ensure that the mobile node's credit is at all
times determined by the effort that the mobile node has spent
throughout the last few seconds.
When the correspondent node has a packet for the mobile node, the
correspondent node first checks the state of the mobile node's
care-of address. If the care-of address is confirmed, the care-of
address has recently been authenticated by the mobile node, and the
correspondent node can be confident that the mobile node is actually
present at the care-of address. In this case, the correspondent node
sends the packet to the mobile node's care-of address as usual,
without touching the mobile node's credit. Otherwise, if the mobile
node's care-of address is unconfirmed, the correspondent node
determines the packet's destination according to how much credit the
mobile node has. If the mobile node's credit is more than, or equal
to, the size of the outgoing packet, the correspondent node sends the
packet directly to the mobile node's care-of address, and it reduces
the mobile node's credit by the size of this packet. If the mobile
Vogt, et al. Expires November 19, 2004 [Page 10]
Internet-Draft Credit-Based Authorization May 2004
node's credit is less than the size of the outgoing packet, the
correspondent node sends the packet to the mobile node's home
address. The packet is forwarded to the mobile node by the mobile
node's home agent in this case. Since the mobile node's home address
has been authenticated in the Early Binding Update message, the
correspondent node can assume that the mobile node is the legitimate
owner of the home address [2]. Thus, the correspondent node can send
packets to the mobile node's home address without security concerns,
and it does not need to reduce the mobile node's credit in this case.
We believe that a faithful mobile node, communicating with a
correspondent node in a typical manner, automatically expends effort
for sending packets to the correspondent node as well as for
receiving packets from the correspondent node. A faithful mobile
node hence automatically earns credit due to its normal behavior such
that it can receive packets at an unconfirmed care-of address during
the binding-update phase. As a consequence, the mobile node does not
have to be aware that Credit-Based Authorization is applied at the
correspondent node.
4.3 Variants of Credit-Based Authorization
A mobile node spends effort--in terms of bandwidth, processing power,
and memory--for sending packets to the correspondent node as well as
for receiving packets from the correspondent node. A correspondent
node may credit either type of effort. Effort for sending packets
can be credited, at the correspondent node, by measuring packets
received from the mobile node. Effort for receiving packets can be
credited by measuring packets sent to the mobile node while the
mobile node's care-of address is confirmed. Both variants have their
particular advantages and drawbacks.
The advantage of crediting a mobile node's effort for sending packets
is that it is exactly this type of effort that an attacker would have
to invest for a direct flooding attack or a reflection attack, both
of which are already possible in today's Internet. Through proper
selection of the EFFORT_QUENCH_FACTOR protocol-configuration
variable, the crediting function can easily be parameterized such
that misuse of Early Binding Updates for a redirection-based flooding
attack becomes more expensive than a direct flooding attack or a
reflection attack. Thus, requiring a node, whether faithful or
malicious, to send packets in order to earn credit is a
straightforward way to discourage misuse of Early Binding Updates.
The motivation for crediting a mobile node's effort for receiving
packets is different. Consider a mobile node running an application
which receives much more data from the correspondent node than it
Vogt, et al. Expires November 19, 2004 [Page 11]
Internet-Draft Credit-Based Authorization May 2004
sends back to the correspondent node. Streaming applications are
probably the most dominant example where user data is transferred
one-way only. The correspondent node is typically a server
originating a lot of data, whereas the mobile node generates little
more than acknowledgements and status information. The huge data
stream originating from the correspondent node leads to excessive
credit consumption during the binding-update phase. The mobile node,
however, can be expected to have a hard time gathering this credit if
its credit depends on the packets that it sends to the correspondent
node. We believe that crediting the mobile node's effort for
receiving packets is the most reasonable approach in this case.
Then, assuming that the volume and rate of data originating from the
correspondent node does not fluctuate too much--particularly, that
there is no significant increase in the generated data volume and
rate during the binding-update phase--applications with asymmetric
traffic will work fine. We emphasize that only while the mobile
node's care-of address is confirmed should the correspondent node
grant credit for packets sent to the mobile node. Only then can the
correspondent node expect that the mobile node actually receives
these packets. Note that this crediting function also works fine for
applications with symmetric traffic.
Packet loss on the path from the correspondent node to the mobile
node can be an issue when the correspondent node measures a mobile
node's effort for receiving packets based on the packets that it has
sent to the mobile node. We discuss this issue in Section 6. We
show how the correspondent node can use care-of-address spot checks
to take packet loss into consideration when it grants credit for
packets the mobile node was supposed to receive.
The first variant of Credit-Based Authorization, crediting a mobile
node's effort for sending packets, is transparent to the mobile node.
The second variant of Credit-Based Authorization, crediting a mobile
node's effort for receiving packets, is transparent to the mobile
node unless care-of-address spot checks are used.
A correspondent node may credit a mobile node's effort for both,
sending packets and receiving packets. After all, the mobile node
invests resources for traffic in both directions. The combination of
the two variants of Credit-Based Authorization is straightforward.
One simply needs to make sure that the total credit a mobile node can
earn does not exceed the total effort the mobile node has spent on
sending and receiving packets. To simplify matters, we do not
explicitly consider the case of crediting traffic in both directions
in this document.
Vogt, et al. Expires November 19, 2004 [Page 12]
Internet-Draft Credit-Based Authorization May 2004
5. Detailed Description
In this section, we describe independent implementations for two
variants of Credit-Based Authorization. The first variant measures a
mobile node's effort for sending packets to the correspondent node,
the other variant measures a mobile node's effort for receiving
packets from the correspondent node. Both implementations affect the
correspondent node only; no changes are needed at the mobile node.
5.1 State at the Correspondent Node
Credit-Based Authorization requires a correspondent node to be aware
of the state, confirmed or unconfirmed, of all registered care-of
addresses. The state of a care-of address is important to decide
whether or not a mobile node needs credit for packets sent to its
care-of address. We propose that the correspondent node maintains,
for each binding, an additional one-bit flag,
CONFIRMED_CARE_OF_ADDRESS, indicating whether or not the respective
care-of address is confirmed. CONFIRMED_CARE_OF_ADDRESS equals 1 if
the care-of address is confirmed. CONFIRMED_CARE_OF_ADDRESS equals 0
if the care-of address is unconfirmed. Figure 1 shows the two
care-of-address states as well as the state transitions that a
care-of address can be subject to.
Reordered +------+ Early
Early | | Binding
Binding | +-------------+ Update +-------------+
Update +--> | | --------> | | ---+ Early
| Confirmed | | Unconfirmed | | Binding
Standard +--> | | <-------- | | <--+ Update
Binding | +-------------+ Standard +-------------+
Update | | Binding
+------+ Update
Figure 1: Care-of Address States
When a mobile node changes its point of network attachment, it sends
to the correspondent node an Early Binding Update message in order to
tentatively register its new care-of address. Having sent the Early
Binding Update message, the mobile node initiates a concurrent
care-of-address test and, once the care-of-address test concludes,
sends to the correspondent node a standard Binding Update message in
order to confirm its care-of address [2].
When the correspondent node receives the Early Binding Update message
from the mobile node, the correspondent node registers the mobile
Vogt, et al. Expires November 19, 2004 [Page 13]
Internet-Draft Credit-Based Authorization May 2004
node's new care-of address, and it sets the lifetime of the mobile
node's binding to TENTATIVE_BINDING_LIFETIME, according to Section
4.1 of [2]. Beyond this, the correspondent node clears the
CONFIRMED_CARE_OF_ADDRESS flag in the mobile node's binding in order
to indicate that the new care-of address is unconfirmed at this
point. When the correspondent node receives the standard Binding
Update message from the mobile node, the correspondent node extends
the lifetime of the mobile node's binding to the smaller of the
lifetime requested by the mobile node and the maximum lifetime,
MAX_RR_BINDING_LIFETIME, according to Section 9.5.1 and Section 9.5.2
of [1]. Moreover, the correspondent node sets the
CONFIRMED_CARE_OF_ADDRESS flag in the mobile node's binding in order
to indicate that the care-of address is now confirmed. When the
mobile node changes its point of network attachment another time, it
again sends to the correspondent node an Early Binding Update
message, and the procedure repeats itself.
The correspondent node may receive from the mobile node multiple
Early Binding Update messages in a row. The messages may carry the
same care-of address, for instance, if the concurrent care-of-address
test fails for some reason, and the mobile node recognizes, due to a
timeout, that either the Care-of Test Init message or the Care-of
Test message got lost under way. The mobile node may then re-send
both, the Early Binding Update message in order to refresh the
tentative binding at the correspondent node, and the Care-of Test
Init message in order to re-initiate the concurrent care-of-address
test. The Early Binding Update messages may carry different care-of
addresses, for instance, if the mobile node changes its point of
network attachment two times shortly one after the other, and there
is no sufficient time to let the first concurrent care-of-address
test conclude.
When the correspondent node receives multiple Early Binding Update
messages in a row, the correspondent node handles each message
according to the procedure defined in Section 4.1 of [2], regardless
of whether this message carries a new or an already registered
care-of address. I.e., the correspondent node registers the care-of
address and resets the binding lifetime to
TENTATIVE_BINDING_LIFETIME. The state of the care-of address remains
unconfirmed.
When the correspondent node receives multiple standard Binding Update
messages in a row, the correspondent node handles each message
according to the procedure defined in Section 9.5.1 and Section 9.5.2
of [1], regardless of whether this message carries a new or an
already registered care-of address. I.e., the correspondent node
registers the care-of address and resets the binding lifetime to the
smaller of the lifetime requested by the mobile node and the maximum
Vogt, et al. Expires November 19, 2004 [Page 14]
Internet-Draft Credit-Based Authorization May 2004
lifetime, MAX_RR_BINDING_LIFETIME. The state of the care-of address
remains confirmed.
A mobile node's Early Binding Update message and subsequent standard
Binding Update message might get reordered on the way to the
correspondent node. In this case, the correspondent node receives
from the mobile node a standard Binding Update message before it
receives from the same mobile node an Early Binding Update message
carrying the same care-of address. Since the two messages carry the
same care-of address, they obviously belong together. Thus, when the
correspondent node receives an Early Binding Update message carrying
an already registered, confirmed care-of address, the correspondent
node must ignore the message, keeping both the care-of-address state
and the binding lifetime unchanged.
5.2 Exponential Aging
We feel that a mobile node's credit should represent the mobile
node's most recently spent effort only. Otherwise, a mobile node may
collect credit over a potentially very long period and consume this
credit during a very short period. Though unlikely, a malicious node
may exploit this property by accumulating a large amount of credit
with a relatively slow data stream, and by using this credit, all at
once, for a short but potent data burst against an arbitrary victim.
We propose exponential aging to gradually reduce a mobile node's old
credit over time. With exponential aging, a mobile node's credit
diminishes while the mobile node does not use it. Accumulating
credit over a very long period, as well as collecting an indefinite
amount of credit, is thus impossible. An implication of this is that
exponential aging can limit the rate of packets which are being sent
to an unconfirmed care-of address of a mobile node to approximately
the rate of packets which have recently been sent to a confirmed
care-of address of the same mobile node. In other words, the
implication is that exponential aging can limit the rate of packets
which are consuming a mobile node's credit to approximately the rate
of packets based on which the same mobile node has recently earned
this credit. See Section 7.3 for a more detailed explanation on why
exponential aging can limit the rate of packets sent to an
unconfirmed care-of address.
A precise aging function ages a mobile node's credit whenever this
credit is about to be increased or reduced, and it accommodates the
time passed since the mobile node's credit was changed before. A
precise aging function is very complex, though. We thus propose to
simply re-calculate a mobile node's credit in equidistant "crediting
intervals" of TENTATIVE_BINDING_LIFETIME length. The effort that a
Vogt, et al. Expires November 19, 2004 [Page 15]
Internet-Draft Credit-Based Authorization May 2004
mobile node has invested throughout a crediting interval is turned
into credit after having exponentially aged the mobile node's old
credit at the end of the crediting interval. We thus ensure that new
credit does not age before it has been around for at least one
crediting interval. The correspondent node may synchronize the
crediting intervals for all entries in its binding cache. A single
clock is therefore sufficient.
Note that TENTATIVE_BINDING_LIFETIME defines both the length of a
crediting interval and the binding lifetime for an unconfirmed
care-of address [2]. Since the binding lifetime for an unconfirmed
care-of address is exactly the time for which the mobile node's
credit should be good during the binding-update phase, it makes sense
to let a mobile node collect credit during this time and to age the
mobile node's credit only when it is older than this time.
An alternative to exponential aging is to simply limit a mobile
node's credit by a constant upper bound. A limit certainly prevents
a mobile node from collecting an indefinite amount of credit.
However, a limit does not prevent a mobile node from keeping
collected credit for a long time before using the credit. A limit is
also insensitive to throughput conditions on the path between the
mobile node and the correspondent node. I.e., a limit for a
low-bandwidth connection is certainly inappropriate for a
high-bandwidth connection, and vice versa. We thus feel that
exponential aging is a more appropriate approach than limiting a
mobile node's credit by a constant upper bound.
5.3 Sending Packets to a Mobile Node
Suppose a correspondent node has a packet for a mobile node, and the
mobile node's care-of address is confirmed. If the correspondent
node credits the mobile node's effort for sending packets to the
correspondent node, it does not need to do anything related to
Credit-Based Authorization in this case. The correspondent node
simply sends the packet to the care-of address (A.1) without changing
the mobile node's credit:
(A) Sending a packet to a confirmed care-of address
(Credit is given for sending packets)
------------------------------------------------------------
(A.1) send(PACKET,CARE_OF_ADDRESS)
If the correspondent node credits the mobile node's effort for
receiving packets from the correspondent node, the correspondent node
proceeds according to the following algorithm.
Vogt, et al. Expires November 19, 2004 [Page 16]
Internet-Draft Credit-Based Authorization May 2004
(A') Sending a packet to a confirmed care-of address
(Credit is given for receiving packets)
------------------------------------------------------------
(A'.1) EFFORT := EFFORT + size(PACKET)
(A'.2) send(PACKET,CARE_OF_ADDRESS)
The correspondent node measures the mobile node's effort for
receiving a packet from the correspondent node in terms of the size
of the packet in bytes (A'.1). Effort invested during one crediting
interval is accumulated in a variable, EFFORT, which should be
sufficiently long not to roll over. The correspondent node maintains
this variable for each entry in its binding cache. New credit will
be calculated, based on the value of EFFORT, at the end the crediting
interval in step (D), after having exponentially aged any old credit.
We thus ensure that new credit does not age before it has been around
for at least one crediting interval. In step (A'.2), the packet is
sent to the mobile node's care-of address.
Now suppose that the correspondent node has a packet for a mobile
node, and the mobile node's care-of address is unconfirmed. In this
case, the correspondent node determines the packet's destination
according to the following steps, independently of whether the
correspondent node credits the mobile node's effort for sending or
for receiving packets.
(B) Sending a packet to an unconfirmed care-of address
(Credit is given for sending or receiving packets)
------------------------------------------------------------
(B.1) If CREDIT >= size(PACKET)
Then
(B.2) CREDIT := CREDIT - size(PACKET)
(B.3) send(PACKET,CARE_OF_ADDRESS)
(B.4) Else
(B.5) CREDIT := 0
(B.6) send(PACKET,HOME_ADDRESS)
EndIf
The correspondent node keeps the mobile node's credit in a variable,
CREDIT, which should be sufficiently long not to roll over. The
correspondent node maintains this variable for each entry in its
binding cache. Provided that CREDIT is greater than or equal to the
size of the outgoing packet in bytes (B.1), CREDIT is reduced by this
packet size (B.2), and the packet is sent to the mobile node's
care-of address (B.3). Otherwise, if CREDIT is smaller than the size
of the outgoing packet in bytes (B.4), any remaining credit is
eliminated (B.5) in order not to switch between the mobile node's
home address and current care-of address multiple times during a
single binding-update phase in case packet sizes differ. The packet
Vogt, et al. Expires November 19, 2004 [Page 17]
Internet-Draft Credit-Based Authorization May 2004
is then sent to the mobile node's home address (B.6). Note that
CREDIT never becomes a negative value.
Note that, even when the mobile node's care-of address is
unconfirmed, the correspondent node can assume that the mobile node
is the legitimate owner of the registered home address, and it can
send packets to this home address without security concerns. This is
because the correspondent node has recently received from the mobile
node an Early Binding Update message in which the mobile node's home
address has been authenticated [2]. However, differences in
propagation delay between packets directly relayed between the mobile
node and the correspondent node and packets passing the mobile node's
home agent may have an adverse performance impact on transport-layer
protocols and application behavior. It is subject to further
research how significant this impact can be.
The amount of available credit does not impact the route taken by
those packets which the mobile node sends to the correspondent node.
The correspondent node can safely accept a packet sent from the
mobile node's care-of address even if this care-of address is
unconfirmed and CREDIT is smaller than the size of the packet. The
reason is that packets sent from the mobile node to the correspondent
node cannot leverage a flooding attack other than a direct flooding
attack or a reflection attack, both of which are already possible in
today's Internet (Section 3). This implies that a mobile node can
send packets to the correspondent node from a new care-of address
immediately after having dispatched an Early Binding Update message
for this care-of address. The mobile node does not need to be aware
that the correspondent node uses Credit-Based Authorization, and it
does not need to know how much credit it has.
5.4 Receiving Packets from a Mobile Node
Suppose a correspondent node receives a packet from a mobile node.
If the correspondent node credits the mobile node's effort for
sending packets to the correspondent node, the correspondent node
executes the following algorithm independently of whether the mobile
node's care-of address is confirmed or unconfirmed.
(C) Receiving a packet
(Credit is given for receiving packets)
------------------------------------------------------------
(C.1) EFFORT := EFFORT + size(PACKET)
(C.2) deliver(PACKET)
The correspondent node measures the mobile node's effort for sending
a packet to the correspondent node in terms of the size of the packet
Vogt, et al. Expires November 19, 2004 [Page 18]
Internet-Draft Credit-Based Authorization May 2004
in bytes (C.1). The packet is delivered to the application in step
(C.2).
If the correspondent node credits the mobile node's effort for
receiving packets from the correspondent node, the correspondent node
does not need to do anything specific to Credit-Based Authorization.
It simply delivers the packet to the application (C'.1) without
changing the mobile node's credit:
(C') Receiving a packet
(Credit is given for sending packets)
------------------------------------------------------------
(C'.1) deliver(PACKET)
5.5 Handling Clock Ticks
The correspondent node may synchronize the crediting intervals for
all entries in its binding cache. A single clock marking the end of
a crediting interval is therefore sufficient. Upon a clock tick, the
correspondent node re-calculates the credit for each entry in its
binding cache according to the following formula. This formula is
used independently of whether the correspondent node credits the
mobile node's effort for sending or for receiving packets. There is
no distinction between bindings with a confirmed care-of address and
bindings with an unconfirmed care-of address.
(D) Handling a clock tick
(Credit is given for sending or receiving packets)
------------------------------------------------------------
(D.1) For Each Binding Do
(D.2) NEW_CREDIT := EFFORT_QUENCH_FACTOR * EFFORT
(D.3) CREDIT := CREDIT * CREDIT_AGING_FACTOR \
+ NEW_CREDIT
(D.4) EFFORT := 0
EndFor
The correspondent node re-computes the credit for each entry in its
binding cache (D.1). A particular mobile node's new credit,
NEW_CREDIT, equals EFFORT multiplied by EFFORT_QUENCH_FACTOR (D.2).
NEW_CREDIT is a helper variable used in this specification for
clarity purposes only. NEW_CREDIT is added to the aged value of
CREDIT in step (D.3). We use the aging factor, CREDIT_AGING_FACTOR,
proposed in Section 9. In step (D.4), the correspondent node resets
EFFORT to zero.
EFFORT_QUENCH_FACTOR is intended to optionally choke the increase of
Vogt, et al. Expires November 19, 2004 [Page 19]
Internet-Draft Credit-Based Authorization May 2004
a mobile node's credit. If EFFORT_QUENCH_FACTOR is smaller than 1.0,
a mobile node is forced to invest more effort, through sending or
receiving packets, than it gets back from a correspondent node while
its care-of address is unconfirmed. Therefore, the smaller
EFFORT_QUENCH_FACTOR is chosen, the less efficiently can Early
Binding Updates be misused for a flooding attack. If
EFFORT_QUENCH_FACTOR is set to 0.0, the correspondent node does not
send any packets to an unconfirmed care-of address, but it sends
these packets to the mobile node's home agent. Obviously,
EFFORT_QUENCH_FACTOR is ineffective if set to 1.0. We propose the
value given in Section 9.
We believe that the following observation is worthwhile mentioning:
If the values of EFFORT_QUENCH_FACTOR and CREDIT_AGING_FACTOR are 0.5
or less, the theory of infinite series tells that, assuming EFFORT is
constant throughout all crediting intervals, CREDIT approaches, but
never exceeds, the value of EFFORT.
6. Care-of-Address Spot Checks
A correspondent node may credit a mobile node's effort for sending
packets to the correspondent node, or it may credit a mobile node's
effort for receiving packets from the correspondent node (Section
4.3). In this section, we discuss security concerns that one might
have with the latter approach. Although we provide rationale that
such security concerns are of less importance than they may seem to
be, we propose an optional mechanism, care-of-address spot checks,
that can disperse these security concerns.
6.1 Introduction
The question with crediting a mobile node's effort for receiving
packets from a correspondent node is how the correspondent node can
measure this effort. Limiting effort measurements to confirmed
care-of addresses may not be sufficient in case of packet loss along
the path from the correspondent node to the mobile node. If a router
drops packets due to congestion, the mobile node receives less data
than the correspondent node has originally sent, even though the
mobile node's care-of address is confirmed. Thus, the mobile node
may earn credit for data that was lost and that it has never
received. A malicious node may even be able to position itself
behind a bottleneck router on purpose, and it may spoof
acknowledgements to encourage the correspondent node to send more
data.
Vogt, et al. Expires November 19, 2004 [Page 20]
Internet-Draft Credit-Based Authorization May 2004
Fortunately, there is an argument that the described attack scenario
is less likely to occur than it may seem: As explained in Section 5.2
and Section 7.3, exponential aging ensures that packets used to
collect credit must occur at approximately the same rate as packets
that consume this credit. Consequently, if an attacker hid behind a
bottleneck router, illegitimately collecting credit for a later
flooding attack against a third party, the workload exposed to the
bottleneck router would have to be comparable with the magnitude of
the flooding attack to come upon the third party. Moreover, a
bottleneck router is typically located at the edge of the Internet,
presumably in the access network itself. Abnormal workload of a
router should draw the attention of the access network's
administrator, who could easily identify the perpetrator for two
reasons: First, the attacker's care-of address would show up as the
destination address of all packets causing the high workload. The
care-of address would reveal the attacker's identity because it would
have to be confirmed in this case. Second, the attacker's home
address would show up in the Type-2 Routing extension header
mandatorily attached to all packets causing the high workload. The
home address, too, would reveal the attacker's identity independently
of the care-of-address state, because it would have been
authenticated in all recently transmitted Early Binding Update
messages and standard Binding Update messages.
Note that the attacker may spoof acknowledgements in order to
accelerate the packet stream originating from the correspondent node.
The resulting packet flood might go beyond the capacity not only of
the attacker's access network, but also of some link deeper in the
Internet. It can be expected, though, that congestion inside the
Internet does not mitigate the flood upon the attacker's access
network due to a higher available bandwidth inside the Internet.
Hence, the attacker should be identified even in this situation.
These observations suggest that no attractive new type of flooding
attack is introduced when a correspondent node credits a mobile
node's effort for receiving packets from the correspondent node. On
the other hand, we recognize the usefulness of some sort of feedback
mechanism that can help the correspondent node determine how much
data a mobile node really receives. Transport- or application-layer
protocols may provide this feedback. We propose a network-layer
approach, periodic care-of-address spot checks, which can disperse
the security concerns explained above. Our work on care-of-address
spot checks is in its very early stages. We decided to present
care-of-address spot checks in this document in order to spark a
discussion on their practicality and sufficiency.
Vogt, et al. Expires November 19, 2004 [Page 21]
Internet-Draft Credit-Based Authorization May 2004
6.2 Overview
Care-of-address spot checks periodically probe a mobile node's
presence at a confirmed care-of address. They are used to
approximately determine the congestion on the path between the
correspondent node and the mobile node. The correspondent node
calculates the mobile node's credit based on the packets sent to the
mobile node and the measured congestion. The more congestion the
correspondent node perceives, the fewer packets is the mobile node
expected to have received, and the less credit is given to the mobile
node. Thus, care-of-address spot checks provide reasonable certainty
that a mobile node earns credit only for packets that it actually
receives. Spot-check-related signaling data is piggybacked to
user-data packets to reduce the bandwidth required for
care-of-address spot checks to a minimum. Care-of-address spot
checks are, by definition, unnecessary if there are no user-data
packets to which spot-check-related signaling data can be attached.
Care-of-address spot checks are initiated by the correspondent node.
When a care-of-address spot check is due for a particular mobile
node, the correspondent node attaches a random string to the next
packet that it sends to the mobile node. In case the packet gets
through to the mobile node, the mobile node retrieves the random
string from the received packet, and it sends the random string back
with the next packet addressed to the correspondent node. The mobile
node is said to "pass" the care-of-address spot check if the
correspondent node finds that the returned random string matches the
random string originally sent to the mobile node.
An important rule in the security design for Mobile IPv6 is that all
signaling is initiated by the mobile node, and that the correspondent
node only responds to the source address from which it has received a
request. This rule ensures that a malicious node cannot redirect a
correspondent node's response except by spoofing a request's source
address. Mobile IPv6's home-address and care-of-address tests, both
of which are initiated by the mobile node, are a good example where
this rule has left a mark. See Section 3.3.3 of [3] for details on
this.
One may argue that care-of-address spot checks violate the described
security-design rule since care-of-address spot checks are initiated
by the correspondent node. This, however, is not the case for two
reasons. First, random strings are attached to packets which would
anyway be sent. The increase in packet size, which is due to an
attached random string, should be acceptable. Second,
care-of-address spot checks are exclusively initiated for confirmed
care-of addresses. Therefore, the correspondent node can rest
assured that packets carrying a random string cannot be redirected to
Vogt, et al. Expires November 19, 2004 [Page 22]
Internet-Draft Credit-Based Authorization May 2004
spoofed care-of addresses, even though some of these packets may be
dropped under way.
6.3 Generating Random Strings
There are multiple ways in which a correspondent node can generate
the random strings that it needs for care-of-address spot checks.
For instance, the correspondent node may generate a new random string
for each care-of-address spot check. An obvious disadvantage of this
approach, though, is that the number of random strings which the
correspondent node must remember grows with the number of pending
care-of-address spot checks.
Mobile IPv6 uses Care-of Keygen Tokens [1] for care-of-address tests,
which can be handled in a more economic way. The beauty of Care-of
Keygen Tokens is that the correspondent node does not have to
explicitly store them. Instead, the correspondent node can
re-compute a mobile node's Care-of Keygen Token on demand given a
nonce, which can be re-used for multiple mobile nodes, and the mobile
node's care-of address. All the correspondent node needs to remember
is a set of nonces, the size of which is independent of the number of
pending care-of-address tests. This kind of resource preservation is
an important precaution against denial-of-service attacks that aim at
exhausting the correspondent node's resources [3][4].
One may argue that protection against denial-of-service attacks is
less important in the case of care-of-address spot checks than it is
in the case of care-of-address tests. After all, both a mobile
node's home address and care-of address are already authenticated
during a care-of-address spot check. Computational efficiency may
therefore be more important than storage efficiency. This is a
fundamental difference to standard care-of-address tests.
Nonetheless, in order to simplify our proposed implementation of
care-of-address spot checks, we re-use existing Mobile IPv6 code for
handling Care-of Keygen Tokens.
Note that nonces used for care-of-address spot checks typically have
a much shorter lifetime, and are more frequently re-produced, than
nonces used for care-of-address tests. We therefore use separate
nonce sets for care-of-address tests and care-of-address spot checks.
Henceforth, when we mention nonces or Care-of Keygen Tokens, we are
referring to those used for care-of-address spot checks rather than
care-of-address tests.
We propose a new option, a Spot Check option, for the IPv6
Destination Options extension header. When a correspondent node
initiates a spot check of a mobile node's care-of address, it uses a
Vogt, et al. Expires November 19, 2004 [Page 23]
Internet-Draft Credit-Based Authorization May 2004
Spot Check option to carry to the mobile node a Care-of Keygen Token
and the index of the nonce used to produce this Care-of Keygen Token.
Likewise, the mobile node uses a Spot Check option to return the
received Care-of Keygen Token and nonce index to the correspondent
node. The mobile node may use a single Spot Check option to return
multiple pairs of Care-of Keygen Tokens and nonce indices to the
correspondent node. This can be helpful in case the rate at which
the mobile node sends packets to the correspondent node is less than
the frequency of care-of-address spot checks.
One may deploy a mechanism other than Care-of Keygen Tokens to
generate and verify random strings for care-of-address spot checks.
Although we do not discuss any such mechanism in this document, we
emphasize that a random string, regardless of how it is created, must
be sufficiently long to discourage a malicious node from guessing the
string. Moreover, random-string generation must not be predictable,
and there must be different random strings for different mobile
nodes.
6.4 Spot Check Frequency
A correspondent node calculates a mobile node's new credit at the end
of each crediting interval. An important design choice is hence how
many care-of-address spot checks the correspondent node should
initiate for a particular mobile node during one crediting interval.
Obviously, there is a trade-off: On one hand, the higher the
frequency of spot checks, the more accurately can the correspondent
node determine the level of congestion on the path towards a mobile
node. The frequency of care-of-address spot checks should therefore
be high. On the other hand, each care-of-address spot check has an
associated processing overhead--not so much at the mobile node as at
the correspondent node. The frequency of care-of-address spot checks
should therefore be limited in order to contain this overhead. We
propose a maximum number of MAXIMUM_SPOT_CHECKS spot checks per
crediting interval (Section 9). The correspondent node then
initiates at most one care-of-address spot check per mobile node
every TENTATIVE_BINDING_LIFETIME/MAXIMUM_SPOT_CHECKS time. The
correspondent node may initiate less care-of-address spot checks for
a particular mobile node if there are, at times, no packets to be
sent to the mobile node, or if the mobile node's care-of address is
unconfirmed during part of the crediting interval.
6.5 State at the Correspondent Node
The time required to complete a care-of-address spot check not only
depends on the round-trip time between a correspondent node and a
Vogt, et al. Expires November 19, 2004 [Page 24]
Internet-Draft Credit-Based Authorization May 2004
mobile node, but also on the availability of packets which can carry
a Spot Check option. However, neither the round-trip time nor the
availability of packets is known in advance. Since a mobile node
must have enough time to return a received Spot Check option, the
correspondent node should be able to re-produce Care-of Keygen Tokens
for a sufficiently long time. We propose that the correspondent node
keeps the MAXIMUM_SPOT_CHECKS recently generated nonces. This allows
it to re-produce one crediting interval worth of Care-of Keygen
Tokens. We store these nonces in an array, NONCE[], with
MAXIMUM_SPOT_CHECKS slots. The currently oldest nonce is replaced by
a new nonce every TENTATIVE_BINDING_LIFETIME/MAXIMUM_SPOT_CHECKS
time. Consequently, any nonce is valid for a period of
TENTATIVE_BINDING_LIFETIME length, and a care-of-address spot check
should not take longer than this time to complete. An index,
CURRENT_NONCE_INDEX, points to the most recently generated nonce in
the NONCE[] array.
The correspondent node needs to remember which nonces it has used for
spot checks of a particular mobile node's care-of address.
Therefore, we extend each entry in the correspondent node's binding
cache by an array, INITIATED[], of MAXIMUM_SPOT_CHECKS bits' length.
Given a binding for a particular mobile node, INITIATED[i] is one if
and only if NONCE[i] was used for a spot check of this mobile node's
care-of address. When NONCE[CURRENT_NONCE_INDEX] is replaced by a
new value, INITIATED[CURRENT_NONCE_INDEX] is set to zero for all
entries in the correspondent node's binding cache.
Moreover, the correspondent node needs to remember whether an
initiated care-of-address spot check has been passed by a particular
mobile node. This information is needed to compute the mobile node's
credit at the end of a crediting interval. For this, we extend each
entry in the correspondent node's binding cache by another array,
PASSED[], of MAXIMUM_SPOT_CHECKS bits' length. Given a binding for a
particular mobile node, PASSED[i] is one if and only if INITIATED[i]
is one and the mobile node has passed the care-of-address spot check
for which NONCE[i] was used. When NONCE[CURRENT_NONCE_INDEX] is
replaced by a new value, PASSED[CURRENT_NONCE_INDEX] is set to zero
for all entries in the correspondent node's binding cache.
Care-of-address spot checks for multiple mobile nodes may coincide
because each mobile node is spot-checked with a different Care-of
Keygen Token. A single clock is thus sufficient to trigger spot
checks of all registered confirmed care-of addresses. The same clock
can also trigger the crediting function at the end of a crediting
interval, i.e., after each series of MAXIMUM_SPOT_CHECKS clock ticks.
A mobile node may attach the same Spot Check option to multiple
packets sent to a correspondent node in order to compensate for
Vogt, et al. Expires November 19, 2004 [Page 25]
Internet-Draft Credit-Based Authorization May 2004
potential packet loss. Of course, the correspondent node must not
attach the same Spot Check option to multiple packets sent to the
mobile node, because this would increase the likelihood that the
mobile node receives the Spot Check option. An increased likelihood,
in turn, would distort the measured congestion on the path towards
the mobile node. For the same reason, a nonce must not be used for
more than one spot check of a single care-of address, although it may
be re-used for spot checks of multiple different care-of addresses.
6.6 Sending Packets to a Mobile Node
When a correspondent node has a packet for a mobile node, and the
mobile node's care-of address is confirmed, the correspondent node's
operation looks like this:
(A") Sending a packet to a confirmed care-of address
(Credit is given for receiving packets)
------------------------------------------------------------
(A".1) EFFORT := EFFORT + size(PACKET)
(A".2) If INITIATED[CURRENT_NONCE_INDEX] == 0
Then
(A".3) CoKT := careOfKeygenToken(NONCES[CURRENT_NONCE_INDEX])
(A".4) attachSpotCheckOption(PACKET,CoKT,CURRENT_NONCE_INDEX)
(A".5) INITIATED[CURRENT_NONCE_INDEX] := 1
EndIf
(A".6) send(PACKET,CARE_OF_ADDRESS)
The correspondent node measures the mobile node's effort for
receiving a packet in terms of the size of the packet in bytes
(A".1). Effort invested during one crediting interval is accumulated
in the variable EFFORT, which we have introduced in Section 5.3. New
credit will be calculated at the end the crediting interval in step
(D"), after having exponentially aged any old credit. The height of
new credit depends on the value of EFFORT as well as the ratio of
initiated to passed spot checks of the mobile node's care-of address.
In step (A".2), the correspondent node checks whether a new spot
check of the mobile node's care-of address is due. This is the case
if INITIATED[CURRENT_NONCE_INDEX] is zero, which means that the most
recently generated nonce, NONCE[CURRENT_NONCE_INDEX], has not yet
been used for a spot check of the mobile node's care-of address. In
step (A".3), the correspondent node produces a Care-of Keygen Token
based on the mobile node's care-of address and
NONCE[CURRENT_NONCE_INDEX] as defined in Section 5.2.5 of [1]. The
correspondent node attaches a Spot Check option carrying this Care-of
Keygen Token and CURRENT_NONCE_INDEX to the outgoing packet in step
(A".4). The correspondent node then sets
Vogt, et al. Expires November 19, 2004 [Page 26]
Internet-Draft Credit-Based Authorization May 2004
INITIATED[CURRENT_NONCE_INDEX] to one (A".5) in order not to do
another care-of-address spot check with the same nonce for the same
mobile node. If, at step (A".2), the correspondent node finds that
INITIATED[CURRENT_NONCE_INDEX] is one, NONCE[CURRENT_NONCE_INDEX] has
already been used for a spot check of the mobile node's care-of
address. In this case, no care-of-address spot check is due, and
steps (A".3) through (A".5) are skipped. Finally, the correspondent
node sends the packet to the mobile node's care-of address (A".6).
When the correspondent node has a packet for a mobile node, and the
mobile node's care-of address is unconfirmed, the correspondent node
determines the packet's destination according to step (B) of Section
5.3.
6.7 Receiving Packets from a Mobile Node
When the correspondent node receives a packet from a mobile node, the
correspondent node executes the following algorithm independently of
whether the mobile node's care-of address is confirmed or
unconfirmed.
(C") Receiving a packet
(Credit is given for receiving packets)
------------------------------------------------------------
(C".1) If hasSpotCheckOption(PACKET)
Then
(C".2) CoKT := getCareOfKeygenToken(PACKET)
(C".3) NONCE_INDEX := getNonceIndex(PACKET)
(C".4) If (INITIATED[NONCE_INDEX] == 1) \
and (PASSED[NONCE_INDEX] == 0)
Then
(C".5) myCoKT := careOfKeygenToken(NONCES[NONCE_INDEX])
(C".6) If CoKT == myCoKT
Then
(C".7) PASSED[NONCE_INDEX] := 1
EndIf
EndIf
EndIf
(C".8) deliver(PACKET)
In step (C".1), the correspondent node checks whether the packet has
a Spot Check option attached to it. If there is no Spot Check
option, the packet is simply delivered to the application in step
(C".8). If a Spot Check option exists, the correspondent node
determines as follows whether this Spot Check option is the correct
response to a recently initiated care-of-address spot check. Let
CoKT be the Care-of Keygen Token advertised in the Spot Check option
Vogt, et al. Expires November 19, 2004 [Page 27]
Internet-Draft Credit-Based Authorization May 2004
(C".2), and let NONCE_INDEX be the nonce index advertised in the Spot
Check option (C".3). NONCE_INDEX identifies the nonce that was
allegedly used to create CoKT.
The correspondent node then ensures that INITIATED[NONCE_INDEX] is
one and PASSED[NONCE_INDEX] is zero (C".4). If
INITIATED[NONCE_INDEX] is zero, NONCE[NONCE_INDEX] has not yet been
used for a spot check of the mobile node's care-of address. This may
happen if the received Spot Check option pertains to a nonce that has
been replaced in the meantime. The correspondent node can safely
ignore the Spot Check option in this case. If PASSED[NONCE_INDEX] is
one, the mobile node has already passed the care-of-address spot
check for which NONCE[NONCE_INDEX] was used. This may happen if the
packet carrying the Spot Check option gets duplicated during
transmission, or if the mobile node attaches the same Spot Check
option to multiple packets in order to mitigate the potential of
packet loss. Although it would not harm if the correspondent node
set PASSED[NONCE_INDEX] to 1 again in step (C".7), the correspondent
node can avoid re-producing the Care-of Keygen Token from the Spot
Check option in step (C".5) in this case.
Given that INITIATED[NONCE_INDEX] is one and PASSED[NONCE_INDEX] is
zero, the correspondent node re-produces the Care-of Keygen Token
from the Spot Check option based on the mobile node's care-of address
and NONCE[NONCE_INDEX] (C".5). If the re-produced value matches the
Care-of Keygen Token from the Spot Check option (C".6), the
correspondent node sets PASSED[NONCE_INDEX] to one (C".7). In case
of a mismatch, the correspondent node ignores the Spot Check option.
The correspondent node should not punish the mobile node for
returning an incorrect Care-of Keygen Token because a malicious node
may otherwise fake false Spot Check options in order to prevent a
faithful mobile node from gathering credit. Finally, the
correspondent node delivers the packet to the application in step
(C".8).
Care-of-address spot checks are needed only when a mobile node
collects credit, i.e., when the mobile node's care-of address is
confirmed. On the other hand, the correspondent node should accept a
Spot Check option coming back from a mobile node even if the mobile
node's care-of address is unconfirmed. The reason is that the mobile
node may receive a Spot Check option at a confirmed care-of address
shortly before changing its point of network attachment. The mobile
node may not be able to immediately return the Spot Check option due
to a lack of outgoing packets. If the mobile node changes its
network-attachment point at that time, chances are that the mobile
node returns the received Spot Check option through an unconfirmed
care-of address.
Vogt, et al. Expires November 19, 2004 [Page 28]
Internet-Draft Credit-Based Authorization May 2004
6.8 Handling Clock Ticks
As mentioned, the correspondent node may synchronize the
care-of-address spot checks for all entries in its binding cache. A
single clock is thus sufficient to trigger care-of-address spot
checks, nonce replacements, and crediting. With spot check, the
clock ticks MAXIMUM_SPOT_CHECKS times per crediting interval, i.e.,
in intervals of TENTATIVE_BINDING_LIFETIME/MAXIMUM_SPOT_CHECKS
length. The currently oldest nonce is replaced upon every clock
tick; crediting is done only once per crediting interval, i.e., every
MAXIMUM_SPOT_CHECKS clock ticks.
Nonce replacement and crediting are united in the following
algorithm, which the correspondent node runs upon every clock tick.
The algorithm also prepares the next spot check of all confirmed
care-of addresses. Note that the initiation time for a particular
care-of-address spot check depends on when the correspondent node
sends to the mobile node the next packet. This packet is then used
to carry a Spot Check option.
(D") Handling a clock tick
(Credit is given for receiving packets)
------------------------------------------------------------
(D".1) CURRENT_NONCE_INDEX := (CURRENT_NONCE_INDEX + 1) \
modulo MAXIMUM_SPOT_CHECKS
(D".2) NONCE[CURRENT_NONCE_INDEX] := random(2**64-1)
(D".3) For Each Binding Do
PASSED[CURRENT_NONCE_INDEX] := 0
INITIATED[CURRENT_NONCE_INDEX] := 0
EndFor
(D".4) If CURRENT_NONCE_INDEX == 0
Then
(D".5) For Each Binding Do
(D".6) NEW_CREDIT := EFFORT * EFFORT_QUENCH_FACTOR \
* sum(PASSED)/sum(INITIATED)
(D".7) CREDIT := CREDIT * CREDIT_AGING_FACTOR \
+ NEW_CREDIT
(D".8) EFFORT := 0
EndFor
EndIf
In step (D".1), the correspondent node increments
CURRENT_NONCE_INDEX, which rolls over to zero when it reaches
MAXIMUM_SPOT_CHECKS. The correspondent node then replaces
NONCE[CURRENT_NONCE_INDEX] by a new random string (D".2), and it sets
INITIATED[CURRENT_NONCE_INDEX] and PASSED[CURRENT_NONCE_INDEX] to
zero for each entry in its binding cache (D".3). There is no
distinction between bindings with a confirmed care-of address and
Vogt, et al. Expires November 19, 2004 [Page 29]
Internet-Draft Credit-Based Authorization May 2004
bindings with an unconfirmed care-of address. For a particular
mobile node with a confirmed care-of address,
INITIATED[CURRENT_NONCE_INDEX] and PASSED[CURRENT_NONCE_INDEX] help
the correspondent node remember that a new care-of-address spot check
is due, and that a Spot Check option should be attached to the next
packet sent to the mobile node.
In step (D".4), the correspondent node checks whether the current
crediting interval is over. This is defined to be the case when
CURRENT_NONCE_INDEX rolls over to zero in step (D".1).
CURRENT_NONCE_INDEX then points to the first nonce in the NONCE[]
array. If so, the correspondent node re-computes the credit for each
entry in its binding cache (D".5). A particular mobile node's new
credit, NEW_CREDIT, is the product of EFFORT, EFFORT_QUENCH_FACTOR,
and the ratio of the number of passed to the number of initiated
care-of-address spot checks during the crediting interval (D".6).
NEW_CREDIT is added to the aged value of CREDIT in step (D".7).
Finally, the correspondent node resets EFFORT to zero (D".8).
7. Security Considerations
Credit-Based Authorization can prevent misuse of Early Binding
Updates for amplified, redirection-based flooding attacks, and it can
discourage such misuse for non-amplified, redirection-based flooding
attacks. In this section, we explain why this is exactly the scope
of protection that is needed to securely employ Early Binding
Updates. We also discuss the design of Credit-Based Authorization
itself with respect to security.
7.1 Scope of Protection
We emphasize that the objective of Credit-Based Authorization is not
to prevent flooding attacks in general: This would probably be a
hopeless venture given that we already have direct flooding attacks
and reflection attacks in today's Internet (Section 3). The
objective of Credit-Based Authorization is rather to prohibit misuse
of Early Binding Updates for a type of flooding attack that is more
potent than those types of flooding attacks already possible today.
With this aim, Credit-Based Authorization prevents misuse of Early
Binding Updates for amplified, redirection-based flooding attacks.
As shown in Section 3, these attacks constitute to the Internet a
significant threat which does not exist today. Credit-Based
Authorization prevents them by limiting the data volume that a
correspondent node can send to a mobile node's care-of address while
this care-of address is unconfirmed. We show in Section 5.2 and
Vogt, et al. Expires November 19, 2004 [Page 30]
Internet-Draft Credit-Based Authorization May 2004
Section 7.3 that, through exponentially aging a mobile node's old
credit, there is also a limitation on the correspondent node's data
rate when sending to an unconfirmed care-of address.
Although Credit-Based Authorization does not prevent misuse of Early
Binding Updates for non-amplified, redirection-based flooding
attacks, it still makes such misuse unattractive enough to render it
practically negligible. The reason is that the correspondent node
can control, through the EFFORT_QUENCH_FACTOR protocol-configuration
variable, how much effort a potential attacker must spend to gain the
credit it needs for a flooding attack. Provided that
EFFORT_QUENCH_FACTOR is below 1.0, the maximum data volume and rate
that a flooding attack can amount to is less than the data volume and
rate that the attacker has either previously sent to the
correspondent node or previously received from the correspondent
node. This makes misuse of Early Binding Updates for non-amplified,
redirection-based flooding attacks very ineffective.
From an attacker's point of view, misuse of Early Binding Updates for
non-amplified, redirection-based flooding attacks has another
important disadvantage compared to a conventional flooding attack:
The attacker's home address shows up in the Type-2 Routing extension
header mandatorily attached to all redirected packets. The home
address reveals the attacker's identity independently of the
care-of-address state, because it has been authenticated in all
recently transmitted Early Binding Update messages and standard
Binding Update messages.
7.2 Attacks on the Routing Infrastructure
Suppose an attacker has access to the path between a mobile node's
home agent and the correspondent node. In this position, the
attacker can impersonate the mobile node by spoofing an Early Binding
Update message or a standard Binding Update message. For this, the
attacker has to obtain a valid Home Keygen Token, which it can obtain
in one of two ways. First, the attacker can eavesdrop on the Home
Test Init and Home Test messages being exchanged between the mobile
node and the correspondent node. Second, the attacker can itself
inject into the network a Home Test Init message on behalf of the
mobile node, and it can intercept the Home Test message coming back
from the correspondent node.
The difference between spoofing an Early Binding Update message and a
standard Binding Update message is that the attacker has to have a
valid Care-of Keygen Token in addition to the Home Keygen Token in
the latter case. The attacker can produce a Care-of Keygen Token for
a particular care-of address if it is present, or has a recorder, on
Vogt, et al. Expires November 19, 2004 [Page 31]
Internet-Draft Credit-Based Authorization May 2004
the path from the correspondent node to that care-of address. For
this, the attacker injects into the network a spoofed Care-of Test
Init message, and it intercepts the Care-of Test message, along with
the Care-of Keygen Token, returning from the correspondent
node--either by itself or through the recorder. In a special case,
the attacker is located in the correspondent node's network, where it
can acquire a Care-of Keygen Token for an arbitrary care-of address.
With the standard binding-update procedure, there is no way by which
the attacker can redirect the mobile node's packets to a care-of
address unless it is present, or has a recorder, on the path from the
correspondent node to that care-of address. Things are different if
the correspondent node supports Early Binding Updates and
Credit-Based Authorization. In this case, an attacker on the path
between the mobile node's home agent and the correspondent node can
redirect the mobile node's packets to an arbitrary care-of address
without having to show presence at that care-of address. Of course,
the accumulated data volume of the redirected packets is limited by
the mobile node's credit.
We argue that the described type of attack is unlikely to occur for
two reasons. First, a fundamental assumption in the design of the
Mobile IPv6 security design [3] is that the routing infrastructure is
secure and functioning. As this specifically includes the path
between the mobile node's home agent and the correspondent node, it
is reasonably unlikely that an attacker can get access to this path.
Second, an attacker would have to invest a significant amount of
effort in order to wage the described attack. Apart from having to
get access to the routing infrastructure between the mobile node's
home agent and the correspondent node, the attacker would have to
synchronize with the mobile node in order to determine a point of
time at which the mobile node's credit is high enough to make the
attack worthwhile. We believe that these investments are
unprofitable given that the yield of the described attack is limited
by the mobile node's credit anyway.
Though unlikely to occur, this potential attack ought to be borne in
mind during experimental deployments of Early Binding Updates and
Credit-Based Authorization.
7.3 Limiting Packet Rate
We repeatedly mention in this document that Credit-Based
Authorization limits both the volume and the rate of packets that a
correspondent node can send to a mobile node's unconfirmed care-of
address. According to the specification in Section 5, however, there
Vogt, et al. Expires November 19, 2004 [Page 32]
Internet-Draft Credit-Based Authorization May 2004
is an explicit limitation only of the data volume, whereas the
limitation of the data rate is an implicit consequence of the
application of exponential aging. In this section, we explain how
exponential aging effectively enforces a limitation of the rate of
packets that a correspondent node can send to a mobile node's
unconfirmed care-of address.
Exponential aging ensures that credit older than one crediting
interval rapidly looses its value. Consequently, a mobile node's
available credit is, at any time, for the most part determined by the
effort that the mobile node has spent during the preceding crediting
interval. A crediting interval has the same length as a tentative
binding's lifetime, TENTATIVE_BINDING_LIFETIME, which, in turn, is
the time period for which the mobile node needs its credit during a
binding-update phase. These things considered, we observe that the
time period during which credit can be most effectively collected is
as long as the time period during which this credit can be consumed,
i.e., TENTATIVE_BINDING_LIFETIME time. The consequence is as
follows.
Suppose, first, that the correspondent node measures the mobile
node's effort for sending packets to the correspondent node. Since
credit translates into data volume, the data volume that the
correspondent node can send to a mobile node's unconfirmed care-of
address during TENTATIVE_BINDING_LIFETIME time is limited by the data
volume that the mobile node has recently sent to the correspondent
node during a period of the same length. Hence, the mean rate at
which the correspondent node can send data to a mobile node's
unconfirmed care-of address, averaged over a period of
TENTATIVE_BINDING_LIFETIME length, is limited by the mean rate at
which the mobile node has recently sent data to the correspondent
node during a period of the same length. Provided the value of
TENTATIVE_BINDING_LIFETIME is reasonably small, the actual data rates
are bound to be close together as well.
Things are similar when the correspondent node measures the mobile
node's effort for receiving packets from the correspondent node. In
this case, the data volume that the correspondent node can send to a
mobile node's unconfirmed care-of address during
TENTATIVE_BINDING_LIFETIME time is limited by the data volume that
the mobile node has recently received from the correspondent node
during a period of the same length. Provided the value of
TENTATIVE_BINDING_LIFETIME is reasonably small, the actual rate at
which the correspondent node can send data to a mobile node's
unconfirmed care-of address is bound to be close to the actual rate
at which the mobile node has recently received data from the
correspondent node.
Vogt, et al. Expires November 19, 2004 [Page 33]
Internet-Draft Credit-Based Authorization May 2004
In Section 3, we show that the power of a conventional flooding
attack is by and large determined by the data volume and rate
generated by the attacker itself. As explained above, Credit-Based
Authorization transfers this property from conventional flooding
attacks to flooding attacks realized through misuse of Early Binding
Updates if and only if the correspondent node measures the mobile
node's effort for sending packets to the correspondent node. The
situation is different if the correspondent node measures the mobile
node's effort for receiving packets from the correspondent node. See
Section 7.4 for more details on this.
7.4 Asymmetric Network Attachment
In Section 4.3, we show that there are two variants of Credit-Based
Authorization: The first variant measures a mobile node's effort for
sending packets to a correspondent node; the second variant measures
the mobile node's effort for receiving packets from the correspondent
node. The first variant is based on the observation that, in a
direct flooding attack or a reflection attack (Section 3), the
attacker needs to spend resources in terms of sending, rather than
receiving, packets. Thus, requiring a node, whether faithful or
malicious, to send packets in order to earn credit is a
straightforward way to discourage misuse of Early Binding Updates for
redirection-based flooding attacks. The second variant accommodates
a mobile node which receives much more data from the correspondent
node than it sends back to the correspondent node. If the first
variant was used in this case, this mobile node might not be able to
collect the credit it needs, during a binding-update phase, to
sustain the data stream received from the correspondent node.
In most scenarios, crediting a mobile node's effort both for sending
packets and for receiving packets provides comparable protection
against misuse of Early Binding Updates. This even though, in a
direct flooding attack or a reflection attack, the attacker's
investments are in terms of packets which the attacker sends rather
than in terms of packets which the attacker receives. The reason is
that a node, whether faithful or malicious, typically spends
comparable effort--in terms of bandwidth, processing power, and
memory--for both sending and receiving packets.
Things are different, however, if a node is asymmetrically attached
to the Internet through, for instance, ADSL. An attacker could
collect much more credit for receiving packets than it could collect
for sending packets in this situation. As a consequence, if credit
is given for packets which the attacker receives, misuse of Early
Binding Updates for a redirection-based flooding attack might still
be lucrative. Whether the existence of asymmetric network attachment
Vogt, et al. Expires November 19, 2004 [Page 34]
Internet-Draft Credit-Based Authorization May 2004
prohibits the second variant of Credit-Based Authorization is subject
to further discussion.
As an aside, there is an alternative to the second variant of
Credit-Based Authorization which likewise accommodates applications
with asymmetric traffic patterns: Here, the correspondent node
extends the length of a crediting interval such that the mobile
node--even though it may not send as much data to the correspondent
node as it receives from the correspondent node--has a chance to
collect the amount credit that it needs, during a binding-update
phase, to sustain the data stream received from the correspondent
node. The advantage of this approach is that it accommodates
applications with asymmetric traffic patterns without posing a new
threat due to the existence of asymmetric network attachment. The
drawback is that extending the length of a crediting interval allows
a mobile node to collect credit over a longer period of time. A
malicious node may misuse this property to by-pass the
rate-controlling function of exponential aging, which we describe in
Section 5.2 and Section 7.3. For this reason, we do not deepen the
idea of extending the length of a crediting interval in this
document.
7.5 Resource Exhaustion Attacks
In Section 6.3, we discuss how a correspondent node may produce and
check the random strings needed for care-of-address spot checks. We
propose to re-use the standard formula from Section 5.2.5 of [1],
which is used to produce and check Care-of Keygen Tokens for
care-of-address tests. This formula is an HMAC_SHA1 function.
Mobile IPv6's Care-of Keygen Tokens help the correspondent node to
efficiently manage its resources in terms of memory storage [3][4].
However, when Care-of Keygen Tokens are used for care-of-address spot
checks, care has to be taken by the correspondent node not to fall
victim to denial-of-service attacks that aim at exhausting its
resources in terms of processing power. This can happen if a
malicious node sends to the correspondent node Spot Check options
with bogus Care-of Keygen Tokens. The correspondent node would have
to check the validity of each of the received tokens in this case.
The processing capacity required to validate Care-of Keygen Tokens in
normal operation should be acceptable, but the processing capacity
needed to invalidate a large number of bogus Care-of Keygen Tokens
may be substantial.
On the other hand, both a mobile node's home address and care-of
address are already authenticated during a care-of-address spot
check. One may argue that this feature is likely to discourage an
Vogt, et al. Expires November 19, 2004 [Page 35]
Internet-Draft Credit-Based Authorization May 2004
attacker from waging a denial-of-service attack against the
correspondent node.
Still, it remains to be discussed how susceptible care-of-address
spot checks are to denial-of-service attacks. One could mitigate the
threat of such attacks by using a more efficient function to produce
and check Care-of Keygen Tokens for care-of-address spot checks,
while keeping the standard function used in [1] to produce and check
Care-of Keygen Tokens for care-of-address test. For instance, one
may calculate Care-of Keygen Tokens for care-of-address spot checks
as a simple SHA1 hash rather than a keyed HMAC_SHA1.
7.6 Alternatives to Credit-Based Authorization
There are alternatives to Credit-Based Authorization which can
protect against misuse of Early Binding Updates for redirection-based
flooding attacks. One alternative is to grant the use of Early
Binding Updates to a trusted community only. Recall that, when the
correspondent node receives an Early Binding Update message from the
mobile node, it can be confident that the mobile node is the
legitimate owner of the home address advertised in this message due
to the home-address authentication. This, in turn, allows the
correspondent node to use the mobile node's home address as a
criterion for deciding whether or not to install a tentative binding
for the mobile node's new care-of address. For instance, the
correspondent node may be a corporate server which grants Early
Binding Updates to mobile nodes from the corporate network only. [9]
goes a step further; it uses pre-configured binding-management keys
shared between mutually trusting nodes. These approaches have a
rather limited application scope, however.
Another alternative to Credit-Based Authorization is a combination of
ingress filtering [6] and a ban on the Alternate Care-of-Address
option in the Early Binding Update message. Ingress filtering is a
function in the access network, preventing packets with spoofed
source addresses to leave the network. The disadvantage of ingress
filtering is that it is not universally deployed, and as such cannot
be relied upon.
A third alternative to Credit-Based Authorization is to identify and
blacklist malicious nodes based on their observed behavior.
Credit-Based Authorization is a proactive strategy, whereas
behavior-based blacklisting is a reactive one. The advantage of a
reactive approach is that a faithful mobile node does not need to
invest effort (i.e., collect credit) before it can receive packets at
an unconfirmed care-of address during the binding-update period.
This can accommodate a mobile node having trouble to collect
Vogt, et al. Expires November 19, 2004 [Page 36]
Internet-Draft Credit-Based Authorization May 2004
sufficient credit--be it because the mobile node's care-of address
changes too frequently, or because the correspondent node measures
the mobile node's effort for sending packets to the correspondent
node, but the mobile node's application generates only very little
data. On the other hand, a reactive approach is by definition unable
to prevent misuse of Early Binding Updates in advance. What it can
do is contain the damage of such misuse and punish the perpetrator.
Punishment, however, will be negligible in most cases, since an
administrative relationship between a mobile node and a correspondent
node does usually not exist.
Behavior-based blacklisting requires a heuristic to determine what
behavior is considered "ill". Choosing the right heuristic, however,
is far from trivial. If carelessly chosen, a heuristic may punish a
faithful mobile node or overlook an evil one. For instance, a simple
heuristic may assume that a faithful mobile node sends a standard
Binding Update message soon after having sent an Early Binding Update
message. At first glance, this heuristic seems to work well: Keeping
alive an unconfirmed care-of address by repeatedly sending Early
Binding Update messages is no longer possible. On the other hand,
there is an easy way to trick this heuristic: An attacker can send to
the correspondent node a forged Early Binding Update message using a
victim's IP address as its care-of address. The attacker can cause
the correspondent node to send packets to the victim as long as the
heuristic allows. The attacker can then update the care-of address
to its own IP address by means of a standard Binding Update
message--thereby fulfilling what the heuristic expects it to do--and
immediately re-update the care-of address to the victim's IP address
by means of an Early Binding Update message. This procedure can be
repeated indefinitely.
While a heuristic may fail to identify a malicious node, it may also
wrongly accuse a faithful mobile node. For example, a mobile node
may be subject to two handovers immediately following each other.
After the first handover, the mobile node may be able to send an
Early Binding Update message, but it may not have enough time to
complete the concurrent care-of address test. If the mobile node
attempted another Early Binding Update after the second handover, the
above-described heuristic would wrongly blacklist it.
8. Conclusion
Early Binding Updates for Mobile IPv6 have been proposed as an
optional optimization for Mobile IPv6. Early Binding Updates allow a
mobile node to use a new care-of address while a care-of-address test
is in progress. Protective measures are necessary to rule out misuse
Vogt, et al. Expires November 19, 2004 [Page 37]
Internet-Draft Credit-Based Authorization May 2004
of this concurrency for redirection-based flooding attacks. We
propose a mechanism, Credit-Based Authorization, that prevents misuse
of Early Binding Updates for amplified, redirection-based flooding
attacks. Through proper parameterization, Credit-Based Authorization
can discourage misuse of Early Binding Updates even for
non-amplified, redirection-based flooding attacks.
With Credit-Based Authorization, a correspondent node monitors a
mobile node's effort for sending or receiving packets. The
correspondent node acknowledges invested effort based on the size of
packets that the mobile node sends to the correspondent node or
receives from the correspondent node. Invested effort is turned into
credit. This credit is consumed by each packet that the
correspondent node sends to an unconfirmed care-of address of the
mobile node during the binding-update phase. The invoiced credit is
such that a malicious node would have to invest more effort to misuse
Early Binding Updates for a redirection-based flooding attack than it
would have to invest for a conventional flooding attack. It stands
to reason that this property will make the malicious node change its
mind about misusing Early Binding Updates.
9. Protocol Configuration Variables
In this section, we recommend default values for the
protocol-configuration variables used in this document. We believe
that the proposed values are reasonable. A protocol implementer may
choose different values nonetheless.
CREDIT_AGING_FACTOR 0.5 (default)
EFFORT_QUENCH_FACTOR 0.5 (default)
MAXIMUM_SPOT_CHECKS 15 (default)
TENTATIVE_BINDING_LIFETIME 3 seconds (default)
TENTATIVE_BINDING_LIFETIME is originally being defined in [2]. It is
used as the length of a crediting interval in this document. When
care-of-address spot checks are used, we propose a maximum of
MAXIMUM_SPOT_CHECKS spot checks per crediting interval, i.e., at most
one care-of-address spot check every 200 milliseconds.
10. Acknowledgements
The necessity for a mechanism to prevent or discourage misuse of
Early Binding Updates for flooding attacks was sparked by a fruitful
discussion on the MIP6 and MOBOPTS mailing lists. Credit-Based
Vogt, et al. Expires November 19, 2004 [Page 38]
Internet-Draft Credit-Based Authorization May 2004
Authorization has been developed as a candidate solution, and a first
presentation was given at the 59th IETF meeting. For their interest,
precious comments, and valuable feedback, we express our gratitude to
the MIP6 and MOBOPTS communities, in particular to Francis Dupont,
James Kempf, Pekka Nikander, Erik Nordmark, Charles Perkins, Oliver
Stanze, Kilian Weniger, and Jidong Wu.
11. References
11.1 Normative References
[1] Johnson, D., Perkins, C. and J. Arkko, "Mobility Support in
IPv6", draft-ietf-mobileip-ipv6-24 (work in progress), June
2003.
[2] Vogt, C., Bless, R., Doll, M. and T. Kuefner, "Early Binding
Updates for Mobile IPv6",
draft-vogt-mip6-early-binding-updates-00 (work in progress),
February 2004.
11.2 Informative References
[3] Nikander, P., Arkko, J., Aura, T., Montenegro, G. and E.
Nordmark, "Mobile IP version 6 Route Optimization Security
Design Background", draft-ietf-mip6-ro-sec-00 (work in
progress), April 2004.
[4] Aura, T., Roe, M. and J. Arkko, "Security of Internet Location
Management", In Proceedings of the 18th Annual Computer
Security Applications Conference, Las Vegas, Nevada, USA.,
December 2002.
[5] Arkko, J. and C. Vogt, "Credit-Based Authorization for Binding
Lifetime Extension",
draft-arkko-mipv6-binding-lifetime-extension-00 (work in
progress), May 2004.
[6] Ferguson, P. and D. Senie, "Network Ingress Filtering: Defeating
Denial of Service Attacks which employ IP Source Address
Spoofing", BCP 38, RFC 2827, May 2000.
[7] Paxson, V., "An Analysis of Using Reflectors for Distributed
Denial-of-Service Attacks", Computer Communication Review
31(3)., July 2001.
[8] Anderson, R., "Why Information Security is Hard -- An Economic
Vogt, et al. Expires November 19, 2004 [Page 39]
Internet-Draft Credit-Based Authorization May 2004
Perspective", In Proceedings of the 17th Annual Computer
Security Applications Conference, New Orleans, Louisiana, USA.,
December 2001.
[9] Perkins, C., "Preconfigured Binding Management Keys for Mobile
IPv6", draft-ietf-mip6-precfgKbm-00 (work in progress), April
2004.
Authors' Addresses
Christian Vogt (Editor and Contact Person)
Institute of Telematics
University of Karlsruhe (TH)
P.O. Box 6980
76128 Karlsruhe
Germany
Phone: +49-721-608-8282
Fax: +49-721-388-097
EMail: chvogt@tm.uka.de
URI: http://www.tm.uka.de/~chvogt/
Jari Arkko
Ericsson Research NomadicLab
FI-02420 Jorvas
Finland
EMail: jari.arkko@ericsson.com
Roland Bless
Institute of Telematics
University of Karlsruhe (TH)
P.O. Box 6980
76128 Karlsruhe
Germany
Phone: +49-721-608-6413
Fax: +49-721-388-097
EMail: bless@tm.uka.de
URI: http://www.tm.uka.de/~bless/
Vogt, et al. Expires November 19, 2004 [Page 40]
Internet-Draft Credit-Based Authorization May 2004
Mark Doll
Institute of Telematics
University of Karlsruhe (TH)
P.O. Box 6980
76128 Karlsruhe
Germany
Phone: +49-721-608-6403
Fax: +49-721-388-097
EMail: doll@tm.uka.de
URI: http://www.tm.uka.de/~doll/
Tobias Kuefner
Institute of Telematics
University of Karlsruhe (TH)
P.O. Box 6980
76128 Karlsruhe
Germany
Phone: +49-721-608-8282
Fax: +49-721-388-097
EMail: kuefner@tm.uka.de
URI: http://www.tm.uka.de/~kuefner/
Vogt, et al. Expires November 19, 2004 [Page 41]
Internet-Draft Credit-Based Authorization May 2004
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
intellectual property 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; neither does it represent that it
has made any effort to identify any such rights. Information on the
IETF's procedures with respect to rights in standards-track and
standards-related documentation can be found in BCP-11. Copies of
claims of rights made available for publication 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 implementors or users of this specification can
be obtained from the IETF Secretariat.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights which may cover technology that may be required to practice
this standard. Please address the information to the IETF Executive
Director.
Full Copyright Statement
Copyright (C) The Internet Society (2004). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assignees.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
Vogt, et al. Expires November 19, 2004 [Page 42]
Internet-Draft Credit-Based Authorization May 2004
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Vogt, et al. Expires November 19, 2004 [Page 43]