Internet DRAFT - draft-zhao-mobopts-rr-ext
draft-zhao-mobopts-rr-ext
Mobopts Working Group F. Zhao
Internet-Draft S F. Wu
Expires: January 12, 2006 UC Davis
J. Zhou
Institute for Infocomm Research
S. Jung
Soongsil University
July 11, 2005
Improvement on Security and Performance of MIP6 Return Routability Test
draft-zhao-mobopts-rr-ext-00
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on January 12, 2006.
Copyright Notice
Copyright (C) The Internet Society (2005).
Abstract
In this draft, we propose several extensions to improve the security
and performance of MIP6 Return Routability test. Our proposal
enables CN and MN to promptly and reliably detect the on-path attack
and reduce the signaling overhead in a secure, efficient and back-
Zhao, et al. Expires January 12, 2006 [Page 1]
Internet-Draft MIP6 RR Extensions July 2005
compatible way. The core idea is to use hash chain to replace home
test procedure in some circumstances and we carefully integrate hash
chain into original MIP6 RR test without introducing new
vulnerabilities. Although it does slightly increase the management
cost of CN, we show that the extended RR test is more secure and more
efficient than other approaches.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Analysis of MIP6 Return Routability Test . . . . . . . . . . . 5
2.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.2 Analysis . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.2.1 Statelessness . . . . . . . . . . . . . . . . . . . . 6
2.2.2 Longer routing path of home test message . . . . . . . 6
2.2.3 High susceptibility to home network failure . . . . . 6
3. Idea, contributions, notations and acronyms . . . . . . . . . 7
3.1 One-way hash chain . . . . . . . . . . . . . . . . . . . . 7
3.2 Motivations and contributions . . . . . . . . . . . . . . 8
3.2.1 Security improvement . . . . . . . . . . . . . . . . . 8
3.2.2 Reducing the signaling overhead . . . . . . . . . . . 8
3.3 Notations and acronyms . . . . . . . . . . . . . . . . . . 9
4. Hash-chain based detection mechanism . . . . . . . . . . . . . 10
4.1 Proposal . . . . . . . . . . . . . . . . . . . . . . . . . 10
4.2 CN operations . . . . . . . . . . . . . . . . . . . . . . 11
4.3 MN operations . . . . . . . . . . . . . . . . . . . . . . 12
4.4 Hash chains for both MN and CN . . . . . . . . . . . . . . 12
4.5 Hash Chain Management . . . . . . . . . . . . . . . . . . 13
4.6 Security analysis . . . . . . . . . . . . . . . . . . . . 13
4.7 Summary and future works . . . . . . . . . . . . . . . . . 15
5. Reducing signaling overhead . . . . . . . . . . . . . . . . . 17
5.1 With CoTi/CoT message . . . . . . . . . . . . . . . . . . 17
5.2 With Binding Refresh message . . . . . . . . . . . . . . . 18
5.3 Security analysis . . . . . . . . . . . . . . . . . . . . 19
5.3.1 Partial control on the MN-CN path . . . . . . . . . . 19
5.3.2 Full control on the MN-CN path . . . . . . . . . . . . 20
5.3.3 Future address stealing attack . . . . . . . . . . . . 20
5.4 Summary . . . . . . . . . . . . . . . . . . . . . . . . . 20
6. Related works . . . . . . . . . . . . . . . . . . . . . . . . 22
7. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 23
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 23
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 24
Intellectual Property and Copyright Statements . . . . . . . . 26
Zhao, et al. Expires January 12, 2006 [Page 2]
Internet-Draft MIP6 RR Extensions July 2005
1. Introduction
The key words MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD,
SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL in this document are to be
interpreted as described in RFC2119 [1].
With the proliferation of mobile networking devices, the Internet is
undergoing the most dramatic change ever since it was born. Mobility
provides the convenience, improves the productivity and changes our
life fundamentally.
It is desired that communication sessions seamlessly continue during
the movement. However, under the original TCP/IP protocol suite, IP
address serves as both locator and identity, which inevitably causes
the existing upper layer connections to be disrupted when the node
changes its point of attachment to the Internet.
IETF MIP6 working group has developed RFC 3775 to support mobility in
IPv6 network by identifying each mobile node with a relatively
permanent home address and addressing the same node with a care-of
address acquired during its movement. The former allows a mobile
node to be always reachable, however, through a longer routing path
when it is away from the home network while the latter allows a
mobile node to be reachable at its current location without passing
through home network, which is referred to as Route Optimization mode
in MIP6 protocol.
However without the careful design, MIP6 Route Optimization support
could introduce various forms of new vulnerabilities, e.g. stealing
attack and flooding attack etc [4]. RFC 3775 designs the Return
Routability (RR) Test, a lightweight and infrastructure-less
authentication mechanism, to resist most attacks without requiring
the existence of security association between Mobile Node (MN) and
Correspondent Node (CN), which ensures the universal deployment of
route optimization.
The RR test still leaves a lot to be desired. Firstly, it is
vulnerable to on-path attackers and the current standard does not
protect MN and CN further from the incurred attacks. Secondly, the
signaling overhead poses challenges to resource-constrained mobile
node and bandwidth-scarce wireless network given the short lifetime
of Binding Cache Entry (at most seven minutes) even though MN does
not change its location since the last Binding Update with CN.
Thirdly the signaling delay caused by the RR test increases the
handover delay, which may degrade the performance of delay-sensitive
applications, such as VoIP.
This draft focuses on the first two issues currently. We propose
Zhao, et al. Expires January 12, 2006 [Page 3]
Internet-Draft MIP6 RR Extensions July 2005
several extensions to enable CN and MN to promptly detect the on-path
attack and reduce the signaling overhead. The RR test related
signaling latency during handover will be addressed in a future
version.
The rest of the draft is organized as follows. In Section 2, we
analyze the MIP6 RR test with emphasis on the disadvantages of the
current approach. Section 3 summarizes our idea, motivations,
contributions and notations as well as acronyms. We present a hash
chain based detection mechanism to improve the security of MIP6 RR
test and another approach to reduce the signaling overhead in Section
4 and Section 5, respectively. The related works are summarized in
Section 6 and finally the whole draft is concluded in Section 7.
Zhao, et al. Expires January 12, 2006 [Page 4]
Internet-Draft MIP6 RR Extensions July 2005
2. Analysis of MIP6 Return Routability Test
In this section, we briefly review and analyze the MIP6 RR test. The
detailed specification of MIP6 RR test can be found in RFC 3775.
2.1 Overview
Route Optimization in MIP6 requires that MN inform the binding
between its identity and its location to CN and CN verify the
correctness of the binding information received in a secure and
efficient way. All must be achieved without the pre-existing
security association between MN and CN. This poses two questions to
CN when it receives the binding information:
1) How can CN ensure that MN is at the location it currently claims?
2) How can CN ensure that the information is from a legitimate MN
rather than a malicious third party?
MIP6 RR test addresses the first question by care-of address test.
By sending a care-of keygen token to MN's care-of address and
verifying whether MN receives it successfully later, CN can ensure
that either MN is really at the care-of address it claims, or there
is another entity communicating with CN on the path between CN and
the care-of address MN claims.
The second question requires MN authenticate itself to CN during the
Correspondent Binding Update procedure. Given the unavailability of
pre-existing security association between MN and CN (or any other
form of global trust relationship, e.g. PKI), MIP6 RR test adopts
home address test for CN to verify whether MN is reachable at its
home address by sending a home keygen token to MN's home address and
verifying whether MN receives it successfully later. Because home
address serves as an identity of MN, by presenting the proof that MN
can be reachable at home address, MN can authenticate itself to CN.
Please note that the signaling messages during home address test are
protected by the pre-existing security association between MN and its
HA, but are not protected when on the path between HA and CN. Thus
given a successful home address test, CN can ensure it is
communicating with either MN or another entity on the path between CN
and MN's home network.
As a stateless and lightweight approach, address test leaves the MIP6
Route Optimization mechanism vulnerable to those launched by on-path
attacker. The design goal of MIP6 Route Optimization is to achieve
the same security level in MIP6 network as the normal IPv6 network.
Zhao, et al. Expires January 12, 2006 [Page 5]
Internet-Draft MIP6 RR Extensions July 2005
2.2 Analysis
2.2.1 Statelessness
MIP6 RR test is designed to be stateless in that each round of RR
test is independent from each other. While the statelessness feature
enables CN to have minimal management of Binding Cache entry, MN has
to re-run the complete MIP6 RR test procedure once the Binding Cache
expires every several minutes (at most seven minutes). There are two
consequences: 1) Since MN keeps repeating the same message exchanges
with CN every time without utilizing the states previously
successfully established at CN even a little bit, the signaling
overhead caused may prove to be a significant cost to resource-
constrained mobile devices and bandwidth-limited wireless network. 2)
The stateless feature makes CN unable to detect the on-path attack as
CN just simply verifies the received Binding Update message without
comparing with the previously established state, which makes MIP6
network slightly less secure than the normal IPv6 network.
Please note less statelessness does not necessarily cause the
vulnerability to state-exhaustion attack. Actually they are two
different issues. To avoid the state-exhaustion attack we should
postpone the establishment of new states until the correct point
during the message exchanges while to make MIP6 RR test less
stateless means to explore the previously successfully established
states and the risk of state-exhaustion attack is expected to be
taken care of during each round of RR test.
2.2.2 Longer routing path of home test message
In MIP6 RR test, home address test involves forwarding the message
between MN and CN via MN's home network (in short, HA in the
following) always, which results in a longer route taken by the home
address test message than that by the care-of test message. The
longer delay caused by home address test procedure may degrade the
application performance when MN starts the Route Optimization with
CN.
2.2.3 High susceptibility to home network failure
Another side effect of home address test is that NEMO Route
Optimization is highly susceptible to home network failure. Thus
when the home network is down or just congested, MN may have
difficulty to communicate with CN even though there is an available
route path between MN and CN.
Zhao, et al. Expires January 12, 2006 [Page 6]
Internet-Draft MIP6 RR Extensions July 2005
3. Idea, contributions, notations and acronyms
In order to address the limitations of MIP6 RR test analyzed in the
previous section, one has to turn to an alternative approach for CN
to verify that MN actually legitimately owns the claimed home address
securely, efficiently and reliably. To this end, we propose to use
hash chain to replace the need of home address test in some
circumstances. This section firstly describes the hash chain, the
core mechanism we use in this draft, and then summarizes our
motivations and contributions of this draft. Finally we introduce
the notations and acronyms used in this draft for the ease of
description.
3.1 One-way hash chain
Hash chain is a widely used security primitive, for example, one-time
password protocol, multicast authentication mechanism [8] and secure
routing protocols. Assume that one wants to generate a hash chain of
length k+1. It generates a random number h_k firstly and then
repeatedly applies the one-way hash function, H, for example, h_k-
1=H(h_k), h_k-2=H(h_k-1), ... , h_0=H(h_1). When needed, the
elements in the chain are revealed in the order of h_0, h_1, ... ,
h_k.
One-way hash chain has the following properties:
1) Due to the irreversibility of one-way hash function, even though
the attacker eavesdrops h_i, it is still cryptographically impossible
for it to derive h_j from h_i where j>i. This property guarantees
that once the initial hash element h_0 is committed, no one other
than the original generator can provide a valid and fresh hash chain
element unless by eavesdropping or interception. Thus it provides a
certain level of identity authentication.
2) On the contrary, anyone can easily confirm that h_j is part of the
chain if h_i=H(h_j)^(j-i) where j>i. Compared with other
cryptography primitive, hash operation is much cheaper and faster,
which reduces the risk of being Denial-of-Service attacked.
3) One can create the chain all at once and store each element of the
chain, or just store h_k together with the sequence number of the
next element in the chain and generate the element on demand (Thanks
to the fast hash operation). There exist other approaches that can
help reduce storage cost with a small computation penalty. (It is
possible to use log(k) storage and log(k) computation to access an
element.) The development of technology is also expected to meet the
increasing requirement of battery and memory for MN to maintain such
kind of one-way hash chain.
Zhao, et al. Expires January 12, 2006 [Page 7]
Internet-Draft MIP6 RR Extensions July 2005
3.2 Motivations and contributions
3.2.1 Security improvement
Although MIP6 RR test effectively limits the successful attackers to
those that are able to access the critical path, MIP6 network is
still a little bit less secure than IPv6 network. For example, an
attacker that is able to only eavesdrop on the HA-CN path can
eventually intercept thus completely control the traffic between MN
and CN.
MIP6 RR test does not provide any further protection against those
"powerful" attackers, thus MN and CN cannot take any prompt and
appropriate response to recover from the attacks if possible or
reduce the damage as much as possible. For example, MN/CN can detect
the disruption of the communication only by observing the traffic
characteristics. (The disruption/redirection attack may be indicated
by the time-out signal; however, MN/CN has to wait the timer to
expire.) Moreover, since MN/CN does not know the root-cause of the
anomaly, MN/CN may have to retry for several times before deciding
whether there is an attack or link failure and what response to take,
switching to bidirectional tunneling mode or just giving up. In
summary, this kind of heuristic method is slow.
Another important issue is that a detection method must avoid "false
positive" and "false negative" even with various types of attack
symptoms and dynamic traffic characteristics observed especially when
MN moves around. Here we call a "false positive" if it is reported
as an attack but actually not; Similarly, we call a "false negative"
if there is an attack but not detected.
In this draft, we propose an efficient and effective detection
mechanism for both CN and MN to promptly, accurately and reliably
detect attacks that could compromise the security of MIP6 RR test and
thus let CN and MN take the appropriate response to mitigate and
recover from attacks. For example, CN may send the packets to the
home address, and thus MN can receive the traffic forwarded by HA,
which follows a non-optimal route but is still better than the
disruption of communication (100% packet loss).
3.2.2 Reducing the signaling overhead
In RFC 3775 the lifetime of Binding Cache Entry (and nonce, token
etc.) is limited to a few minutes, which requires MN to repeat MIP6
RR test procedure every several minutes even if MN does not change
its location since last successful Binding Update with CN. While it
is necessary to mitigate some kinds of attacks, such as future
address stealing attack and time shifting attack, it does cause a lot
Zhao, et al. Expires January 12, 2006 [Page 8]
Internet-Draft MIP6 RR Extensions July 2005
of signaling overheads, which could become a big burden to resource-
constrained mobile nodes and the bandwidth-scarce wireless network.
There could be two different ways to reduce the signaling overhead,
one is to extend the lifetime of Binding Cache entry; the other is to
reduce the number of signaling messages needed. The first method is
not acceptable, as it will increase the security risks. In this
draft, we focus on the latter method especially when MN does not
change its location since the last Binding Update to CN. Our
approach is to use hash chain to eliminate the necessity of Home Test
procedure but still provides the same security protection as before.
3.3 Notations and acronyms
Throughout this draft, the following notations and acronyms are used:
CoA: the care-of IP address of MN
HoA: the home address of MN
CNA: the IP address of CN
BU: Binding Update message
BA: Binding Acknowledgement message
Kbm: the Binding Management key
S_MN: the sequence number of the current element in MN's one-way
hash chain
H_MN(S_MN): the current element in MN's one-way hash chain
S_CN: the sequence number of the current element in CN's one-way
hash chain
H_CN(S_CN): the current element in CN's one-way hash chain
N: the largest number of retries if MN or CN does not receive the
reply within a certain time period
M: the largest number of hash functions that MN or CN is willing
to perform, usually M > N
Zhao, et al. Expires January 12, 2006 [Page 9]
Internet-Draft MIP6 RR Extensions July 2005
4. Hash-chain based detection mechanism
MIP6 RR test is vulnerable to the attackers that are able to access
certain critical paths. Although it is difficult to completely
resist those powerful attackers (The inter-domain coordination might
be needed eventually.), we propose a simple but effective detection
mechanism to enable CN and MN to detect the attack promptly and then
take the appropriate response. The rationale is as follows: CN is in
the best position to detect the attack attempts because in order for
the attacks (e.g. DoS flooding attack and redirection attack) to
succeed, the attacker must change the state stored in CN. Therefore
the idea is that in order for CN to accept a new Binding Update,
either a valid MN or an attacker must provide the cryptographically
sound proof of the previous successful Binding Update to CN if any.
If the correctness of this proof cannot be verified by CN, CN may
disable the relevant Binding Cache entry and forward the data packet
to its home address instead.
4.1 Proposal
MN generates a hash chain for each pair of <HoA, CN> so that MN can
use multiple HoAs to communicate with different CNs. The primary
differences from the original MIP6 RR test are that the current hash
chain element generated by MN is included in the BU message and CN
extends the Binding Cache entry with two fields to store the current
element in MN's hash chain and the corresponding sequence number.
MN generates the BU message as follows and sends it to CN.
BU:
o Source IP address: CoA
o Destination IP address: CNA
o {HoA | S_MN | home_nonce_index | careof_nonce_index | H_MN(S_MN) |
MAC}
o MAC = HMACSHA1(Kbm, (CoA | CNA | BU))
If MN requests the Binding Acknowledgement, CN generates the BA
message based on the verification result.
BA:
o Source IP address: CNA
Zhao, et al. Expires January 12, 2006 [Page 10]
Internet-Draft MIP6 RR Extensions July 2005
o Destination IP address: CoA
o {S_MN | MAC}
o MAC = HMACSHA1(Kbm, (CoA | CNA | BA))
4.2 CN operations
When CN receives the BU message, CN firstly generates Kbm and then
verifies the MAC. If the result is positive, CN performs the
following procedure to verify the newly received hash chain element,
H_MN(S_MN):
1. CN searches the Binding Cache by using MN's HoA as the primary
key.
2. If it does not exist, CN accepts the BU message and creates a new
Binding Cache entry and forwards the data packets destined to
this HoA based on MIP6 RO protocol.
3. If it does exist, CN verifies H_MN(S_MN) received in the BU
message with the old hash chain element, H_MN(S_MN') stored in
the Binding Cache as follows:
* If S_MN' >= S_MN, CN discards this BU message because it is a
replayed message.
* If S_MN' < S_MN <= S_MN'+M and H_MN(S_MN') ==
H_MN(S_MN)^(S_MN-S_MN'), CN believes this BU message is valid,
thus it updates the Binding Cache Entry with S_MN and
H_MN(S_MN) and then sends the BA message if requested.
* If S_MN' < S_MN <= S_MN'+M and H_MN(S_MN') <>
H_MN(S_MN)^(S_MN-S_MN'), CN realizes that there is an attacker
that can successfully finish the RR test; however, CN is not
sure whether the currently received BU message is from the
attacker or a valid MN. Thus CN disables this entry,
indicates the reason in the BA message if requested and
forwards the data packets to the home address. CN's local
policy may decide to accept the new BU message for this HoA
later again or not, for example, after either the current
session is ended or a certain time period.
* If S_MN'+M < S_MN, CN realizes that the number of hash
computation needed is too large, in order to avoid the DoS
attack, CN disables this entry, indicates the reason in the BA
message if requested and forwards the data packets to the home
Zhao, et al. Expires January 12, 2006 [Page 11]
Internet-Draft MIP6 RR Extensions July 2005
address. CN's local policy may regulate whether to refuse
accepting the Route Optimization operation from this HoA
forever or to freeze for a certain time period after which it
may start to accept the new BU message for this HoA again.
4.3 MN operations
When MN does not receive the BA message within a certain time period,
MN may retry to send the BU message in case that the previous BU
message is dropped due to the network congestion. However, MN must
use a new hash chain element in this new BU message in order to
invalidate the old hash chain element because an attacker could
intercept it for the future attack.
BU:
o Source IP address: CoA
o Destination IP address: CNA
o {HoA | S_MN+1| home_nonce_index | careof_nonce_index |
H_MN(S_MN+1) | MAC}
o MAC = HMACSHA1(Kbm, (CoA | CNA | BU))
Please note that if MN cannot receive the BA message after retrying
for N times, MN should switch to the Bidirectional tunneling mode.
4.4 Hash chains for both MN and CN
CN may also use hash chain for MN to authenticate the origin and
freshness of BA message. CN may generate a pool of hash chains
proactively, and then randomly select one for the signaling between
MN and CN after successfully verifying the BU message from MN. MN or
CN may communicate with multiple nodes and thus simultaneously
maintain multiple hash chains, each of which can be uniquely
identified by a pair of home address of MN and IP address of CN, i.e.
<HoA, CNA>.
Except that the BU and BA messages are extended to include the first
hash chain elements, H_MN(S_MN) and H_CN(S_CN), other messages are
still as same as in RFC 3775. MN sends the BU message as follows:
BU:
o Source IP address: CoA
Zhao, et al. Expires January 12, 2006 [Page 12]
Internet-Draft MIP6 RR Extensions July 2005
o Destination IP address: CNA
o {HoA | S_MN | home_nonce_index | careof_nonce_index | H_MN(S_MN) |
MAC}
o MAC = HMACSHA1(Kbm, (CoA | CNA | BU))
When CN receives and verifies the BU message successfully, CN will
record S_MN as well as H_MN(S_MN) and reply with the following BA
message if requested.
BA:
o Source IP address: CNA
o Destination IP address: CoA
o {S_CN | H_CN(S_CN) | MAC}
o MAC = HMACSHA1(Kbm, (CoA | CNA | BA))
When MN receives and verifies the BA message successfully, MN will
record S_CN and H_CN(S_CN).
4.5 Hash Chain Management
The hash chain can be depleted after a long time use. MN can start a
new hash chain with CN by sending the last element in the old hash
chain together with the first element in the new hash chain in the BU
message.
Hash chain should not be lost due to the reboot of CN or MN. While
it is not a big problem for CN as it is just a fresh start, it is
better for MN to store the hash chain in the safe hardware so that
the synchronization between MN and CN can be restored.
CN must verify the hash chain element in the BU message even if S_MN
is not consecutive in order to recover from the BU packet loss due to
the network congestion. However in order to prevent DoS attack the
difference between the new S_MN and the old S_MN should not be more
than M.
4.6 Security analysis
Our approach inherits all the underlying assumptions of the original
MIP6 RR test, for example, no infrastructure support, pre-existing SA
between MN and HA but no pre-existing SA between MN and CN or between
HA and CN, no ingress filtering and compliant HA and CN.
Zhao, et al. Expires January 12, 2006 [Page 13]
Internet-Draft MIP6 RR Extensions July 2005
The successful detection of attack depends on the successful
commitment of the first hash element. The security of the first time
Binding Update procedure still depends on the diverse routing paths
and IP address test, however the use of hash chain still provides an
additional level of protection.
In the following we compare the security strength of the original RR
test and the extended RR test given the different powers of attacker.
We categorize the power of attackers into two categories:
Full control: the attacker can intercept, drop and of course
eavesdrop the traffic passing by. For example, the attacker
controls a router in the Internet.
Partial control: the attacker can only eavesdrop the traffic that
can finally arrive at the intended destination successfully.
The attacker could have different powers on the different paths.
Moreover, the attacker could move from one path to the other; or it
could have a conspirator on the other path; or these two paths are
kind of overlapping with each other and the attacker is attached to
the common part of these two paths.
o Partial control on HA-CN path only:
* Orignal RR test: The attacker can have full control of the
traffic.
* Extended RR test: Detected. The attacker still has the partial
control only.
o Partial control on MN-CN path only:
* Orignal RR test: The attacker cannot have full control of the
traffic.
* Extended RR test: The attacker cannot have full control of the
traffic.
o Partial control on both HA-CN and MN-CN:
* Orignal RR test: The attacker can have full control of the
traffic.
* Extended RR test: Detected, The attacker still has the partial
control only. (The spoofed BA message can be detected if CN's
hash chain is used.)
Zhao, et al. Expires January 12, 2006 [Page 14]
Internet-Draft MIP6 RR Extensions July 2005
o Full control on HA-CN path only:
* Orignal RR test: The attacker can have full control of the
traffic.
* Extended RR test: Detected. But the attacker still has full
control of traffic if CN sends to MN's home address.
o Full control on MN-CN path only:
* Orignal RR test: The attacker already has full control of the
traffic as long as MN runs in the RO mode.
* Extended RR test: The attacker already has full control of the
traffic as long as MN runs in the RO mode. But any
modification can be detected.
o Full control on both HA-CN and MN-CN path:
* Orignal RR test: The security of MIP6 RR test cannot be held
due to the power of attacker.
* Extended RR test: The security of MIP6 extended RR test cannot
be held due to the power of attacker.
o Partial control on the HA-CN path and full control on the MN-CN
path:
* Orignal RR test: The attacker can have full control of the
traffic.
* Extended RR test: The spoofed BA message cannot be detected.
The attacker can have full control of the traffic temporally.
MN may recover from the attack after retries.
o Partial control on the MN-CN path and full control on the HA-CN
path:
* Orignal RR test: The attacker can have full control of the
traffic.
* Extended RR test: Detected. The attacker has full control of
traffic if CN sends to HoA.
4.7 Summary and future works
This hash chain based detection mechanism can be combined with other
Zhao, et al. Expires January 12, 2006 [Page 15]
Internet-Draft MIP6 RR Extensions July 2005
network diagnosis mechanisms to further discover the location of
attacker, and then other kind of mechanisms, e.g. source routing, can
be triggered to bypass that path. Moreover the state machine of MN
and CN operations will be made later.
While Section 5 presents an approach for MN to promptly renew its
Binding Cache entry when it does not change its location, the
extended RR test introduced in this section can be used in any
situation, especially when MN changes its location since the last
Binding Update with CN.
Zhao, et al. Expires January 12, 2006 [Page 16]
Internet-Draft MIP6 RR Extensions July 2005
5. Reducing signaling overhead
In this section, we propose some extensions to improve the
performance of the MIP6 RR test by reducing the signaling overhead
when MN renews its Binding Cache entry at the same location. Our
idea is to use hash chain to remove the necessity of Home Test
procedure.
5.1 With CoTi/CoT message
When the Binding Cache entry is close to expiration, MN uses the
following simplified RR test if it does not change its location since
last Binding Update to CN.
MN HA CN
| | |
| CoTi |
|-------------------------------------------------------->|
| CoT |
|<--------------------------------------------------------|
| BU |
|-------------------------------------------------------->|
| BA |
|<--------------------------------------------------------|
Figure 1: With CoTi/CoT message
The CoTi and CoT messages are the same as those in the original MIP6
RR test and are used to test whether MN is at the claimed location.
Assume that the current sequence number and hash chain element are
S_MN and H_MN(S_MN) in MN's hash chain and S_CN and H_CN(S_CN) in
CN's hash chain respectively.
MN generates the BU message as follows:
BU:
o Source IP address: CoA
o Destination IP address: CNA
o {HoA | S_MN | H_MN(S_MN) | careof_nonce_index | care-of token}
We include careof_nonce_index and care-of token in the BU message in
order to verify whether MN can really receive the CoT message at the
claimed location.
When CN receives the BU message, CN firstly verifies that care-of
Zhao, et al. Expires January 12, 2006 [Page 17]
Internet-Draft MIP6 RR Extensions July 2005
token is valid. If successful, CN looks up Binding Cache by HoA. If
found, CN verifies whether the current CoA in the Binding Cache entry
is the same as the source IP address of BU message. If not, CN
replies with a negative reply. Otherwise, CN verifies H_MN(S_MN) and
updates the corresponding Binding Cache entry if successful and then
generates the following BA message to MN.
BA:
o Source IP address: CNA
o Destination IP address: CoA
o {S_CN | H_CN(S_CN) | MAC}
o MAC = HMACSHA1(H_MN(S_MN), H_CN(S_CN))
MN now verifies whether MAC is indeed generated from H_MN(S_MN) and
H_CN(S_CN). If correct, MN verifies H_CN(S_CN) by comparing with the
old hash chain element from CN. If successful, MN updates its
records with a new H_CN(S_CN) and S_CN.
The integrity of BA message is weakly protected by H_CN(S_CN), which
provides the limited protection against that kind of attacker that
just moves onto the MN-CN path after MN sends the BU message.
However it does not resist the attacker on the MN-CN path generally.
5.2 With Binding Refresh message
MN HA CN
| | |
| Binding Refresh Request message |
|<--------------------------------------------------------|
| BU |
|-------------------------------------------------------->|
| BA |
|<--------------------------------------------------------|
Figure 2: With Binding Refresh message
The Binding Refresh Request message could serve as the same purpose
as CoT message. We extend the Binding Refresh Request message with
the mobility options of careof_nonce_index | care-of token.
Binding Refresh Request message:
o Source IP address: CNA
Zhao, et al. Expires January 12, 2006 [Page 18]
Internet-Draft MIP6 RR Extensions July 2005
o Destination IP address: CoA
o {careof_nonce_index | care-of token}
o care-of token = HMACSHA1 (Kcn, (CoA | HoA | nonce | 1)))
BU:
o Source IP address: CoA
o Destination IP address: CNA
o {HoA | S_MN | H_MN(S_MN) | careof_nonce_index | care-of token}
CN first verifies care-of token is valid, then verifies H_MN(S_MN).
If MN requests the BA message, CN will generate the following BA
message and send it to MN.
BA:
o Source IP address: CNA
o Destination IP address: CoA
o {S_CN | H_CN(S_CN) | MAC }
o MAC = HMACSHA1( H_CN(S_CN), (CoA | CNA | H_MN(S_MN) | BA)))
5.3 Security analysis
5.3.1 Partial control on the MN-CN path
If the BU message arrives at CN successfully, the attacker cannot
replay the eavesdropped hash chain element later.
If the BU message does not arrive at CN successfully, e.g. due to the
network congestion, MN will resend the BU message with the current
hash chain element after timeout. Please note that the attacker
cannot make CN redirect the traffic to another location by presenting
the eavesdropped hash chain element because source IP address must be
the same as before.
The attacker cannot forge the BA message from CN without providing a
valid CN's hash chain element.
Zhao, et al. Expires January 12, 2006 [Page 19]
Internet-Draft MIP6 RR Extensions July 2005
5.3.2 Full control on the MN-CN path
If the attacker modifies CoA in the BU message, CN can detect that
CoA is different from before and thus drops the modified BU message.
If the attacker modifies the hash chain element, CN cannot verify the
modified hash chain element successfully and thus drops it.
If the attacker drops the BU message, MN will retry with the same
hash chain element for several times if the BA message is not
received. It does not increase the knowledge of the attacker about
the hash chain.
The attacker can only reuse the intercepted hash chain element with
the same CoA, however, it is exactly what MN wants to do. Thus the
only meaningful attack happens when MN moves out from CoA after
sending the BU message and before the current Binding Cache entry
expires, which opens an extremely short window for the attacker.
(Otherwise CN will disable the Binding Cache entry and the complete
RR test has to be rerun, thus the intercepted hash chain element
becomes invalid due to the new received hash chain element.) And it
is only meaningful to the attacker that will move out from the MN-CN
path as well because otherwise the flooding attack traffic goes
through the attacker firstly and the attacker can always flood the
location represented by CoA directly.
If MN fails to renew the BCE after several retries, MN will send the
traffic through HA and since CN receives the traffic through HA, CN
may use it as a signal to redirect the traffic through HA.
In summary the attacker does not get any little benefit from this.
5.3.3 Future address stealing attack
Similar with that in RFC 3775, a malicious MN can still launch DoS
flooding attack against its current location. For example, MN
requests a long stream from CN and then moves to another location.
This attack is mitigated by the lifetime of Binding Cache entry.
Please note that MN cannot continue flooding the previous CoA because
of the periodical CoA address test.
5.4 Summary
Please note that the hash chain used here may be different from the
one used in Section 4. MN may exchange the first element of this
hash chain together with that of other hash chain in the Binding
Update message with CN.
Zhao, et al. Expires January 12, 2006 [Page 20]
Internet-Draft MIP6 RR Extensions July 2005
Our approach reduces the signaling overhead and shortens the time of
Binding Update procedure with CN by avoiding home address test
message that usually passes through a longer route.
Zhao, et al. Expires January 12, 2006 [Page 21]
Internet-Draft MIP6 RR Extensions July 2005
6. Related works
RFC 3775 [2] defines RR test in details. The rationale and
background of this design are documented in [4] and a taxonomy and
analysis of enhancements to Mobile IPv6 Route Optimization is
presented in [5]. R. Deng, J. Zhou and F. Bao proposed a secure
Binding Update protocol with strong security and good scalability in
[7]. W. Haddad et al proposed to use Cryptographically Generated
Addresses (CGA) to reduce signaling load and handoff delay in [11].
Another proposal of improvement of RR protocol can be found in [6].
C. Vogt proposed Early Binding Update (EBU) in [12] to reduce the
handover latency related to the RR test and credit-based
authorization in [13] with J. Arkko to mitigate the misuse of Early
Binding Update. However EBU requires more signaling messages, e.g.
proactive home address test message, and extra processing in CN, e.g.
the credit calculation. C. Vogt and J. Arkko also proposed a credit-
based mechanism to extend the lifetime of binding update in [14] as
well. Part of our work is originally published in [15].
Probably the most similar works are [9][10]. In [9] J. Ylitalo et al
proposed to use one-way hash chain and secret splitting to establish
the trust between mobile nodes and middle boxes in micro-mobility
while our proposal addresses the security and performance issues in a
macro-mobility protocol, Mobile IPv6 protocol. In [10] V. Torvinen
and J. Ylitalo independently proposed a security context
establishment procedure by using reverse one-way hash chain and
delayed authentication in mobility and multi-homing management while
our work focuses on improving the security and performance of Mobile
IPv6 RR test procedure in all scenarios and provides the
comprehensive analysis of security and performance.
Zhao, et al. Expires January 12, 2006 [Page 22]
Internet-Draft MIP6 RR Extensions July 2005
7. Conclusion
In this draft, we extended original MIP6 RR test by applying hash
chain. Through the thorough analysis, we show it is a very promising
approach to provide the stronger security and reduce signaling
overhead.
8. References
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", RFC 2119, March 1997.
[2] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in
IPv6", RFC 3775, June 2004.
[3] Arkko, J., Devarapalli, V., and F. Dupont, "Using IPsec to
Protect Mobile IPv6 Signaling between Mobile Nodes and Home
Agents", RFC 3776, June 2004.
[4] 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-02 (work in
progress), October 2004.
[5] Arkko, J. and C. Vogt, "A Taxonomy and Analysis of Enhancements
to Mobile IPv6 Route Optimization",
draft-arkko-mip6-ro-enhancements-00 (work in progress),
October 2004.
[6] Bao, F., Deng, R., and J. Zhou, "Improvement of Return
Routability Protocol", draft-qiu-mip6-rr-improvement-00 (work
in progress), August 2004.
[7] Deng, R., Zhou, J., and F. Bao, "Defending against Redirect
Attacks in Mobile IP", Proceedings of the 9th ACM Conference on
Computer and Communications Security, pages 59--67, Washington,
DC, November 2002.
[8] Perrig, A., Canetti, R., Tygar, J D., and D. Song, "Efficient
Authentication and Signing of Multicast Streams Over Lossy
Channels", Proceedings of IEEE Symposium on Security
and Privacy, 2000.
[9] Ylitalo, J., Melen, J., Nikander, P., and V. Torvinen, "Re-
thinking Security in IP based Micro-Mobility", Proceedings of
the 7th Information Security Conference, Palo Alto, CA, USA,
September 2004.
Zhao, et al. Expires January 12, 2006 [Page 23]
Internet-Draft MIP6 RR Extensions July 2005
[10] Torvinen, V. and J. Ylitalo, "Weak Context Establishment
Procedure for Mobility Management and Multi-Homing",
Proceedings of the 8th IFIP TC-6 TC-11 Conference on
Communications and Multimedia Security, Windermere, GB,
September 2004.
[11] Haddad, W., Madour, L., Arkko, J., and F. Dupont, "Applying
Cryptographically Generated Addresses to Optimize MIPv6 (CGA-
OMIPv6)", draft-haddad-mip6-cga-omipv6-03 (work in progress),
October 2004.
[12] Vogt, C., "Early Binding Updates for Mobile IPv6",
draft-vogt-mobopts-early-binding-updates-00 (work in progress),
February 2005.
[13] Vogt, C. and J. Arkko, "Credit-Based Authorization for Mobile
IPv6 Early Binding Updates",
draft-vogt-mobopts-credit-based-authorization-00 (work in
progress), February 2005.
[14] Arkko, J. and C. Vogt, "Credit-Based Authorization for Binding
Lifetime Extension",
draft-arkko-mipv6-binding-lifetime-extension (work in
progress), May 2004.
[15] Zhao, F., Wu, S F., and S. Jung, "Extensions on Return
Routability Test in MIP6", draft-zhao-mip6-rr-ext-01 (work in
progress), February 2005.
Authors' Addresses
Fan Zhao
University of California, Davis
One Shield Avenue
Davis, CA 95616
US
Phone: +1 530 752 3128
Email: fanzhao@ucdavis.edu
Zhao, et al. Expires January 12, 2006 [Page 24]
Internet-Draft MIP6 RR Extensions July 2005
S. Felix Wu
University of California, Davis
One Shield Avenue
Davis, CA 95616
US
Phone: +1 530 754 7070
Email: sfwu@ucdavis.edu
Jianying Zhou
Institute for Infocomm Research
21 Heng Mui Keng Terrace
Singapore 119613
SG
Phone: +65 6874 8543
Email: jyzhou@i2r.a-star.edu.sg
Souhwan Jung
Soongsil University
1-1, Sangdo-dong, Dongjak-ku
Seoul 156-743
KOREA
Phone: +82 2 820 0714
Email: souhwanj@ssu.ac.kr
Zhao, et al. Expires January 12, 2006 [Page 25]
Internet-Draft MIP6 RR Extensions July 2005
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Disclaimer of Validity
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement
Copyright (C) The Internet Society (2005). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Zhao, et al. Expires January 12, 2006 [Page 26]
