Internet DRAFT - draft-zhang-mip6-pid
draft-zhang-mip6-pid
MIP6 Lu Hongmei
Internet Draft Zhang Hongke
Expires: December, 2006 NGI Research Center
Beijing Jiaotong University
July 29, 2006
Privacy Identifier in MIPv6
draft-zhang-mip6-pid-00.txt
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 December 29, 2006.
Copyright Notice
Copyright (C) The Internet Society (2006). All Rights Reserved.
Abstract
This document proposes a solution on Mobile IPv6 home address privacy,
which prevents an eavesdropper from tracking a MN during route
optimization.
Zhang Expires December 29, 2007 [Page 1]
Internet-Draft Privacy Identifier in MIPv6 July 2006
Conventions used in this document
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 RFC-2119
Table of Contents
1. Introduction................................................2
2. Assumptions.................................................3
3. Privacy Identifier Proposal..................................3
3.1. Return Routability Process..............................5
3.2. Binding Update.........................................5
3.3. PID packet format.......................................8
3.4. WORD Option............................................8
4. Security Considerations......................................9
5. IANA Considerations.........................................9
6. Acknowledgments.............................................9
7. References..................................................9
Author's Addresses............................................10
Intellectual Property Statement................................10
Disclaimer of Validity........................................11
Copyright Statement...........................................11
Acknowledgment................................................11
1. Introduction
HoA uniquely identifies a MN, in MIPv6. The HoA of a MN is included
in packets it sends and receives. In fact, packets sent by a MN
include a Home Address option that contains its HoA. Packets sent by
a CN to a given MN contain a type 2 routing header that includes the
mobile HoA. Thus any eavesdropper within the network can easily
identify packets that a particular MN sends, and then continue to
track it.
MIPv6 allows a MN move from one network to another, while maintains
optimal routing mode. A MN can keep exchanging data packets with CN
When moving outside of the home network. Therefore when a MN roams to
a foreign network, it is allocated a CoA, and then sends binding
update message to update its binding cache entry with MN's new
location i.e. CoA. Since there is location information of its current
foreign network (prefix of the subnet) in the CoA and the binding
update message and subsequent data packets both HoA and CoA, it is
Zhang Expires December 29, 2006 [Page 2]
Internet-Draft Privacy Identifier in MIPv6 July 2006
easy to find out the location of a MN by keeping track of messages by
HoA.
Therefore, once a MN moves outside of home network, MIPv6 discloses
home address that used to identify, locate and track its target
during optimal routing mode.
In order to prevent the attack on HoA, a MN can avoid using the same
HoA during a long time. There are mostly two methods:
o MN can use substituted identifier as HoA, packets sent and
received by a MN will contain substituted identifier instead of
HoA, but it must be transmitted securely and must not become a
target of attack.
o MN is collocated temporary Home Address that is periodically
changed;
This document proposes a mechanism for preventing the eavesdropper
from tracking of MN during optimal routing mode.
2. Assumptions
The methods discussed in this document depend upon the following
assumptions:
o The MN and the HA shares one secret key Kbm.
o MN's identity is not revealed by other protocols such as AAA etc.
o PID can be used as indexes for IPsec SAs between MN and HA.
o MN communicate using PID instead of HoA, in fact, using HoA to
communication is reachable.
3. Privacy Identifier Proposal
Here we propose a HoA privacy solution that meets the following
requirements:
o The privacy identifier substituting HoA can be changed, but not
frequently; the privacy identifier must change only when the CoA
changes, and the privacy identifier itself must not become a
target of attack.
Zhang Expires December 29, 2006 [Page 3]
Internet-Draft Privacy Identifier in MIPv6 July 2006
o Continuous reachability at all times.
o It is impossible for a eavesdropper to reckon the relationship
between a privacy identifier and a HoA;
o As less dependency as possible to other protocols such as IPsec.
In the solution privacy identifier is used to substitute HoA. If the
MN decides to use route optimization mode, it must sends a binding
update to its CN. This binding update contains the privacy identifier
in its Home Address option and the actual HoA is concealed by being
encoded in a newly defined sub-option. In order to preserve privacy
the binding update must be encrypted
Thus the following packets between the MN and the CN contains the
privacy identifier in the Home Address option and routing header 2
instead of the actual HoA. As a result, an eavesdropper is not able
to identify the packets sent or received by a particular node.
During the period of communication process, the following requirement
is necessary:
o To prevent disclosing the MN's HoA in any binding update message.
o To avoid using the same privacy identifier in binding update
message.
Privacy Identifier(PID) changes while CoA changing, and is used to
replace CoA in destination option. CN use this privacy identifier to
recover the HoA from binding update packets. This solution ensures
that the update of PID and CoA is synchronous.
The definition of PID is as follows:
PID = Clearword XOR HoA
Clearword = First(128 HMAC_SHA1(Seed,CN|HoA|CoA))
''Seed'' is a random number that generated by MN. Because of ''seed'' is
not transmitted in plain text, MN can use the same SEED for
communication with all the CN and HA. The introduction of seed can
ensure that the ''clearword'' is random enough. Adding the address of
CN to the computation of ''clearword'' is to guarantee each ''clearword''
correspond with one and only CN, and CoA is used to make sure that
the ''clearword'' updated synchronously with the new CoA.
Zhang Expires December 29, 2006 [Page 4]
Internet-Draft Privacy Identifier in MIPv6 July 2006
3.1. Return Routability Process
In Return Routability Process, Home Test Init (HoTI) and Home Test
(HoT) using the address of HA and PID, but not HoA.
Home Test Init to the HA in the following form:
IPv6 header (source = care-of address,
destination = home agent)
ESP header in tunnel mode
IPv6 header (source = home address,
destination = correspondent node)
Mobility Header
Home Test Init
Home Test Init from the MN in the following form:
IPv6 header (source = home agent,
destination = correspondent node)
Destination Options header
Home Address option (PID)
Mobility header
Home Test Init
Home Test to the MN in the following form:
IPv6 header (source = correspondent node,
destination =home agent)
Routing header (type 2)
PID
Mobility header
Home Test
Home Test from the HA in the following form:
IPv6 header (source = home agent,
destination =care-of address)
ESP header in tunneling mode
IPv6 header (source = correspondent node,
destination = home address)
Mobility header
Home Test
3.2. Binding Update
After receiving the HoT and Care of Test, the MN sends binding update
to the CN in the following form:
Binding Update from MN:
Zhang Expires December 29, 2006 [Page 5]
Internet-Draft Privacy Identifier in MIPv6 July 2006
IPv6 header (source = care-of address,
destination = home agent)
Destination Options header
Home Address option (PID)
Mobility header
Binding Update
Binding Update to HA:
IPv6 header (source = home address,
destination = home agent)
Destination Options header
Home Address option (PID)
Mobility header
Binding Update
Binding Acknowledgement from HA:
IPv6 header (source = home agent,
destination = care-of address)
Routing header (type 2)
PID
Mobility header
Binding Acknowledgement
Binding Acknowledgement to MN;
IPv6 header (source = home agent,
destination = home address)
Routing header (type 2)
PID
Mobility header
Binding Acknowledgement
Adding ''word'' option to binding update message, the content of which
is ''clearword'' or ''EncryptedWord''.
The MN immediately computes and uses the new PID when it obtains the
new CoA, which means that the PID is updated synchronously with the
new CoA.
In the course of binding update for HA, PID is in the Home Address
option (substitute the place of HoA), Clearword is in the Word option
of BU, and Word option is protected by IPsec. At HA, BU messages are
protected by ESP (transmit mode) which can ensure the security of
Clearword. PID is work as source address through SA is setup with HA
in the transmit mode, thus the new PID does not impact on the IPsec
Zhang Expires December 29, 2006 [Page 6]
Internet-Draft Privacy Identifier in MIPv6 July 2006
operation. HA can obtain the Clearword in Word option after
decryption, and then recover HoA, HoA=PID XOR Clearword.
During the time of binding update of CN, at the beginning of RR, the
MN uses the new PID and the CN is unnecessary to verify the validity
of PID. At the end of RR, MN will obtain a binding management key
(Kbm), with which MN encrypts ''clearword''.
EncryptedWord = Encrypt(ClearWord)
Encrypt()is the encrypted content of () with Kbm.
Then send the BU message that contains the EncryptedWord in the Word
option to the CN.
After receiving a BU message, CN must compute Kbm and verify the
validity of Message Authentication Code (MAC). If the verification is
successful and the PID is valid, ''EncryptedWord'' t is decrypted to
recover ''clearword''. With PID and clearword, CN can recover HoA.
After that, the CN keeps both HoA and PID in its binding cache. The
process of communication is the same as RFC3775 except that the PID
substitutes the HoA. The involved arithmetic is as follows:
HoA=PID XOR clearword
Clearword=Decrypt(EncryptedWord)
Decrypt() is the decrypted content of () with Kbm.
When MN and CN communicate via reverse tunneling, the procedure is
the same as above.
During the whole process of communication, this technique conceals
the HoA by this way. Furthermore, it can prevent the RR related
attack from eavesdropper, since the CoA updates synchronously with
privacy identifier.
Zhang Expires December 29, 2006 [Page 7]
Internet-Draft Privacy Identifier in MIPv6 July 2006
3.3. PID packet format
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Option Type | Option Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ PID +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Option Type
IANA is requested to assign a new type
Option Length
8 bit unsigned integer indicating the length of the option
excluding the type and length fields.
PID
The PID as above
3.4. WORD Option
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Option Type | Option Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ WORD +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Option Type
Zhang Expires December 29, 2006 [Page 8]
Internet-Draft Privacy Identifier in MIPv6 July 2006
IANA is requested to assign a new type
Option Length
8 bit unsigned integer indicating the length of the option
excluding the type and length fields.
WORD
ClearWord or EncryptedWord
4. Security Considerations
We assume that the communications between a MN and its HA are
protected by IPsec Security Associations (SA) as in Mobility support
in IPv6 RFC3775.
5. IANA Considerations
The PID destination option introduced in requires IANA assignment
from the destinations options space.
The Option Type value for the WORD Option within the option numbering
space will be assigned by IANA.
6. Acknowledgments
This document is a collaborative effort of our entire NGI Research
Center. Many thanks to them who are Yang Shen, Zhang Sidong, Chen
Jian, Ren Yan, Zhang Hui, Zhang Bingyi.
7. References
[1] D. B. Johson and C. Perkins, "Mobility Support in IPv6", RFC
3775, June 2004.
[2] J. Arkko, V. Devarapalli and F. Dupont, "Using IPsec to Protect
Mobile IPv6 Signaling Between Mobile Nodes and Home Agents",RFC
3776, June 2004.
[3] Haddad, W., Ed., "Anonymity and Unlinkability Extension for
OMIPv6-CGA", draft-haddad-privacy-omipv6-anonymity-00.txt (work
in progress), June 2005.
[4] Castelluccia, C., Dupont, F., and G. Montenegro, "A Simple
Privacy Extension to Mobile IPv6", IEEE/IFIP International
Zhang Expires December 29, 2006 [Page 9]
Internet-Draft Privacy Identifier in MIPv6 July 2006
Conference on Mobile and Wireless Communication Networks (MWCN),
October 2004.
[5] R. Koodli. Solutions for IP Address Location Privacy in the
presence of IP Mobility. Internet Draft, Internet Engineering
Task Force. draft-koodli-location-privacy-00.txt, February
2005.
[6] W. Haddad, E. Nordmark, F. Dupont, M. Bagnulo, S. Park, B. Patil,
"Privacy for Mobile and Multi-homed Nodes: MoMiPriv Problem
Statement", draft-haddad-momipriv-problem-statement-01, February
2005.
Author's Addresses
Long Hongmei Tel: +86 10 5168 5677
IP Lab,EIES Fax: +86 10 5168 3682
Beijing Jiaotong University of China
Beijing
http://iplab.njtu.edu.cn
China,100044
Email:lu_922@163.com
Zhang Hongke Tel: +86 10 5168 5677
NGI Research Center Fax: +86 10 5168 3682
Beijing Jiaotong University of China
Beijing
http://iplab.njtu.edu.cn
China,100044
Email: hkzhang@center.njtu.edu.cn
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
Zhang Expires December 29, 2006 [Page 10]
Internet-Draft Privacy Identifier in MIPv6 July 2006
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 (2006).
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.
Zhang Expires December 29, 2006 [Page 11]
