One document matched: draft-qiu-mip6-rr-improvement-00.txt
Network Working Group Feng BAO
INTERNET-DRAFT Robert DENG
Expires: February 28, 2005 Ying QIU
Network Working Group Jianying ZHOU
August 30, 2004
Improvement of Return Routability Protocol
<draft-qiu-mip6-rr-improvement-00.txt>
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 February 28, 2005.
Copyright Notice
Copyright (C) The Internet Society (2004). All Rights Reserved.
Abstract
This document proposes an improved security solution for Return
Routability (RR) protocol without changing the architecture. With
the improvement, three types of redirect attacks can be prevented.
Expires: February 28, 2005 [Page 1]
Internet Draft Improved RR August 30, 2004
Table of Contents
1. Introduction ................................................. 2
2. Brief Review of RR Protocol .................................. 2
3. Discussion of Redirect Attacks in MIPv6 ...................... 4
3.1 Session Hijacking Attacks ................................. 5
3.2 Movement Halting Attacks .................................. 6
3.3 Traffic Permutation Attacks ............................... 6
4. Improvement of RR Protocol ................................... 7
5. Security Considerations ...................................... 8
6. Conclusion ................................................... 8
7. Acknowledgements ............................................. 8
8. References ................................................... 8
9. Authors' Addresses ............................................ 8
Intellectual Property and Copyright Statements ................... 9
1. INTRODUCTION
In the base specification of Mobile IPv6 (MIPv6) [1], the Return
Routability protocol (RR) is employed to secure binding updates
from mobile nodes to corresponding nodes.
In the draft, we will discuss three attacks to the RR protocol and
then give a solution without changing the RR architecture.
2. BRIEF REVIEW OF RR PROTOCOL
In Return Routability (RR) protocol, each correspondent node CN
keeps a secret key Kcn and generates nonces at regular intervals,
say every few minutes. CN uses the same secret key Kcn and nonce
with all the mobile nodes it is in communication with, so that it
does not need to generate and store a new nonce when a new mobile
node contacts it. Each nonce is identified by a nonce index. When a
new nonce is generated, it must be associated with a new nonce
index, e.g., j. CN keeps both the current nonce of Nj and a small
set of previous nonce values, Nj-1, Nj-2, ... . Older values are
discarded, and messages using them will be rejected as replays.
Message exchanges in the RR protocol are shown in the figure below,
where the HoTI (Home Test Init) and CoTI (Care-of Test Init)
messages are sent to CN by a mobile node MN simultaneously. The HoT
(Home Test) and CoT (Care-of Test) are replies from CN. All RR
protocol messages are sent as IPv6 "Mobility Header" in IPv6
packets.
Expires: February 28, 2005 [Page 2]
Internet Draft Improved RR August 30, 2004
Mobile node Home agent Correspondent node
| |
| Home Test Init (HoTI) | |
|------------------------->|------------------------->|
| | |
| Care-of Test Init (CoTI) |
|---------------------------------------------------->|
| |
| | Home Test (HoT) |
|<-------------------------|<-------------------------|
| | |
| Care-of Test (CoT) |
|<----------------------------------------------------|
| |
In the brief review of a protocol message, we will use the first two
fields to denote source IP address and destination IP address,
respectively. We will use CNA to denote the IP address of the
correspondent node CN.
When MN wants to perform route optimization, it sends
HoTI = {HoA, CNA, CKh} and
CoTI = {CoA, CNA, CKc}
to CN, where CKh and CKc are the initial cookies used to match
responses with requests. HoTI tells MN??s home address HoA to CN. It
is reverse tunneled through the home agent HA, while CoTI informs
MN??s care-of address CoA and is sent directly to CN.
When CN receives HoTI, it takes the source IP address of HoTI as
input and generates a home keygen token
KTh = HMAC_SHA1(Kcn, (HoA|Nj|0))
and replies MN with
HoT = {CNA, HoA, CKh, KTh, j},
where | denotes concatenation and the final "0" inside the pseudo
random function is a single zero octet, used to distinguish home and
care-of cookies from each other. The index j is carried along to
allow CN later efficiently finding the nonce value Nj that it used
in creating the home keygen token KTh.
Similarly, when CN receives CoTI, it takes the source IP address of
CoTI as input and generates a care-of keygen token
KTc = HMAC_SHA1(Kcn, (CoA|Ni|1))
Expires: February 28, 2005 [Page 3]
Internet Draft Improved RR August 30, 2004
and sends
CoT ={CNA, CoA, CKc, KTc, i}
to MN, where the final "1" inside the pseudo random function is a
single octet "0x01". Note that HoT is sent via MN??s home agent HA
while CoT is delivered directly to MN.
When MN receives both HoT and CoT, it hashes together the two keygen
tokens to form a binding key
Kbm = SHA1(KTh|KTc),
which is then used to authenticate the corresponding binding update
message to CN:
BU = {CoA, CNA, HoA, Seq#, i, j, MACbu},
????
where Seq# is a sequence number used to detect replay attack and
MACbu = HMAC_SHA1(Kbm, CoA|CNA|HoA|Seq#|i|j)
is a message authentication code (MAC) protected by the binding key
Kbm. MACbu is used to ensure that BU was sent by the same node which
received both HoT and CoT. The message BU contains j and i, so that
CN knows which nonce values Nj and Ni to use to first re-compute KTh
and KTc and then the binding key Kbm. Note that CN is stateless
until it receives BU and verifies MACbu.
3. REDIRECT ATTACKS TO RR PROTOCOL
In the RR protocol, the two keygen token exchanges verify that a
mobile node MN is alive at its addresses, i. e., is at least able to
transmit and receive traffic at both its home address HoA and care-
of address CoA, respectively. The eventual binding update is
cryptographically protected with the binding key Kbm obtained by
hashing the concatenation of the two keygen tokens KTh and KTc.
Obviously, the RR protocol protects binding updates against
intruders who are unable to monitor the HA-CN path and the MN-CN
path simultaneously. However, one has no reason to assume that an
intruder will monitor one link and not the other, especially when
the intruder knows that monitoring a given link is particularly
effective to expedite its attack. Even worse, we demonstrate that
the RR protocol can be attacked under its original assumption of no
simultaneous monitor of both the HA-CN path and the MN-CN path.
Expires: February 28, 2005 [Page 4]
Internet Draft Improved RR August 30, 2004
3.1 Session Hijacking Attacks
In the session hijacking redirect attack shown in the figure below,
assume that a mobile node MN1 is communicating with a correspondent
node CN. An intruder sends a forged binding update message (or
replays an old binding update message) to CN, claiming that MN1 has
moved to a new care-of address belonging to a node MN2. If CN
accepts the fake binding update, it will redirect to MN2 all packets
that are intended to MN1. This attack allows the intruder to hijack
ongoing connections between MN1 and CN or start new connections with
CN pretending to be MN1. This is an "outsider" attack since the
intruder tries to redirect other nodes?? traffic. Such an attack may
result in information leakage, impersonation of the mobile node MN1
or flooding of MN2.
This attack is serious because MN1, MN2, CN and the intruder can be
any nodes anywhere on the Internet. All the intruder needs to know
is the IP addresses of MN1 and CN. Since there is no structural
difference between a mobile node home address and a stationary IP
address, the attack works as well against stationary Internet nodes
as against mobile nodes.
+-----+
| MN2 |<------------+
+-----+ |
v
+-----+ +----+
| MN1 |<----- XX ------->| CN |
+-----+ +----+
^
+----------+ |
| Intruder | -------+
+----------+
In the case of the static IPv6 without mobility (which is equivalent
to the mobile node MN at its home subnet in MIPv6), to succeed in
the attack, the intruder must be constantly present on the CN-HA
path. In order to redirect CN??s traffic intended for MN to a
malicious node, the intruder most likely has to get control of a
router or a switch along the CN-HA path. Furthermore, after taking
over the session from MN, if the malicious node wants to continue
the session with CN while pretending to be MN, the malicious node
and the router need to collaborate throughout the session. For
example, the router tunnels CN??s traffic to the malicious node and
vise versa.
In the case of MIPv6, the effort committed to break the RR protocol
to launch a session hijacking attack could be considerably lesser.
Assume that MN1 and CN in the figure above are having an on-going
communication session and the intruder wants to redirect CN??s
Expires: February 28, 2005 [Page 5]
Internet Draft Improved RR August 30, 2004
traffic to his collaborator MN2. The intruder monitors the CN-HA
path (i.e., anywhere from MN1??s home network to CN??s network) to
obtain HoT, extracts the home keygen token KTh and sends it to MN2.
Upon receiving KTh, MN2 sends a CoTI to CN and CN will reply with a
care-of keygen token KTc. MN2 simply hashes the two keygen tokens to
obtain a valid binding key, and uses the key to send a binding
update message to CN on behalf of MN1. The binding update will be
accepted by CN which will in turn direct its traffic to MN2.
3.2 Movement Halting Attacks
Another related attack is when a mobile node MN rapidly moves from
one care-of address CoA to another CoA??. Since MN runs the RR
protocol whenever it moves to a new location, an intruder can
intercept the care-of keygen token KTc in the current RR session and
the home keygen token KTh in the next RR session, hash the two
keygen tokens to a valid binding key, and then send a binding update
message with the CoA in the current session to the correspondent
node. The correspondent node will still send its traffic back to
CoA. Hence, MN, which has moved to CoA??, will not receive data from
the correspondent node. Note that in this attack the attacker does
not have to intercept the two keygen tokens at the "same time".
3.3 Traffic Permutation Attacks
+-----+ :
| MN1 |===========:======\\
+-----+ : \\
: \\
+-----+ : +--------------+
| MN2 |===========:===| CN or Server |
+-----+ : +--------------+
: //
+-----+ : //
| MN3 |===========:======//
+-----+ :
:
+----------+
| Intruder |
+----------+
The RR protocol is also subject to a "traffic permutation" attack.
Consider the figure above where a correspondent node provides
on-line services to many mobile clients. An intruder can simply
eavesdrop on the RR protocol messages to collect keygen tokens on
the border between the correspondent node and the Internet. The
intruder then hashes random pairs of keygen tokens to form binding
keys, and sends binding update messages to the correspondent node.
Expires: February 28, 2005 [Page 6]
Internet Draft Improved RR August 30, 2004
Such a forged binding update message will be accepted by the
correspondent node with probability 1/4. This will cause redirection
of traffic to randomly selected mobile clients and eventually bring
down the services of the correspondent node.
4. IMPROVEMENT OF RR PROTOCOL
The attacks outlined in the above section are due to the decoupling
of HoA and CoA in RR messages. In the original RR protocol, the home
keygen token
KTh = HMAC_SHA1(Kcn, (HoA|Nj|0))
and the care-of keygen token
KTc = HMAC_SHA1(Kcn, (CoA|Ni|1)))
are delivered without any stated relationship. Any pair of home
keygen token and care-of keygen token can generate a valid binding
key as long as the indexes, i and j, are still valid.
However, the attacks described in the above section can be prevented
by modifying the RR protocol to include both CoA and HoA in the
generation of home keygen token and care-of keygen token,
respectively. In the improved RR protocol, HoA and CoA are bound
together. A mobile node MN sends
HoTI = {HoA, CNA, CoA, CKh} and
CoTI = {CoA, CNA, HoA, CKc}
to a correspondent node CN, which replies with the home keygen token
KTh = HMAC_SHA1(Kcn, (HoA|Nj|CoA|0))
and the care-of keygen token
KTc = HMAC_SHA1(Kcn, (CoA|Ni|HoA|1)).
Expires: February 28, 2005 [Page 7]
Internet Draft Improved RR August 30, 2004
5. SECURITY CONSIDERATIONS
The draft proposes an improvement of RR protocol so that three kinds
of redirect attacks can be prevented.
6. CONCLUSION
After analysis of RR protocol and three redirect attacks, we
proposed an improved solution for RR protocol. The improvement can
provide much stronger security than the original RR protocol without
changing its architecture.
7. ACKNOWLEDGEMENTS
8. REFERENCES
[1] D. B. Johson and C. Perkins, "Mobility Support in IPv6",
RFC 3775, June 2004.
9. AUTHORS' ADDRESSES
Feng BAO
Institute for Infocomm Research
21 Heng Mui Keng Terrace
Singapore 119613
Phone: +65-6874-8456
EMail: baofeng@i2r.a-star.edu.sg
Robert DENG
Singapore Management University
469 Bukit Timah Road
Singapore 259756
Phone: +65-6822-0920
EMail: robertdeng@smu.edu.sg
Ying QIU
Institute for Infocomm Research
21 Heng Mui Keng Terrace
Singapore 119613
Phone: +65-6874-6742
EMail: qiuying@i2r.a-star.edu.sg
Jianying ZHOU
Institute for Infocomm Research
21 Heng Mui Keng Terrace
Singapore 119613
Phone: +65-6874-6668
EMail: jyzhou@i2r.a-star.edu.sg
Expires: February 28, 2005 [Page 8]
Internet Draft Improved RR August 30, 2004
INTELLECTUAL PROPERTY STATEMENT
The IETF takes no position regarding the validity or scope of any
intellectual property or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; neither does it represent that it
has made any effort to identify any such rights. Information on the
IETF's procedures with respect to rights in standards-track and
standards-related documentation can be found in BCP-11. Copies of
claims of rights made available for publication and any assurances
of licenses to be made available, or the result of an attempt made
to obtain a general license or permission for the use of such
proprietary rights by implementors or users of this specification
can be obtained from the IETF Secretariat.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights which may cover technology that may be required to practice
this standard. Please address the information to the IETF Executive
Director.
Full Copyright Statement
Copyright (C) The Internet Society (2004). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph
are included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assignees.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Expires: February 28, 2005 [Page 9]
Internet Draft Improved RR August 30, 2004
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Expires: February 28, 2005 [Page 10]
| PAFTECH AB 2003-2026 | 2026-04-23 00:31:36 |