[Docs] [txt|pdf] [Tracker] [Email] [Nits]
Versions: 00
Network-based Mobility Management W. Haddad
(Netlmm) S. Krishnan
Internet-Draft Ericsson Research
Intended status: Standards Track November 11, 2007
Expires: May 11, 2008
On Providing Light SeND and Privacy Extensions for Proxy MIPv6 (PMIPv6)
draft-haddad-netlmm-pmipv6-privacy-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 May 11, 2008.
Copyright Notice
Copyright (C) The IETF Trust (2007).
Haddad & Krishnan Expires May 11, 2008 [Page 1]
Internet-Draft Proxy MIPv6 Privacy November 2007
Abstract
This document describes a light and CGA free version of the secure
neighbor discovery protocol combined with a privacy extension for the
Proxy Mobile IPv6 protocol.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Conventions used in this document . . . . . . . . . . . . . . 4
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
4. Background and Motivation . . . . . . . . . . . . . . . . . . 6
5. Proposed Solutions . . . . . . . . . . . . . . . . . . . . . . 8
5.1. Solution for On-path attacks . . . . . . . . . . . . . . . 8
5.2. Solution for On-link attacks . . . . . . . . . . . . . . . 8
5.3. Operation . . . . . . . . . . . . . . . . . . . . . . . . 9
5.4. Future work . . . . . . . . . . . . . . . . . . . . . . . 10
6. New Option Format . . . . . . . . . . . . . . . . . . . . . . 11
7. Security Considerations . . . . . . . . . . . . . . . . . . . 12
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13
8.1. Normative References . . . . . . . . . . . . . . . . . . . 13
8.2. Informative References . . . . . . . . . . . . . . . . . . 13
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14
Intellectual Property and Copyright Statements . . . . . . . . . . 15
Haddad & Krishnan Expires May 11, 2008 [Page 2]
Internet-Draft Proxy MIPv6 Privacy November 2007
1. Introduction
Proxy Mobile IPv6 protocol (described in [PMIPv6]) is an ongoing
activity, which aims essentially to provide network based mobility.
The main concept is to trick the mobile node (MN) into believing that
it is always attached to its home network even when in reality, it
has switched to foreign network(s). Consequently, the MN can keep
using it IP home address (HoA) while being located away from its home
network.
This document describes a mechanism which combines a light and CGA
free version of the secure neighbor discovery (described in [SeND])
combined with a privacy extension for PMIPv6 protocol. At this
stage, the light SeND (LiSeND) protocol enables the MN and its access
router, i.e., the mobility access gateway (MAG), to authenticate the
exchange of router solicitation (RtSol) and advertisement (RtAdv)
messages and removes the need for running duplicate address detection
(DAD) on the MN side (for more details on RtAdv/RtSol and DAD, please
refer to the Neighbor Discovery Protocol described in [NDP]).
Another key feature lies in the fact that LiSeND does not require the
crypto generated address technique (described in [CGA]) deployment on
both the infrastructure and the MN sides.
Building on LiSeND, we then describe a simple privacy extension which
enables to mask the MN's HoA in a visited network(s) and thus,
prevents an eavesdropper from learning, identifying and tracing the
MN. A side effect of the suggested proposal is a mechanism which
removes the harmful impact on the MN's ongoing sessions in case of a
possible duplicate address detection (DAD) failure.
Haddad & Krishnan Expires May 11, 2008 [Page 3]
Internet-Draft Proxy MIPv6 Privacy November 2007
2. 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 [TERM].
Haddad & Krishnan Expires May 11, 2008 [Page 4]
Internet-Draft Proxy MIPv6 Privacy November 2007
3. Terminology
Since our proposal is mainly designed for network-based mobility, we
borrow the terminology used in PMIPv6 and refer to a mobility
(un)aware by MN. The main privacy aspects definitions are defined in
[PRITERM]. Finally, we reuse the tunneling optimization mechanism
and terminology that we have introduced earlier in [TOM].
Haddad & Krishnan Expires May 11, 2008 [Page 5]
Internet-Draft Proxy MIPv6 Privacy November 2007
4. Background and Motivation
Being a network-base mobility, PMIPv6 achieves its goal by enabling
the MN to retain the same IP address while roaming between different
foreign networks and delegates the task of securely discovering and
updating the MN's Local Mobility Anchor (LMA) to the MAG.
The MAG fulfills its task by sending a proxy binding update (PBU)
message to request binding (and potentially assigning) the MN's home
network prefix (HNP) to its own egress interface address as being the
MN's care-of address (CoA). Following a successful update, the MN's
LMA starts tunneling data packets sent from the correspondent node(s)
(CN) (i.e., which is kept totally unaware about the MN's mobility) to
the MN's CoA, i.e., MAG's egress interface address. The MAG then
decapsulates each data packet sent to the MN's CoA and forwards it to
the MN. It follows, as mentioned earlier, that the MN will always
believe that it is still attached to its home network, especially
that the MAG takes great care of nurturing the MN's belief by
advertising in unicast mode its home prefix in order to convince it
to (re)-configure its HoA.
Our motivation is mainly guided by a requirement in EU and some Asian
countries and from a general desire in others (!!), to protect the
MN's privacy while switching to and moving across foreign networks.
Such protection should enable to provide anonymity and unlinkability
aspects whenever possible. Consequently, privacy protection in a
PMIPv6 environment means first and foremost preventing the MN from
disclosing its HoA within any foreign network and removing any
"linkability" when switching to a new MAG. It follows that an
efficient privacy protection should enable the MN to mask its HoA and
to update the mask each time it switches to a new MAG. It is
noteworthy that updating the mask becomes more efficient for
protecting the MN's privacy if it is applied at higher frequency than
just when switching to a new MAG. While the suggested proposal
enables such enhancement, we don't detail it in this version.
A malicious node (acting independently), has two topological
locations from which, it can learn/detect the MN's HoA (or maybe the
HNP only) and use it to trace the MN's subsequent movements. The
first location is anywhere on-path between the MAG and the MN's LMA.
In such location, the eavesdropper is able to check the inner header
carried in each data packet sent by the MN's HA to its current MAG.
The data packet inner header carries the MN's HoA and the CN's IP
address. With such ability, the eavesdropper can rely for example,
on som prior knowledge/hint to uncover the targeted MN's current
whereabout and even "lock" on it.
The second location is the link to which the MN is attached. In such
Haddad & Krishnan Expires May 11, 2008 [Page 6]
Internet-Draft Proxy MIPv6 Privacy November 2007
location, the eavesdropper is also able to identify the MN and trace
its movements. In addition, other static identifier(s), e.g., the
MN's MAC address, become available and may significantly contribute
in detecting and tracing the MN. However, we consider out of scope
all parameters below the IP layer but we carefully note that our
proposal can also be extended to cover the MAC address, i.e., by
extending the scope of the mask. Privacy issues related to the MAC
layer are detailed in [ANON].
The unlinkability protection can be seriously endangered each time
the MN switches to a foreign network and keeps using its CGA public
key from which, it has generated its HoA. In fact, the requirement
behind PMIPv6 design to enable the MN to retain its HoA means also
that the MN won't be able to change its CGA public key as its HoA
won't remain the same. Consequently, if an eavesdropper learns the
MN's public key (which is far from being a problem!), then it will
always be able to trace the MN after switching to a new MAG(s). In
addition, as applying the mask will generate a pseudo-IPv6 (pIPv6)
address, it is of high importance to make sure that pIPv6 won't be
reused when switching to a new MAG.
The picture of the two separate threats scenarios described above
becomes rapidly more complicated when they are combined. This is the
case where at least two malicious nodes with each following one of
the two scenarios, are coordinating their "search, identify and
trace" activities. In such case, an efficient anonymity and
unlinkability protection can be obtained by simply merging the two
solutions addressing each of the the two scenarios. In other words,
the MN's HoA MUST NOT be disclosed neither on the link between the MN
and its MAG nor anywhere between the MAG and the MN's LMA. Also, the
MN MUST avoid (re)-using its CGA public key and the pIPv6 MUST be
refreshed after the handoff.
In the following section, we address the above scenarios separately
and describe two mechanisms to reduce the eavesdropper's ability to
learn the MN's HoA and/or trace its movements. The combination of
the two protections is highlighted in the last section.
Haddad & Krishnan Expires May 11, 2008 [Page 7]
Internet-Draft Proxy MIPv6 Privacy November 2007
5. Proposed Solutions
5.1. Solution for On-path attacks
Our proposed mechanism addresses the first scenario where an
eavesdropper is located on-path between the MN's MAG and the LMA by
completely eliminating the need for disclosing the MN's HoA in any
data packet sent to the MN's PMA. This is achieved by removing it
from each data packet exchanged between the MN's LMA and its current
MAG, via applying the tunneling optimization (TO) mechanism. As in
the Mobile IPv6 case [MIP6], the TO mechanism can be securely applied
during the PBU/PBA messages exchange between the MAG and the LMA
nodes. In this case, the PMIPv6 signaling exchange should lead both
sides to create a PaT, which can be immediately applied on each data
packet sent by the MN to the correspondent node (CN) and/or tunneled
from the HA to the MN's CoA, i.e., the MAG. This results in a
complete removal of the MN's HoA from the path between the MAG and
the LMA. Consequently, implementing such optimization significantly
complicates the eavesdropper's task of identifying the targeted MN
from snooping into data packets flow(s) exchanged between the MN's
MAG and its LMA. Note that if the MN is using multiple HoAs as it
may be talking to different CNs, then the PMA and HA will have to
generate one PaT for each HoA.
In addition to removing the MN's HoA from data packets and in order
to enhance the unlinkability aspect, it is highly recommended that
the MAG refreshes periodically the MN's CoA, i.e., its own IP egress
interface address, and updates all associated PaT(s) accordingly.
This can be done by re-sending PBU message(s) to the LMA to update
its binding cache entries table.
5.2. Solution for On-link attacks
As mentioned in the second threat scenario, when an eavesdropper is
attached to the same link than the MN, it can easily detect the
unicast RtAdv message sent by the MAG to the MN following a
successful authentication and the receipt of a PBA message (unless
the HNP is obtained via another way, e.g., from the AAA). However,
as disclosing the MN's home network prefix (HNP) alone may be very
sufficient for an eavesdropper to identify the MN, providing privacy
protection to the MN requires a complete "blackout" on its HNP on any
foreign link. Such requirement may also be raised within the MN's
home network as it blocks malicious nodes from learning the MN's HoA
even when it is still attached to its home network. Imposing an HNP
blackout requires the MAG and/or LMA to send special parameters to
the MN in order to enable it to (re)-configure its HoA and at the
same time, generate a special PaT to translate its HoA to another
pIPv6 address in each IP packet sent by the MN as well as in each IP
Haddad & Krishnan Expires May 11, 2008 [Page 8]
Internet-Draft Proxy MIPv6 Privacy November 2007
packet forwarded by the LMA/MAG to the MN. In addition, these
parameters MUST be sent encrypted, which makes it tempting at this
stage to turn to the CGA technique to achieve this particular goal
(i.e., using the MN's CGA public key), then send them in the unicast
RtAdv message. However, as mentioned earlier, using the MN's CGA
public key provides the eavesdropper just another valuable tool to
identify and trace the MN. In order to avoid the CGA impasse, a new
secret called "privacy key (Kp)" should be computed and stored in the
AAA. Computing Kp should be performed when authenticating the MN for
the first time. Note that generating Kp can occur when the MN is
attached to a foreign network. The mechanism(s) to be used to
compute Kp is out of scope of this document.
5.3. Operation
After generating and storing Kp, the AAA may decide to share it with
the MN's LMA. But, in general, Kp is used by the MN and the AAA to
derive the "transient handoff key (THK)", which is then sent to the
MN's current MAG. THK can be sent to the MAG directly by the AAA,
following a successful authentication or by the LMA in the PBA
message. This means that each time the MN has to perform an
authentication, a new THK is computed and sent to the current MAG.
In addition to refreshing THK, the AAA and the MN SHOULD also
generate a pseudo-NAI (pNAI) and bind it to the new TKh to be used.
The new pNAI is used by the MN during the next authentication and is
carried by the PBU message sent by the MAG to the LMA. It follows
that the pNAI MUST be sent to the LMA prior to receiving a PBU
message (e.g., after a successful authentication).
Upon receiving a THK, the MAG SHOULD use it to derive a PaT and to
encrypt the HNP sent by the LMA in order to be advertised to the MN.
For this purpose, the MAG has to signal to the MN its capability to
offer anonymity and unlinkability services. This is done by setting
a new bit called "Privacy (P)" bit in the unicast RtAdv message sent
to the MN. The presence of the "P" bit also indicates to the MN that
it has to generate the PaT which corresponds to the THK computed by
the MN. One way to handle the "P" bit is to set it in the same new
option (called "Unicast RtAdv Authentication (URA)") carrying the
message authentication. Moreover, the MAG MUST use THK to
authenticate all unicast RtAdv messages sent to the MN. Similarly,
the MN MUST use THK to authenticate any RtSol message sent to the
MAG.
Upon receiving a RtAdv message carrying a URA (i.e., following a
successful authentication), the MN proceeds first to check the
message validity with its own THK. If the message is valid then the
MN decrypts the HNP, configures its HoA and generates the
corresponding PaT. Otherwise, the MN should silently discard the
Haddad & Krishnan Expires May 11, 2008 [Page 9]
Internet-Draft Proxy MIPv6 Privacy November 2007
message.
The PaT SHOULD be applied by the MN on each data packet sent to the
CN. The MAG SHOULD apply the PaT on each IP packet sent to the MN's
HoA and on each data packet sent by the MN. It follows that the MN's
HNP is never disclosed on the link. It should be noted that for the
purpose of enhancing the unlinkability while being attached to the
same link, it is highly recommended to periodically refresh the PaT.
In addition to hiding the HNP advertised to the MN, the MAG SHOULD
also run the DAD procedure on the MN's new pIPv6 address before
advertising the HNP to the MN. In case of a collision, the MAG
SHOULD randomly generate a unique pseudo-HNP then share it with the
MN. This is achieved by XORing a random 64-bit parameter with the
corresponding PaT then with the HNP and testing its uniqueness. The
MAG SHOULD then send the 64-bit parameter to the MN in a new option
(called "Pseudo Home Network Prefix (PHNP)") carried by the RtAdv
message. Note that the PHNP MUST be encrypted with THK.
In the unlikely event leading to inserting a PHNP option in the RtAdv
message, the MN MUST use the 64-bit pseudo-HNP to update the PaT
generated from THK. This is done by XORing the 64-bit pseudo-HNP
with the PaT in order to enable generating a new pIPv6 when the data
packet header is XORed with the updated PaT.
It follows from the above, that in order to avoid breaking the MN's
anonymity during an NDP exchange between two MNs, the MAG SHOULD also
act as the "reference" node for any NDP queries. Such enhancement
will enable LiSeND to provide most of features provided by SeND
protocol.
In order to address merging privacy threats scenarios described
earlier, the two mechanisms have to be combined in order to protect
the path between the MAG and the LMA and at the same time, the one
between the MN and the MAG against malicious eavesdroppings. Doing
so provides anonymity and unlinkability features to the MN on the
path between the MN to its LMA. This means that the MN's MAG SHOULD
apply a PaT when dealing with the corresponding LMA and another one
when dealing with the MN in order to mask the MN's HoA or its HNP
from each data packet exchanged between the MN and the CN and/or from
signaling messages exchanged between the MAG and the LMA.
5.4. Future work
Future versions of this work will probe further enhancements for the
LiSeND protocol and possible stretching of anonymity and
unlinkability extensions down to the MAC layer.
Haddad & Krishnan Expires May 11, 2008 [Page 10]
Internet-Draft Proxy MIPv6 Privacy November 2007
6. New Option Format
TBD
Haddad & Krishnan Expires May 11, 2008 [Page 11]
Internet-Draft Proxy MIPv6 Privacy November 2007
7. Security Considerations
This document introduces first LiSeND protocol which is a light and
CGA free version of SeND protocol. LiSeND is shown to be adapted to
the concept of network based mobility where PMIPv6 protocol is a
leading candidate. We describe next how key privacy aspects can be
build on top of LiSeND in a seamless way which does not affect the
MN's unawareness about its mobility.
Our proposal relies on sharing a different "privacy key" between the
MN and each MAG visited by the mobility unaware MN. For this
purpose, and considering the main clients for deploying PMIPv6, we
adopt a realistic approach centered around the existence of a AAA
infrastructure which will enable the MN to be authenticated upon
attachment to foreign network(s). We also consider that the MN is
able to derive the corresponding transient handoff key (THK) after
each successful authentication.
However, in order to avoid sharing the same THK between three
different nodes (i.e., MN, LMA and MAG), and in order to enable
LiSeND to protect the MN against compromised MAG, we suggest sending
a hash of the current THK (H_THK) to the MN's LMA. It follows that
each MAG MUST include H_THK in the PBU message sent to the LMA
following a successful authentication of the MN.
Haddad & Krishnan Expires May 11, 2008 [Page 12]
Internet-Draft Proxy MIPv6 Privacy November 2007
8. References
8.1. Normative References
[CGA] Aura, T., "Cryptographically Generated Addresses (CGA)",
RFC 3792, March 2005.
[MIP6] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support
for IPv6", RFC 3775, June 2004.
[NDP] Narten, T., Nordmark, E., Simpson, W., and H. Soliman,
"Neighbor Discovery for IP version 6 (IPv6)", RFC 4861,
September 2007.
[SeND] Arkko, J., Kempf, J., Sommerfield, B., Zill, B., and P.
Nikander, "Secure Neighbor Discovery (SeND)", RFC 3971,
March 2005.
[TERM] Bradner, S., "Key Words for Use in RFCs to Indicate
Requirement Levels", RFC 2119, BCP , March 1997.
8.2. Informative References
[ANON] Haddad, W., Nordmark, E., Dupont, F., Bagnulo, M., Patil,
B., and H. Tschofenig, "Anonymous Identifiers (ALIEN):
Privacy Threat Model for Mobile and Multi-Homed Nodes",
Internet Draft, draft-haddad-alien-threat-model-00.txt,
January 2007.
[PMIPv6] Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K.,
and B. Patil, "Proxy Mobile IPv6", Internet
Draft, draft-ietf-netlmm-proxymip6-06.txt, september 2007.
[PRITERM] Haddad, W. and E. Nordmark, "Privacy Terminology",
Internet
Draft, draft-haddad-alien-privacy-terminology-03.txt,
October 2007.
[TOM] Haddad, W., Naslund, M., and P. Nikander, "IP Tunneling
Optimization in a Mobile Environment", Internet-
Draft, draft-haddad-mip6-tunneling-optimization-01.txt,
July 2007.
Haddad & Krishnan Expires May 11, 2008 [Page 13]
Internet-Draft Proxy MIPv6 Privacy November 2007
Authors' Addresses
Wassim Haddad
Ericsson Research
Torshamnsgatan 23
SE-164 80 Stockholm
Sweden
Phone: +46 8 4044079
Email: Wassim.Haddad@ericsson.com
Suresh Krishnan
Ericsson Research
8400 Decarie Blvd.
Town of Mount Royal, QC
Canada
Phone: +1 514 345 7900
Email: Suresh.Krishnan@ericsson.com
Haddad & Krishnan Expires May 11, 2008 [Page 14]
Internet-Draft Proxy MIPv6 Privacy November 2007
Full Copyright Statement
Copyright (C) The IETF Trust (2007).
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.
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, THE IETF TRUST 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.
Intellectual Property
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.
Acknowledgment
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
Haddad & Krishnan Expires May 11, 2008 [Page 15]
Html markup produced by rfcmarkup 1.129c, available from
https://tools.ietf.org/tools/rfcmarkup/