One document matched: draft-montenegro-mipv6sec-bit-method-00.txt
Network Working Group G. Montenegro
Internet-Draft Sun Labs, Europe
Expires: October 4, 2002 P. Nikander
Ericsson Research NomadicLab
April 5, 2002
Protecting Against Bidding Down Attacks
draft-montenegro-mipv6sec-bit-method-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 October 4, 2002.
Copyright Notice
Copyright (C) The Internet Society (2002). All Rights Reserved.
Abstract
Mobile IPv6 uses "return routability" to secure route optimization.
Even after using this procedure, there are residual threats for which
other stronger methods provide protection. Since these are optional,
and return routability is the default, an attacker may engage in
"bidding down" attacks. These attacks aim at coercing participants
in Mobile IPv6 route optimization to forgo the stronger methods for
the default return routability. This document discusses what the
participants in route optimization can do to deter or alleviate
bidding down attacks: the "step down" procedure for the mobile node
and the "bit method" at the correspondent node.
Montenegro & Nikander Expires October 4, 2002 [Page 1]
Internet-Draft Protecting Against Bidding Down Attacks April 2002
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Bidding Down Attacks . . . . . . . . . . . . . . . . . . . . 6
2.1 Man-in-the-Middle Attack (MiTM) . . . . . . . . . . . . . . 7
2.1.1 General Case . . . . . . . . . . . . . . . . . . . . . . . . 7
2.1.2 Attack in the Mobile IPv6 Case . . . . . . . . . . . . . . . 8
2.1.3 Mallory situated between the Home Agent and Bob . . . . . . 10
2.2 Impostor Attack . . . . . . . . . . . . . . . . . . . . . . 11
3. Defending Against Bidding Down Attacks . . . . . . . . . . . 12
3.1 Step Down Procedure . . . . . . . . . . . . . . . . . . . . 12
3.2 Bit Method . . . . . . . . . . . . . . . . . . . . . . . . . 13
4. Security Considerations . . . . . . . . . . . . . . . . . . 15
5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 16
References . . . . . . . . . . . . . . . . . . . . . . . . . 17
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 17
Full Copyright Statement . . . . . . . . . . . . . . . . . . 18
Montenegro & Nikander Expires October 4, 2002 [Page 2]
Internet-Draft Protecting Against Bidding Down Attacks April 2002
1. Introduction
Mobile IPv6 [2] must support route optimization between mobile nodes
and correspondent nodes that have no previous security relationship
with each other. It must do so without recourse to infrastructure
based solutions. The default mechanism used is called "return
routability" (RR). Since RR is not based on strong cryptographic
assurances there are residual threats (see Residual_Threats.txt [1]),
in particular, the so called "future attacks" [3][4], as compared to
the baseline case of IPv6 without mobility,
Bidding down attacks raise serious concerns in two special areas:
1. Effects on Stationary Nodes
A stationary node may not wish to be involved in route
optimization as a mobile node (i.e. to redirect its address by
asking its correspondent nodes to instal binding cache entries on
its behalf). Such a node would benefit from the ability to
unequivocally (and securely) indicate that they never redirect
their address. Otherwise, it can fall prey to attacks which
exploit the residual threats allowed by RR.
This is potentially a very serious threat, because it can make any
"legacy" node in the Internet vulnerable to the future attacks.
This includes nodes which are always stationary and which would
never do that which mobile nodes do when they move: use RR to ask
their peers to insert binding cache entries on their behalf (to
redirect their addresses). Popular servers would be prime targets
for attack given their well-known addresses: rogue nodes could
"redirect" them by installing bogus binding cache entries. Of
course, all IPv6 nodes are expected to implement route
optimization as correspondent nodes, but not as mobile nodes.
Therefore, it is highly desirable to set up a mechanism that
allows correspondent nodes to easily check whether a given node's
address is redirectable or not.
2. Implications for Improved IPv6 Signaling Security
There are implications with respect to a future Internet with
improved IPv6 control signaling security. For example, it is
conceivable that Neighbour Discovery security could be improved.
Due to existing issues with Neighbor Discovery [5] RR does not
make current on-link security much worse. However, this could
change as a result of improvements in ND security, and as a result
RR might be left as the weakest link in Internet security. There
is a need to future-proof IPv6 by (1) putting mechanisms in place
Montenegro & Nikander Expires October 4, 2002 [Page 3]
Internet-Draft Protecting Against Bidding Down Attacks April 2002
from the very start, and (2) requiring that all IPv6 nodes
implement them. Only such an arrangement would allow a secure
migration towards more secure Binding Update authorization
mechanisms, for example, at the same time as ND is improved.
However, this is very hard if attackers can claim that the nodes
in question only support RR.
Because of this, it is essential to allow other (non-default)
stronger mechanisms to be used instead of RR.
Thus, the selection mechanism should be impervious to the "bidding
down" attack, in which an attacker forces parties that are initially
interested in engaging in a more secure procedure, to fall back on a
less secure one.
All Mobile IPv6 implementations should protect against the "bidding
down" attack. Several such mechanisms have been proposed. This
document reviews the step down procedure used in conjunction with the
"bit method" and examines their effectivity.
The "bit method" essentially divides the IPv6 interface identifier
space into two. Addresses from one space allow a node to express the
following to its peers:
"(1) I do not engage in redirection operations on my address, or,
if I do, (2) I only do so with cryptographically strong mechanisms
in which I will prove to your satisfaction that I do have
authorization to use that address."
Addresses from the other space allow a node to express the following
to its peers:
"(3) I engage in redirection operations on my address and do not
intend to prove conclusively that I do have authorization to use
this address (e.g. RR is ok)"
(3) is a viable tradeoff for a mobile node to make: yes, there are
some vulnerabilities, but it obtains route optimization by being able
to redirect its address with a relatively simple mechanism free of
intellectual property.
For an unsuspecting stationary node that is not interested in
redirecting its address, (3) may not be a viable tradeoff. It
essentially means that the node only obtains the negative side of the
tradeoff (it becomes a potential victim of the vulnerabilities in
RR), as it is not at all interested in the benefit (route
optimization of its addresses).
Montenegro & Nikander Expires October 4, 2002 [Page 4]
Internet-Draft Protecting Against Bidding Down Attacks April 2002
An attacker could just claim that the address is his and insert a
binding cache entry (a host route) into any correspondent node. This
will break communications between the correspondent node and the
stationary node. If, on the other hand, the address expresses either
(1) or (2) above to the correspondent node, this attack is no longer
possible: the correspondent node will expect a cryptographic proof of
authorization. If the attacker can produce it, there are much more
serious problems at hand.
Nevertheless, it is not absolutely necessary to separate the address
space as described above by using the "bit method." It is enough to
require all nodes interested in redirecting their addresses to prove
cryptographically that their address is redirectable. This implies
that ALL redirectable addresses must be "Hash Based Addresses," that
is, they must be derived from a secure hash of some bit sequence (not
necessarily a Public Key), and require proof of that derivation as
part of the redirection procedure (e.g. route optimisation). Since
stationary hosts do not produce their addresses in this manner, they
are protected by the difficulty in inverting the secure hash: it is
prohibitively expensive for attackers to produce derivation proofs
for "stationary" addresses.
The problem is that these "Hash Based Addresses" have IPR concerns.
At the time of this writing it is not at all clear if those issues
will be resolved. Accordingly, this document deals with what the
Mobile IPv6 Security Design Team believes to be the second best
method: the "bit method." Nonetheless, other methods are mentioned
in Section 3.2.
Section 2 discusses the Bidding Down attack, examining its
implications with respect to the mobile node and the correspondent
node. Thus, it motivates a subsequent Section 3 on the defense
mechanisms.
Montenegro & Nikander Expires October 4, 2002 [Page 5]
Internet-Draft Protecting Against Bidding Down Attacks April 2002
2. Bidding Down Attacks
The problem at hand consists of a node that wishes to affect how
another node routes packets to it. Given that the problem is not
limited to Mobile IP, it is worthwhile to adopt a more general model.
Alice is the node that wishes to alter how Bob routes packets to it.
We also assume that there is an attacker, Mallory, that launches the
bidding down attack.
Bidding down attacks exist in general outside the domain of Mobile
IP. The analysis starts with a general model in which it may be more
difficult to implement defenses, and then proceeds to the more
specific Mobile IP model.
Assume Alice and Bob are capable of two flavors of secure exchanges:
"strong" flavor: As part of the exchange, Alice can provide
cryptographical assurances to Bob about some of its properties,
including its address (every single bit in it). This can be
obtained in a variety of manners, infrastructure-less (CGA [6][7])
or infrastructure-based (PKI, key distribution center, trusted
third party, AAA, etc). The exact method used does not matter.
What matters is the requirement that in a strong exchange Alice
can cryptographically prove to Bob certain properties about itself
(including its address). The exchange itself is also integrity
protected. "Strong" schemes under consideration for Mobile IP all
do, of course, satisfy these requirements.
"weak" flavor: As part of the exchange, Alice *cannot* provide
cryptographical assurances to Bob about some of its properties,
including its address.
Alice wants to engage Bob in an exchange, and Mallory wishes to
affect the result of the exchange such that they end up using the
weak flavor.
Let's assume a fixed bit (or bit pattern) in Alice's address (the
"bit method") makes an explicit distinction between addresses used
with the "strong" and "weak" exchanges. The objective is to avoid
bidding down from the "strong" to the "weak" flavor.
Of course, if Alice implements the "strong" exchange, a very valid
policy would be for it not to engage any more in "weak" exchanges.
This simplifies Alice's protocol processing and is more secure
because Alice avoids any risk of falling victim to a bidding down
attack. For a mobile node, this translates to requiring a "strong"
mechanism for route optimization. The mobile node simply forgoes the
benefits of route optimization and limits itself to bidirectional
Montenegro & Nikander Expires October 4, 2002 [Page 6]
Internet-Draft Protecting Against Bidding Down Attacks April 2002
tunneling [2] when it communicates with correspondent nodes that only
implement the "weak" RR mechanism.
If, however, Alice continues to employ the "strong" and "weak"
exchanges, she cannot use the same address for both. Because of the
fixed bit pattern in the address, in essence, she appears to her
peers as two different hosts ("strong" Alice versus "weak" Alice),
depending on which of her two different addresses she uses:
As: address used with the "strong" exchange.
Aw: address used with the "weak" exchange.
At least the interface ID portions of these addresses (lower 64 bits)
will most probably be completely different and uncorrelated. This is
true of CGA [6][7] mechanisms under consideration as "strong"
infrastructureless mechanisms for route optimization. Therefore, it
is not always possible for an observer to derive one address from the
other, although some methods may allow it. If, in fact, the routing
prefix portions of both addresses (higher 64 bits) are also
uncorrelated, the possibility that Mallory can remain "in the middle"
is negligible. An attacker that can achieve such a feat has already
subverted the routing infrastructure to such a degree that it will be
in a position to launch much more serious attacks. Accordingly, if
Alice uses both the "strong" and "weak" mechanisms, it is in her best
interest to make sure that the corresponding addresses are completely
uncorrelated (both the routing prefixes as well as the interface
ID's).
Additionally, if Alice is a mobile node it will also use a care-of
address at its visiting link.
2.1 Man-in-the-Middle Attack (MiTM)
Suppose the following situation:
Alice ==== Mallory ==== Bob
Mallory's convenient location may have been acquired by exploiting
vulnerabilities in neighbor discovery, or by gaining control of a
conveniently located network element (a router, for example). It is
important to point out that routers that carry both incoming and
outgoing traffic for Alice are in an ideal position to launch DoS
attacks.
2.1.1 General Case
The simplest attack is as follows:
Montenegro & Nikander Expires October 4, 2002 [Page 7]
Internet-Draft Protecting Against Bidding Down Attacks April 2002
Alice(As,strong) ===> Mallory X Bob
Alice <== Mallory (weak) X Bob
Alice sends, among other things, its "strong" address, itself an
indication that it wishes to engage in the strong exchange. Mallory
throws this packet away and replies spoofing Bob, indicating a
preference for the weak variant. Notice that if Mallory is on the
path ingress filtering does not apply to this spoofed packet.
Also, this is much simpler than rewriting Alice's address with a
"weak" address and then sending the packet to Bob. Mallory simply
repeats this for any signaling packets to Bob in which Alice uses its
strong address.
The hope is that eventually, Alice will give up and use its weak
address, at which point, Mallory will let the traffic through,
presumably, because it can break the protocol:
Alice(Aw,weak) ===> Mallory ==> Bob
Alice(Aw,weak) <== Mallory <== Bob
The above step is not as obvious as it seems. As explained above,
generally there is no correlation whatsoever between the previous As
address observed by Mallory, and the subsequent Aw address once Alice
gives up and settles for the weak exchange. Mallory would need to
use heuristics, or look at link layer information in order to
establish that this newly observed address Aw belongs to Alice.
Alternatively, Mallory could just be on the lookout for any signaling
exchange carried out with weak addresses in order to exploit them.
The attack depends on Mallory's being able to selectively drop all
the exchange signaling packets from Alice and substitute them with
its own. This also depends on As and Aw using the same route (both
going through Mallory).
2.1.2 Attack in the Mobile IPv6 Case
The above attack is not nearly as easy in MobileIPv6, because it is
much harder for Mallory to selectively drop the exchange signaling
packets from Alice and substitute with its own.
This difficulty stems from the fact that in the RR mechanism, the
mobile node sends simultaneous RR "initialization" messages through
two different routes. The figure below shows a summarized rendition
of the RR exchange. In it, messages 1 (HoTI) and 2 (CoTI) initialize
the RR process. The mobile node reverse tunnels the HoTI via its
Montenegro & Nikander Expires October 4, 2002 [Page 8]
Internet-Draft Protecting Against Bidding Down Attacks April 2002
home agent (first route), and it sends the CoTI directly (second
route). Likewise, the correspondent node responds with parallel
messages by sending the HOT to the mobile node's home address HoA
(which is then intercepted and tunneled to the mobile node's current
location by the home agent), and the COT directly to the mobile node
at its care-of address CoA. The mobile node is able to send a valid
binding update (message 5) only after it receives valid HOT and COT
messages [2].
1. MN(HoA) -> CN: HoTI(HoA, ...)
2. MN(CoA) -> CN: CoTI(CoA, ...)
3. CN -> MN(HoA): HoT(...)
4. CN -> MN(CoA): CoT(...)
5. MN(CoA) -> CN: BU(HoA, CoA, ...)
Of course, if Mallory is on Alice's local link it can discard all its
packets. But this constitutes a DoS attack. To carry out a bidding
down attack, Mallory must be more subtle. It must not to alert Alice
that something out of the ordinary is happening. Thus it needs to be
very selective as to which packets it will act upon.
Because of this it is much safer for Alice to encrypt messages
tunneled through its home agent, as MIPv6 says it SHOULD.
Furthermore, it is much safer to encrypt the tunneled packets, and
not merely the Mobility Header messages. This way Mallory cannot
distinguish between data and signalling packets being tunneled by
Alice through her home agent (HA).
Here, both the strong and weak exchanges share the RR (return
routability) procedure in which Alice and Bob exchange packets in
parallel via topologically independent routes. Since the MN to HA
path should be encrypted, this makes it very difficult for Mallory to
actually remain in the middle (i.e. be able to see and selectively
modify traffic) for all the packet exchanges. Suppose Alice using a
strong address MN is the mobile node, and Bob is the correspondent
node.
Alice initiates the RR exchange by sending two packets simultaneously
(HoTI via the home agent, and CoTI directly to the correspondent
node), both of which express preference for a strong exchange. This
preference is indicated in two ways by the HoTI:
o by the use of a "strong" address, and
o by explicit fields within the signaling packet
The CoTI only uses the latter indication. The above attack would be:
Montenegro & Nikander Expires October 4, 2002 [Page 9]
Internet-Draft Protecting Against Bidding Down Attacks April 2002
strong HoTI: CoA(encrypted tunnel) ===> HA ==> Bob
strong CoTI: CoA ===> Mallory X Bob
Notice that Mallory is no longer "in the middle" because the HoT
packet is encrypted. Mallory may discard only the packet it sees.
In the second phase of the attack, the RR responses to the above
arrive at Alice:
strong HoT: CoA(encrypted tunnel) <=== HA <== Bob
weak CoT: CoA <=== Mallory X Bob
Alice must wait to receive both the HoT and the CoT before proceeding
with the RR procedure. It will see two conflicting replies from Bob.
In particular, it is quite suspicious that the safe reply (the HoT
via the encrypted tunnel from its HA) indicates a preference for a
strong exchange, while the CoT indicates the opposite. This is
already a very strong indication that an attack is under way.
However, if Alice is not encrypting, or if it is selectively
encrypting only the signaling portion of the packets, it is possible
for Mallory to launch the attack. Namely, it can discard signaling
packets from Alice (HoTI and CoTI) and reply with its own indicating
a preference for a weak exchange. In this case, both HoT and CoT
would be consistent, and Alice might restart the RR procedure using
its weak address in a subsequent HoTI.
2.1.3 Mallory situated between the Home Agent and Bob
The above procedure is particularly important in this case. In this
situation, RR is known to be breakable, and if Mallory is able to
place itself in the middle (with the ability to discard packets
selectively) then there is no further protection. However, if
neighbor discovery is secure in the future, this may be very
difficult for Mallory to achieve.
In this case, the required retransmissions will give the mobile node
a chance to hear back from the real correspondent node in case it
does in fact support the strong exchange. Simply put, Alice must
handle bidding down attacks by being very stubborn and insisting on
(and re-requesting) a strong exchange. Protection on Bob's side is
much simpler. It simply hinges on the fact that Bob will never
engage in weak exchanges with nodes whose address have the bits set
to indicate preference for a strong exchange.
Montenegro & Nikander Expires October 4, 2002 [Page 10]
Internet-Draft Protecting Against Bidding Down Attacks April 2002
2.2 Impostor Attack
Mallory === Bob
Alice .../
Here, Alice may not be actively communicating with Bob. It need not
even be on line. Mallory poses as Alice and tries to convince Bob.
We assume that Alice is either a stationary node that does
participate in redirection procedures at all, or, if it does, that it
wishes to use something other than the "weak" flavor: it does not use
the baseline RR as its binding update authorization method, instead
preferring a much stronger alternative.
The attack starts by the attacker (Mallory) sending a fake request to
the correspondent node (Bob), indicating the desire to use RR in the
request. The correspondent node (Bob), not having any knowledge of
the true desires of the mobile node (Alice) accepts this.
1. Attacker sends first message(s) of RR to the correspondent node
(the HoTI and CoTI messages). In this network scenario both
messages can be sent from the attacker's location towards the
correspondent node. This is because the attacker can place
itself between the correspondent node and the CoA by carefully
choosing the care-of address it uses in RR. This can be done
easily, for example, by selecting an address from the network
where the attacker is located.
2. The correspondent node inspects the messages and continues the RR
protocol by sending its COT and HOT messages.
3. Once the attacker receives the responses it is in a position to
send a valid binding update.
As a result, the attacker has established a binding cache entry for
the mobile node's (Alice's) address at the correspondent node. It
only had to use RR regardless of the mobile node's preference for a
stronger mechanism.
Montenegro & Nikander Expires October 4, 2002 [Page 11]
Internet-Draft Protecting Against Bidding Down Attacks April 2002
3. Defending Against Bidding Down Attacks
As can be seen from the analysis above, bidding down attacks have
different characteristics depending on whether they are looked at
from the point of view of the mobile node or the correspondent node.
Accordingly, they must use different mechanisms. The two following
sections detail the defenses used by the mobile node (Step Down
Procedure) and the correspondent node (Bit Method).
3.1 Step Down Procedure
By following certain rules a mobile node reduces the possibility of a
bidding down attack and remains in control. This is called the step
down procedure.
When Mallory is on the same link as mobile node Alice it can launch
attacks to make her desist of the strong mechanism and settle for the
weak one. In order to prevent falling victim to these attacks, Alice
must be very careful as to the conditions under which it will give up
on using the strong mechanism.
To begin with, above it has been noted that Alice MUST have valid HoT
and CoT packets that indicate preference for the weak exchange. In
the event that Mallory also produces false HoT packets, Alice MUST be
able to give preference to those received from its HA under the
protection of the ESP tunnel. It is not clear how this information
is kept with the packet after it has been decapsulated and extracted
from its ESP protection. Because Mallory could be dropping packets
from the HA, Alice MUST handle bidding down packets in similar manner
to how it handles lost packets and the corresponding retransmissions.
The rules for a mobile node to carry out a step down procedure are:
o Both a valid HoT and CoT are required to initiate a step down
procedure.
o The procedure requires two more pairs of related HoT and CoT
packets (should we only require one more?).
o Only after this complete step down procedure does a mobile node
heed a correspondent's preference for a weak exchange and begin
the corresponding weak RR process (in which the mobile node uses
its weak address) or simply by desisting on using route
optimization.
If at any time during the step down procedure the mobile node
receives any messages which specify preference for something other
than RR (a stronger exchange), the step down procedure is aborted.
Montenegro & Nikander Expires October 4, 2002 [Page 12]
Internet-Draft Protecting Against Bidding Down Attacks April 2002
This means that the mobile node will not engage in a weak exchange.
Of course, it may also desist on using route optimization.
3.2 Bit Method
The first time Bob receives a packet sent by Alice, he has no other
knowledge about her but the packet itself. In particular, the only
information he has about Alice is the source IP address in the
packet. If Alice is a stationary node, she does not want her address
to be redirectable, so Bob must not install a binding cache entry for
it. To prevent would-be attackers from "redirecting" Alice's
address, Bob needs to learn if her address is indeed redirectable.
He has several options:
1. He can query DNS, do a reverse lookup, and hope to learn
something useful. However, this may be expensive in terms of
time and number of packets, causing packets sent to the DNS
server that serves the reverse map for Alice's address, and
thereby somewhat dangerous from the Denial-of-Service point of
view. Additionally, secure DNS is not widely deployed, and
therefore he usually cannot fully trust the results.
2. He can try to use some other infrastructure, such as AAA, to
obtain some information about Alice. However, this method
requires that Alice participates in the same infrastructure,
which, in general, is unlikely for a number of years to come.
Secondly, this method has the same drawbacks as DNS lookups,
generating delay and extra traffic.
3. He can send a probe to Alice, checking that there indeed is
somebody who answers at her address. TCP SYN ACK is basically
such a probe, and so are the new Mobile IPv6 RR packets (HoTI,
CoTI, HoT, CoT). The drawback of this method is that it does not
say anything about Alice's address being redirectable or not (the
whole point of this exercise). Notice that once Bob knows that
Alice's address is redirectable, this step is an integral part of
that process, which is why it is part of RR.
4. He can require that, as part of the address redirection
procedure, Alice prove in a cryptographically secure manner that
her address is indeed redirectable. The problem is that the only
known way to do this in an infrastructureless manner raises
intellectual property concerns whose implications are not clear.
5. He can have a look at the address, and try to deduce something
from the address itself. Currently, he can learn whether Alice
is using a link local, site local or global address, whether
Alice's address is supposed to contain a globally unique
Montenegro & Nikander Expires October 4, 2002 [Page 13]
Internet-Draft Protecting Against Bidding Down Attacks April 2002
interface ID, etc.
The whole idea of the "bit method" is to extend the last option above
so that Bob can tell by looking at the address if it is redirectable
or not.
The "bit method" allocates a bit (or a bit pattern) in the IPv6 64
bit Interface Identifier field, with the intention of later defining
a method that allows peer hosts to securely find out what security
protocols, and perhaps other functional features, the host using the
address supports. That is, if a host's address has the bit set, the
host indicates to its peers either of the following:
It does not use "redirection procedures" to influence how packets
destined to itself are routed by a peer. Currently, the only such
"redirection procedure" proposed for widespread deployment is the
Mobile IPv6 route optimization procedure. Other similar
applications of such procedures may appear in the future (for
example for certain anycast implementations). In the absence of
any further signaling, the peer (correspondent node) assumes this
is the case.
If the node does use "redirection procedures", then it only does
so by using a "strong" mechamism as defined above, i.e. using
further signaling and strong cryptographic mechanisms.
If the bit is cleared in the host's address, it relies on the default
("weak") mechanisms. In the case of Mobile IPv6, this is the RR
procedure.
Note that an active attacker on the path between Alice and Bob is
able to clear a set bit. However, that changes the address, and
Alice is not going to answer to any possible replies sent by Bob.
Thus, the bit prevents the attacker from impersonating as Alice and
fooling Bob to use the less secure protocol.
If the bit is set, the correspondent host MUST require a
cryptographic assurance before heeding any redirects for the address
in question. Failure to do so means the correspondent host MUST NOT
heed any redirects. This eliminates any potential misuse of Return
Routability to attack a given address, and prevents the correspondent
node from being bid down.
Montenegro & Nikander Expires October 4, 2002 [Page 14]
Internet-Draft Protecting Against Bidding Down Attacks April 2002
4. Security Considerations
This note deals almost exclusively with security issues. The issue
at hand is that the baseline Mobile IPv6 route optimization
mechanism, RR, may "pollute" the Internet at large with some
additional threats. These affect all hosts (not just mobile hosts).
Any protection must be mandated as part of the baseline RR mechanism.
We discuss the "bit method" in which a bit or bit pattern in the
address prevents the use of RR to attack stationary hosts. Coupled
with the "step down" procedure, it alleviates the attack against
mobile nodes that implement route optimization mechanisms stronger
than RR. Unlike the latter which relies on trust in the routing
infrastructure in order to authorize binding updates, the "strong"
mechanisms all employ cryptographic assurances of some sort or other.
This document does not discuss the "bidding aside" attacks, in which
an attacker forces the use of a "strong" mechanism instead of another
also "strong" mechamism. Presumably, it would do so because not all
such mechanisms are equally strong, so by choosing judiciously, an
attacker can lower the bar. Nevertheless, this bar is sufficiently
much higher than the RR level, since it requires carrying out
successful cryptographic attacks. If an attacker is able to do this,
it can basically attack the Internet at will. Furthermore, careful
review before approving any future optional "strong" mechamisms can
assure that the bar remains high enough.
Montenegro & Nikander Expires October 4, 2002 [Page 15]
Internet-Draft Protecting Against Bidding Down Attacks April 2002
5. Acknowledgements
This document "borrows" extensively from Mobile IPv6 security Design
Team write-ups [1] and discussions. Accordingly, it owes much to the
other members (besides the authors) of the design team, Jari Arkko
and Erik Nordmark. It also benefits from discussion on the Mobile IP
and IPv6 mailing lists. Brian Carpenter's observations in the latter
led to the the step down procedure.
Montenegro & Nikander Expires October 4, 2002 [Page 16]
Internet-Draft Protecting Against Bidding Down Attacks April 2002
References
[1] Arkko, J., Nordmark, E., Nikander, P. and G. Montenegro, "Mobile
IPv6 Security Design Team Writeups", see http://www.piuha.net/
~jarkko/publications/mipv6/, April 2002.
[2] Perkins, C. and D. Johnson, "Mobility Support in IPv6",
Internet-Draft http://www.ietf.org/internet-drafts/draft-ietf-
mobileip-ipv6-16, March 2002.
[3] Arkko, j. and T. Aura, "MIPv6 BU Attacks and Defenses", draft-
aura-mipv6-bu-attacks-01 (work in progress), March 2002.
[4] Devarapalli, V., "Future Attacks and Threats", Thread on the
Mobile IP alias http://playground.sun.com/mobile-ip/WG-archive/
frm04733.html, January 2002.
[5] Kempf, J. and E. Nordmark, "Threat Analysis for IPv6 Public
Multi-Access Links", draft-kempf-ipng-netaccess-threats-00 (work
in progress), November 2001.
[6] Roe, M., Aura, T., O'Shea, G. and J. Arkko, "Authentication of
Mobile IPv6 Binding Updates and Acknowledgments", draft-roe-
mobileip-updateauth-02.txt (work in progress), February 2002.
[7] Montenegro, G. and C. Castelluccia, "Statistically Unique and
Cryptographically Verifiable (SUCV) Identifiers and
Addresses.", NDSS 2002, February 2002.
Authors' Addresses
Gabriel Montenegro
Sun Labs, Europe
29, chemin du Vieux Chene
38240 Meylan
France
EMail: gab@sun.com
Pekka Nikander
Ericsson Research NomadicLab
Espoo
Finland
EMail: Pekka.Nikander@nomadiclab.com
Montenegro & Nikander Expires October 4, 2002 [Page 17]
Internet-Draft Protecting Against Bidding Down Attacks April 2002
Full Copyright Statement
Copyright (C) The Internet Society (2002). 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 assigns.
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
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.
Montenegro & Nikander Expires October 4, 2002 [Page 18]
| PAFTECH AB 2003-2026 | 2026-04-23 20:08:08 |