MIP6 Working Group F. Zhao
Internet-Draft S F. Wu
Expires: August 25, 2005 UC Davis
S. Jung
Soongsil University
February 21, 2005
Extensions on Return Routability Test in MIP6
draft-zhao-mip6-rr-ext-01
Status of this Memo
This document is an Internet-Draft and is subject to all provisions
of Section 3 of RFC 3667. 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 become aware will be disclosed, in accordance with
RFC 3668.
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 August 25, 2005.
Copyright Notice
Copyright (C) The Internet Society (2005).
Abstract
This draft proposes some extensions to the Return Routability Test in
MIP6 to address the location privacy issue and enable CN as well as
MN to promptly detect the attack that could compromise the security
of MIP6 RO mechanism.
Zhao, et al. Expires August 25, 2005 [Page 1]
Internet-Draft MIP6 RR Extensions February 2005
Table of Contents
1. Motivations . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Related Works . . . . . . . . . . . . . . . . . . . . . . . . 6
3. Assumptions . . . . . . . . . . . . . . . . . . . . . . . . . 7
3.1 No infrastructure support . . . . . . . . . . . . . . . . 7
3.2 Pre-existing SA between MN and HA . . . . . . . . . . . . 7
3.3 No pre-existing SA between MN and CN or between HA and
CN . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
3.4 No ingress filtering . . . . . . . . . . . . . . . . . . . 7
3.5 Unmalicious HA and CN . . . . . . . . . . . . . . . . . . 7
3.6 The power of the attacker . . . . . . . . . . . . . . . . 8
4. Proposal . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
4.1 Notations . . . . . . . . . . . . . . . . . . . . . . . . 9
4.2 Protecting the privacy of HoA in MIP6 RR test message
without encryption . . . . . . . . . . . . . . . . . . . . 9
4.3 Protection of the HoA privacy in the BU message . . . . . 13
4.4 Extending the RR test with a detection mechanism . . . . . 14
4.5 Lengthening the lifetime of BCE . . . . . . . . . . . . . 16
4.6 Fast BU refreshment . . . . . . . . . . . . . . . . . . . 17
4.7 Non-repudiation . . . . . . . . . . . . . . . . . . . . . 18
5. Security consideration . . . . . . . . . . . . . . . . . . . . 19
5.1 The privacy of HoA . . . . . . . . . . . . . . . . . . . . 19
5.2 Denial-of-Service attack . . . . . . . . . . . . . . . . . 19
5.2.1 Decryption . . . . . . . . . . . . . . . . . . . . . . 19
5.2.2 Hash chain verification . . . . . . . . . . . . . . . 19
5.3 Prevention of traffic interception . . . . . . . . . . . . 19
5.4 Other attacks described in [7] . . . . . . . . . . . . . . 20
6. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 21
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 22
A. Return Routability Test on Network Prefix (RRNP) in NEMO . . . 23
Intellectual Property and Copyright Statements . . . . . . . . 24
Zhao, et al. Expires August 25, 2005 [Page 2]
Internet-Draft MIP6 RR Extensions February 2005
1. Motivations
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].
MIP6 adopts Return Routability Test as a lightweight and
infrastructure-less authentication mechanism to achieve a reasonable
level of authentication between MN and CN even without pre-existing
security association. Our motivations to propose some extensions to
the original MIP6 RR test are as follows:
1) Location privacy
Recently location privacy, especially in the mobile environment,
attaches more and more attentions. Moreover, the core idea of MIP6
RR test can be used to enhance the security of NEMO Route
Optimization protocol. Although NEMO RO solution is still under
discussion, a potential approach is to enable MR to register its
MNP(s) with CN/CR to achieve the optimal route just like the
procedure of Binding Updates to correspondent nodes in MIP6. The
privacy issue in NEMO, such as the privacy of MNP (Mobile Network
Prefix), becomes even more serious. In this draft, we propose to
postpone the disclosure of HoA as late as possible by using hash
function and even make HoA invisible to the eavesdropper in the BU
message to CN by using encryption.
In MIP6 RR test, HoA is in the cleartext in the HoTi decapsulated and
forwarded by HA, HoT and BU messages to CN, thus an eavesdropper can
learn that MN is away from the home network and even MNÆs current
location when combining with CoA. The location privacy can be
protected by making either CoA (location) or HoA (identity) invisible
to eavesdropper. In this draft we use the latter.
However, we focus on the privacy issues only in the RR test related
messages (thus in the IP layer), so the privacy issues of other
messages, such as home BU message, prefix discovery message and data
message, are out of scope of this draft.
2) Detection of attack
The goal of the original MIP6 RR test is to make the MIP6 network as
secure as the IPv6 network. However, in MIP6, an attacker that is
able to only eavesdrop the traffic in the IPv6 network can
effectively intercept the traffic between MN and CN, which makes the
MIP6 network a little bit less secure than the IPv6 network. For
example, if an attacker adjacent to a unmalicious router on the path
between HA and CN can only eavesdrop the traffic but not intercept
Zhao, et al. Expires August 25, 2005 [Page 3]
Internet-Draft MIP6 RR Extensions February 2005
the traffic passing by in the IPv6 network, he can successfully
intercept thus take the complete control of the communication between
MN and CN by launching the MIP6 RR test.
In this draft we propose an efficient and effective detection
mechanism for both CN and MN to promptly detect any attack that could
compromise the security of MIP6 RO mechanism and thus take the
appropriate response. In the original MIP6 RR test, MN may detect
the disruption of the communication by observing the traffic
characteristics (The disruption/redirection attack is indicated by
the time-out signal, however, MN has to wait the timer to expire.).
Moreover, since MN does not know the root-cause of the anomaly, MN
may have to retry for several times (for example, by re-sending the
Binding Updates to CN) before concluding that there is either an
attack or link failure. In order to discover the root-cause, MN may
also try to compare the results by using the reverse tunneling to HA.
Thus the whole procedure is very lengthy. On the other hand, the
original MIP6 RR test does not provide any means for CN to detect the
attack, thus the performance of the communication between MN and CN
suffers since the moment when CN accepts the BU from an attacker. We
believe that CN is in the best position to detect the attack and the
most effective mechanism to resist a large range of attacks and
minimize the effects of attack has to be done on the CN side. By
detecting the attack promptly and taking the appropriate actions, for
example, CN sends the packets to the home address, MN can detect the
attack directly by observing the traffic being forwarded by HA, which
follows a non-optimal route but is still better than the disruption
of communication (100% packet loss).
3) Performance improvement
Besides the security enhancement, this detection mechanism also helps
improve the performance by reducing the signaling overhead.
In MIP6 RO protocol, the lifetime of Binding Cache Entry (and nonce,
token etc.) is limited to a few minutes in order to mitigate some
attacks, which causes a lot of signaling overheads. With the
detection mechanism, it is possible to lengthen the lifetime of
Binding Cache Entry when some attacks, such as Future Address
Stealing, are considered as the low severity.
Another observation is that it is unnecessary to keep repeating the
complete RR procedure if there is no attacker around, especially when
MN still stays at the same location as before. The by-product of
this detection mechanism is to reduce the complete RR procedure to
just one round trip of message exchange when the lifetime of BCE is
about to expire and MN does not change its location, which thus
greatly improves the performance.
Zhao, et al. Expires August 25, 2005 [Page 4]
Internet-Draft MIP6 RR Extensions February 2005
4) RR test on network prefix
It is also our motivation to propose a MIP6 RR test mechanism that
could be easily extended to ôRR-testö Mobile Network Prefix in NEMO
efficiently and securely once NEMO working group is re-chartered to
work on the NEMO RO problem.
This draft is organized as follows: in Section 2 we briefly review
the related works and then describe the assumptions and the details
of our proposal in Section 3 and Section 4 respectively. In Section
5 we present the security consideration and conclude the whole draft
in Section 6. Finally, we briefly discuss the applicability of these
ideas to NEMO RR test on MNP in Appendix 1.
Zhao, et al. Expires August 25, 2005 [Page 5]
Internet-Draft MIP6 RR Extensions February 2005
2. Related Works
MIP6 protocol [2] adopts the RR test to enable CN to authenticate the
binding between CoA and HoA of MN in a reasonable security level when
there is no pre-exisitng security association between CN and MN. The
rationale and background of this design are documented in [5]. Later
on, a lot of enhancements of MIP6 RO and improvement of the original
RR test are proposed in [6][7]. Those proposals are based on MIP6
RO; however, NEMO [4] RO [10] has its own security issues. [8]
proposed the idea of using NPT message to verify the correctness of
MNP; however, it not only generates the amplication effect but also
leaves a hole for an attacker to successfully steal the traffic [9].
Zhao, et al. Expires August 25, 2005 [Page 6]
Internet-Draft MIP6 RR Extensions February 2005
3. Assumptions
Our draft inherits all the underlying assumptions of the original
MIP6 RR test. Besides, we emphasis and restate the following
assumptions:
3.1 No infrastructure support
The extended RR test does not require PKI or AAA infrastructure to
assist the authentication procedure and thus avoids the expensive
public key calculation and signaling overhead due to extra message
exchanges.
3.2 Pre-existing SA between MN and HA
We assume that there exists a security association between MN and HA
and the integrity and confidentiality of the messages between MN and
HA are protected by this SA [3].
3.3 No pre-existing SA between MN and CN or between HA and CN
We assume that there is no pre-existing SA between MN and CN or
between HA and CN.
3.4 No ingress filtering
Our proposal does not rely on the ingress filtering, thus we assume
that there is no ingress filtering enforced and the attacker can even
spoof the packets.
3.5 Unmalicious HA and CN
We assume that HA and CN do not have any malicious intention.
If HA is malicious, the security of MIP6 RR test is compromised. For
example, a malicious HA can redirect the HoT message to an attacker
so that the attacker can successfully finish the RR procedure with CN
and intercept the traffic to other MN; a malicious HA can also drop
the HoTi or HoT message from or to any MN. In [8], the same
assumption is also held implicitly because otherwise a malicious HA
can forward the NPT messages to the attacker or respond on behalf of
the attacker. Also a malicious HA can fully control the
communication in MIP6 when MN performs the reverse tunneling. This
is similar with the case that the attacker has full control
(interception) over the path between CN and HA. The same analyses
also apply if CN is malicious. Thus we believe this is a valid
assumption.
Zhao, et al. Expires August 25, 2005 [Page 7]
Internet-Draft MIP6 RR Extensions February 2005
3.6 The power of the attacker
We use the following two terms to describe the power of the attacker:
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 original MIP6 RR test limits the attack to be successful only
when the attacker is in certain locations. In other words, the
security is compromised when the attacker has the following powers:
The attacker is able to access (intercept or eavesdrop) the message
exchanges on both MN-CN path and HA-CN path. To do so, 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.
We assume that the attacker has no full control on either MN-CN path
or HA-CN path, but the attacker may have the partial control over
both paths to eavesdrop the traffic passing by at the same time.
Zhao, et al. Expires August 25, 2005 [Page 8]
Internet-Draft MIP6 RR Extensions February 2005
4. Proposal
Our discussions are based on the following simplified MIP6 scenario:
CN is a fixed node in the Internet. It is possible to use the
reverse tunneling when CN is also a mobile node just like in [5], but
we will address this case in details in the later version of this
draft due to the constrained time frame.
Each extension can be applied to the original MIP6 RR test as an
independent add-on module. Thus based on the security policy, MN and
CN can negotiate to use one or a combination of several extensions.
4.1 Notations
Besides those used in [2], we also defines the following notations:
RN: a random number generated by MN with the fixed length. In
other words, the length of RN is pre-configured and well known by
MN, HA, CN and/or any other node.
HV: the output of a secure hash function, such as SHA1.
Kha: a secret node key of HA.
4.2 Protecting the privacy of HoA in MIP6 RR test message without
encryption
MN HA CN
| | |
| CoTi |
|-------------------------------------------------------->|
| CoT |
|<--------------------------------------------------------|
| HoTi | HoTi_HA |
|-------------------------->|---------------------------->|
| HoT_HA | HoT |
|<--------------------------|<----------------------------|
| BU |
|-------------------------------------------------------->|
| BA |
|<--------------------------------------------------------|
Figure 1: The RR test procedure
Please note that MN should send HoTi and CoTi as soon as possible,
even at the same time. The figure shows that HoTi is after CoTi just
because of the convenience of drawing.
Zhao, et al. Expires August 25, 2005 [Page 9]
Internet-Draft MIP6 RR Extensions February 2005
When MN moves to a new location other than its home network, MN may
decide to start the RR procedure with remote node, CN, as follows.
HoTi:
o Source IP address: HoA
o Destination IP address: CN
o {home_init_cookie | RN}
MN generates the HoTi message and forwards it into the reverse MN-HA
tunnel, thus the confidentiality and the secrecy of HoTi are
protected by SA between MN and HA.
After HA receives and verifies the HoTi message successfully, HA will
generate the following HoTi_HA message and forward it to CN. Note
that HoTi_HA message can use the same MH type value for HoTi message
because this transformation is transparent to CN. We give a
different name to the HoTi_HA message in order to highlight their
differences.
HoTi_HA:
o Source IP address: HA
o Destination IP address: CN
o {home_init_ha_cookie | HV} where HV = SHA1 (HoA | RN)
Please note that HA replaces the source IP address, HoA, with its own
IP address, HA and replaces home_init_cookie with
home_init_ha_cookie. While there are several ways to generate
home_init_ha_cookie, we simply generate it by a Random Number
Generator (RNG). Then HA establishes a table where
home_init_ha_cookie, HoA and home_init_cookie are stored in one entry
and home_init_ha_cookie is a primary key. Please note that HA
creates the table entry only after it verifies the received packet
from MN, thus it does not risk the Denial-of-Service attack at this
stage. Later, when HA receives the HoT packet that seems like from
CN, HA just needs to perform the table lookup operation to verify the
cookie. The management of this table does not result in too much
extra cost because HA needs to remember the recent home_init_cookie
in the original MIP6 RR test anyway. However if HA still concerns
about the memory cost, HA can generate home_init_ha_cookie by
AES(Kha, HoA | home_init_cookie) and only need to remember 1)
home_init_ha_cookie or 2) the output of a hash function over
home_init_ha_cookie or 3) even nothing. In 1) and 2) memory cost is
Zhao, et al. Expires August 25, 2005 [Page 10]
Internet-Draft MIP6 RR Extensions February 2005
reduced at a cost of decryption and/or hash computation and the
Denial-of-Service attack for HA is mitigated by firstly verifying the
received home_init_ha_cookie in the HoT message that seems from CN.
However, in 3) Denial-of-Service attack may become a serious threat
when HA later decrypts the payload to restore HoA and
home_init_cookie. Although the time spent on the decryption may not
be as much as one thought because AES is done over a short payload
(the concatenation of HoA and home_init_cookie), HA should take all
these factors in considerations and balance the cost between memory
and computation to minimize the threats.
After CN receives HoTi_HA message, CN generates the HoT message.
Note that the formula to generate home_token takes HV as input as
well.
HoT:
o Source IP address: CN
o Destination IP address: HA
o {home_init_ha_cookie | home_token | home_nonce_index}
o home_token = First (128, HMAC_SHA1(Kcn, (HV | home_nonce | 0)))
After HA receives HoT message, HA looks up the table with
home_init_ha_cookie as the primary key or decrypts the
home_init_ha_cookie. After successfully achieving HoA and
home_init_cookie, HA generates the following HoT_HA message and
forwards it to MN through the MN-HA tunnel.
HoT_HA:
o Source IP address: CN
o Destination IP address: HoA
o {home_init_cookie | home_token | home_nonce_index}
o home_token = First (128, HMAC_SHA1(Kcn, (HV | home_nonce | 0)))
Please note that HoT_HA message can use the same MH type value for
HoT message because this transformation is transparent to MN. We
give a different name to the HoT_HA message in order to highlight
their differences.
MN generates the CoTi message and sends it directly to CN. Note that
CoTi carries HV instead of HoA in the cleartext in [7].
Zhao, et al. Expires August 25, 2005 [Page 11]
Internet-Draft MIP6 RR Extensions February 2005
CoTi:
o Source IP address: CoA
o Destination IP address: CN
o {careof_init_cookie | HV}
o HV = SHA1 (HoA | RN) where RN is the same random number used in
the HoTi message.
After CN receives CoTi message, CN generates the CoT message. Note
that the formula to generate careof_token takes HV as input as well.
CoT:
o Source IP address: CN
o Destination IP address: CoA
o {careof_init_cookie | careof_token | careof_nonce_index}
o careof_token = First (128, HMAC_SHA1(Kcn, (CoA | HV | careof_nonce
| 1)))
The binding management key, Kbm, is generated by taking the
concatenation of home_token and careof_token as input of SHA1.
Kbm = SHA1(home_token | careof_token)
MN generates the BU message as follows and sends it to CN.
BU:
o Source IP address: CoA
o Destination IP address: CN
o {HoA | seq | home_nonce_index | careof_nonce_index | RN | MAC}
o MAC = First (128, HMAC_SHA1(Kbm, (CoA | CN | BU)))
Please note that the privacy of HoA is protected by encryption as
shown in Section 4.3. Other kinds of privacy protection mechanisms
than encryption could be used as well.
When CN receives the BU message, CN firstly calculates HV based on
HoA and RN, then generates Kbm and verifies the MAC. If MN requests
Zhao, et al. Expires August 25, 2005 [Page 12]
Internet-Draft MIP6 RR Extensions February 2005
the Binding Acknowledgement, CN generates the BA message based on the
verification result.
BA:
o Source IP address: CN
o Destination IP address: CoA
o {seq | HV | MAC}
o MAC = First (128, HMAC_SHA1(Kbm, (CoA | CN | BA)))
4.3 Protection of the HoA privacy in the BU message
The binding management key, Kbm, and the encryption key, Ken, are
generated as follows.
Kbm = SHA1(home_token | careof_token | 0)
Ken = SHA1(home_token | careof_token | 1)
BU:
o Source IP address: CoA
o Destination IP address: CN
o {seq | home_nonce_index | careof_nonce_index | HV | ENC | MAC}
o ENC = AES (Ken, HoA | RN)
o MAC = First (128, HMAC_SHA1(Kbm, (CoA | CN | BU)))
After CN receives the BU message, CN firstly generates Kbm and Ken,
then verifies MAC and decrypts ENC. Assume that what CN gets is HoAÆ
and RNÆ, CN will verify whether HV is equal to SHA1 (HoAÆ | RNÆ). If
the BA message is requested, CN generates the following one based on
the verification result.
BA:
o Source IP address: CN
o Destination IP address: CoA
o {seq | HV | MAC}
Zhao, et al. Expires August 25, 2005 [Page 13]
Internet-Draft MIP6 RR Extensions February 2005
o MAC = First (128, HMAC_SHA1(Kbm, (CoA | CN | BA)))
Please note that the decryption operation is after the verification
succeeds, which is necessary to reduce the risk of Denial-of-Service
attack. Please note that the time spent on the decryption might be
not as much as one thought because AES is done over a short payload
(the concatenation of HoA and RN). Although an attacker on the HA-CN
path can still pass the MAC verification and make CN spend resources
on the decryption operation, a detection mechanism can be used to
detect this kind of attack as shown below.
4.4 Extending the RR test with a detection mechanism
The original MIP6 RR test allows an attacker to intercept the traffic
even though this attacker is only able to eavesdrop the traffic in
the IPv6 network, which makes the MIP6 network slightly less secure
than the IPv6 network. In order to provide better security together
with other performance benefits, we propose a simple but effective
detection mechanism to enable CN to detect the attack promptly and
take the appropriate response when the power of attacker can
compromise the security of the original MIP6 RR test. The core idea
is that either a valid MN or an attacker must provide the
cryptographically sound proof of the previous successful Binding
Update to CN if any, before a new Binding Update is accepted by CN.
If the correctness of this proof cannot be verified by CN, CN
disables the relevant Binding Update Cache entry and forwards the
data packet to its home address instead.
We adopt one-way hash chain to accomplish that. While we have
considered using other kinds of one-way hash chain (or tree) as well,
in this draft we focus our discussions on the following one:
MN wants to a chain of length k. Firstly, it generates a random
number h_k 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). This
one-way hash chain has the following properties: MN reveals the
elements of the chain in the order of h_0, h_1, à, h_k to CN. Even
though the attacker eavesdrops h_i in this chain, it is still
cryptographically impossible for him to derive h_j from h_i where
j>i. On the contrary, any one can easily confirm that h_j is part of
the chain if h_i=H(h_j)^(j-i) where j>i. MN 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. There exist other approaches
that can help reduce storage cost with a small recomputation 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
Zhao, et al. Expires August 25, 2005 [Page 14]
Internet-Draft MIP6 RR Extensions February 2005
maintain such kind of one-way hash chain. Please note that MN
maintains a hash chain for each pair of <HoA, CN> so that MN can use
multiple HoAs to communicate with different CN.
Notations:
h_seq: the current element in the one-way hash chain.
seq: the sequence number of this element in the one-way hash
chain.
MN generates the BU message as follows and sends it to CN.
BU:
o Source IP address: CoA
o Destination IP address: CN
o {HoA | seq | home_nonce_index | careof_nonce_index | RN | h_seq |
MAC}
o MAC = First (128, HMAC_SHA1(Kbm, (CoA | CN | BU)))
When CN receives the BU message, CN firstly calculates HV based on
HoA and RN, then generates Kbm and verifies the MAC. If the result
is positive, CN performs the following procedure to verify h_seq:
1. Search the Binding Update Cache by using MNÆs HoA as the primary
key.
2. If it does exist, CN verifies h_seq in the BU message with the
old hash chain element, h_seqÆ stored in the Binding Updates
Cache as follows:
1. If seqÆ >= seq, discard the BU message because it is a
replayed message.
2. If seqÆ < seq and h_seqÆ=H(h_seq)^(seq-seqÆ), CN believes
this BU message is correct, thus it updates the Binding Cache
Entry with h_seq and then sends the Binding Acknowledgement
message if requested.
3. If seqÆ < seq and h_seqÆ <> H(h_seq)^(seq-seqÆ), CN realizes
that there is an attacker that can successfully finish the
extended RR test; however, CN is not sure whether this BU
message is from the attacker or a valid MN based on its
current knowledge. Thus CN disables this entry, indicates
Zhao, et al. Expires August 25, 2005 [Page 15]
Internet-Draft MIP6 RR Extensions February 2005
the reason in the BA message and forwards the data packets to
the home address. CNÆs policy may decide to accept the new
BU message for this HoA when the current session with this
HoA is ended or after a certain amount of time.
3. If it does not exist, CN accepts the BU message and creates a new
Binding Update Cache Entry and forwards the data packets destined
to this HoA based on MIP6 RO protocol.
The hash chain can be depleted after a long time use. MN can update
the hash chain information in CN by starting a complete RR test and
sending the last element in the old hash chain together with the
first element in the new hash chain in the BU message.
The hash chain information should not be lost due to the reboot in CN
and 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 information in the
hard disk so that the synchronization between MN and CN can be
restored.
CN must verify the hash chain element in the BU message even if seq
is not consecutive in order to recover from the BU packet loss due to
the network congestion. However the difference between the new seq
and the old seq should not be more than the number of retries when MN
experiences the packet loss.
If MN requests the Binding Acknowledgement, CN generates the BA
message based on the verification result.
BA:
o Source IP address: CN
o Destination IP address: CoA
o {seq | HV | MAC}
o MAC = First (128, HMAC_SHA1(Kbm, (CoA | CN | BA)))
Please note that this detection mechanism is independent from the
location privacy mechanism, thus the privacy of HoA can be also
protected by encryption just like in the previous section. CN needs
to verify the hash chain element after the decryption.
4.5 Lengthening the lifetime of BCE
Given the strong detection mechanism, it is possible to lengthen the
lifetime of BCE in order to reduce the frequency of RR test. One of
Zhao, et al. Expires August 25, 2005 [Page 16]
Internet-Draft MIP6 RR Extensions February 2005
dangers to do so is the future address stealing attack, which is
similar with the reflector-based flooding attack and can be easily
detected by MN. Thus if there is no such attack detected by MN, MN
can benefit from the lengthened BCE lifetime; otherwise, MN needs the
help from the upstream router to filter the unwanted traffic, maybe
in a way similar with pushback, which is out of the scope of this
draft. More examinations on the Pros and Cons of lengthening the
lifetime of BCE are still needed.
4.6 Fast BU refreshment
When the lifetime of one binding cache entry is about to expire or MN
receives the Binding Refresh Request message from CN, if MN does not
change its location, MN can send the following BU message to CN:
BU:
o Source IP address: CoA
o Destination IP address: CN
o {seq | HV | h_seq}
o where HV = SHA1(HoA)
When CN receives it, it uses HV to looks up the Binding Cache that is
extended to include HV as a field in each entry. If there exists an
entry, CN compares the received CoA with that in the entry. If it
matches, CN verifies h_seq as described before. If everything is
correct, CN generates the following BA message if requested:
BA:
o Source IP address: CN
o Destination IP address: CoA
o {seq | HV}
o where where HV = SHA1(HoA | h_seq)
When MN receives the BA message, MN generates SHA1(HoA | h_seq) and
then compares it with HV. If HoA is not disclosed, then it is
cryptographically impossible for an eavesdropper to generate SHA1(HoA
| h_seq) based on SHA1(HoA) and h_seq, thus MN can believe this BA
message is really from CN that gains the knowledge about HoA from the
complete RR procedure that MN did with CN before.
Zhao, et al. Expires August 25, 2005 [Page 17]
Internet-Draft MIP6 RR Extensions February 2005
Please note that if using the method above it is required to protect
the privacy of HoA in the data message as well. It is possible to
use SHA1(HoA) instead of HoA in the data packet; however, the details
will be discussed in the future version. If MN does not worry about
the location privacy, it can just use HoA in the BU message rather
than HV. Please note that the Binding Acknowledgement message is
optional in the original MIP6 RR test anyway, the forged Binding
Acknowledgement message may result in a non-optimal route in the
worst case but not disruption.
4.7 Non-repudiation
It seems that the only way to provide the non-repudiation of HA or CN
is to use the public key. Our RR test can be extended to achieve the
repudiation if the public keys of HA and/or CN are available. The
details of this extension are skipped because it is equivalent to say
that there exists the trust relationship between HA and CN.
Moreover, instead of using public key every time when launching the
RR test, we can use public key authentication only at the first time
and then use the hash chain in the following RR test session to
reduce the computation cost.
Zhao, et al. Expires August 25, 2005 [Page 18]
Internet-Draft MIP6 RR Extensions February 2005
5. Security consideration
5.1 The privacy of HoA
The privacy of HoA is protected as much as possible. Using the hash
value of HoA instead of HoA in the cleartext not only makes the
leakage of HoA cryptographically impossible but also help shorten the
length of message, simplify the task to design and parse message
format as the length of a hash function output is fixed. Moreover,
we append a random number to HoA before performing the hash function
in order to make it difficult for the attacker to derive HoA because
HAÆs address shares the same network prefix with HoA mostly. Without
this random number, the attacker may need less computation to acquire
HoA.
Please note that privacy is secondary compared with authentication
because if an attacker can break the authentication of the RR test,
the privacy of HoA is also compromised.
5.2 Denial-of-Service attack
Security comes with costs. We carefully design the protocol in order
to minimize the risk of Denial-of-Service attack against MN, CN or
HA.
5.2.1 Decryption
It is possible that the attacker can launch the DoS attack by making
CN/HA busy with decryption, however it requires the attacker to forge
the BU message with the correct MAC and hash chain element or to
provide the correct cookie. Because AES is done over a short payload
(For example, the total length of HoA and RN is only 32 bytes.), the
time to encrypt/decrypt by AES may not be as much as one thought.
5.2.2 Hash chain verification
The attacker may want to launch the DoS attack by making CN spend a
lot of time on the verification of hash chain element. For example,
if the current hash chain element is h_i, the attacker sends one BU
message with h_j where j>>i. CN may set the upper bound of the
difference between j and i, which is also the number of retries when
the BU message is lost during the transmission. If j is too large,
CN may refuse the BU message according to its policy.
5.3 Prevention of traffic interception
The attacker only being able to eavesdrop on both MN-CN and HA-CN
path cannot intercept the traffic that is intended to a specific MN
Zhao, et al. Expires August 25, 2005 [Page 19]
Internet-Draft MIP6 RR Extensions February 2005
when the detection mechanism is in use.
5.4 Other attacks described in [7]
The attacks described in [7] do not succeed in our RR test. For the
session hijacking attacks in section 3.1, although the attacker can
learn the home_token, however, it does not know HoA, so the attacker
cannot generate the correct BU message. If the attacker has its
conspirator on the MN-CN path, since its conspirator cannot intercept
the message, it cannot stop MN from finishing the RR test with CN.
Together with the detection mechanism, the traffic cannot be
hijacked. For the Movement Halting attacks in section 3.2, when the
attacker is able to know home_token and careof_token in the different
sessions but from one single MN, the attacker must have to learn HoA
from the BU message. If the BU message is encrypted, the attack
fails if the attacker cannot monitor both paths simultaneously. If
the BU message is not encrypted, the attack still fails when the
detection mechanism is used. For the traffic permutation attacks in
section 3.3, the attacker is able to know multiple home_tokens and
multiple careof_tokens in the different sessions from multiple
different MNs. However, since both home_token and careof_token are
generated from the hash output of HoA, CN can detect the forged BU
message using mixed home_token and careof_token. Again the detection
mechanism can detect this attack as well.
Using the hash output of HoA only prevents the attack targeting at a
specific MN and the attacker has no knowledge of HoA associated with
this MN. But the attacker on the HA-CN path is free to launch the RR
test for any HoA it chooses as long as it is on the path from CN to
this home network. Again, this attack can be detected by the
detection mechanism.
The extended RR test supports the fast Binding Updates procedure in
CN, which is especially useful when MN moves from one location to
another frequently. When MN moves to a new location, MN can reuse
the home_token received at the previous location as long as
home_token is still valid, thus MN saves the home test procedure that
is usually longer than the careof test since HoTi and HoT messages
have to go through HA firstly.
Zhao, et al. Expires August 25, 2005 [Page 20]
Internet-Draft MIP6 RR Extensions February 2005
6. Conclusions
In this draft, we propose several extensions to the original MIP6 RR
test. Our proposal protects the location privacy and enables CN and
MN to promptly detect the attack, thus it achieves better security
and performance.
7. 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] Devarapalli, V., Wakikawa, R., Petrescu, A. and P. Thubertet,
"Network Mobility (NEMO) Basic Support Protocol", RFC 3963,
January 2005.
[5] 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.
[6] 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.
[7] Bao, F., Deng, R. and J. Zhou, "Improvement of Return
Routability Protocol", draft-qiu-mip6-rr-improvement-00 (work
in progress), August 2004.
[8] Ng, C. and J. Hirano, "Extending Return Routability Procedure
for Network Prefix (RRNP)", draft-ng-nemo-rrnp-00 (work in
progress), October 2004.
[9] Nordmark, E., "Re: [nemo] [Fwd: I-D
ACTION:draft-ng-nemo-rrnp-00.txt]", NEMO WG mailing list
archive, http://www1.ietf.org/mail-archive/web/nemo/current/msg
01809.html, October 2004.
[10] Zhao, F., Wu, S F. and S. Jung, "NEMO Route Optimization
Problem Statement and Analysis", draft-zhao-nemo-ro-ps-01 (work
Zhao, et al. Expires August 25, 2005 [Page 21]
Internet-Draft MIP6 RR Extensions February 2005
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
S. Felix Wu
University of California, Davis
One Shield Avenue
Davis, CA 95616
US
Phone: +1 530 754 7070
Email: sfwu@ucdavis.edu
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 August 25, 2005 [Page 22]
Internet-Draft MIP6 RR Extensions February 2005
Appendix A. Return Routability Test on Network Prefix (RRNP) in NEMO
We limit our discussion in this draft in such a simplified NEMO
scenario: 1) CN/CR is a fixed node in the Internet. 2) MR is not in
the nested NEMO network, instead it attaches to the Internet
directly.
Generally speaking, we expect that the RR test on network prefix
(RRNP) in NEMO makes the NEMO network as secure as the MIP6/IPv6
network. Especially, the leakage of MNP information in NEMO does not
affect just one simple host as in MIP6 but a whole network, thus we
expect to protect the privacy of MNP during the RRNP procedure, which
is accomplished by applying hash function and encryption over the MNP
information. There are following advantages by using hash function
over MNP information alone: 1) The privacy of MNP is protected and
the disclosure of MNP is postponed as late as possible. 2) It does
not limit the number or source of MNP(s) owned by MR. Instead, MR
could own arbitrary number of MNPs from one or even multiple
different home networks while the length of message is shortened and
the task to design and parse message format is simplified as the
length of a hash function output is fixed. 3) The attacks described
in [7] are defeated while still making the fast Binding Update
possible.
We also avoid using multiple NPT messages to test the correctness of
MNP. Instead, we depend on HA to actively verify the MNP information
in the HoTi message. The reasons are as follows:
1) HA knows the MNP(s) associated with MR implicitly or explicitly
before the RRNP test. This is similar with implicit mode and
explicit mode in NEMO Basic Support Protocol. For example, there
is manual configuration at HA mapping the MNP to MRÆs HoA, so HA
knows the MNP associated with MR implicitly. On the other hand,
MR may inform HA about the MNP information explicitly by the Home
Binding Update procedure and then start the RRNP test. Either
way, HA can verify the MNP information in the RRNP message
correctly. (Note that in the explicit mode, the MNP information
in the RRNP message must match that in the Home Binding Update
message.)
2) HA should not have any malicious intention to CN/CR and MR as
we discuss before.
Hash chain can also be integrated into the RRNP test to detect the
attack.
Zhao, et al. Expires August 25, 2005 [Page 23]
Internet-Draft MIP6 RR Extensions February 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 August 25, 2005 [Page 24]