[Search] [txt|pdfized|bibtex] [Tracker] [Email] [Nits]
Versions: 00 01 02 03 04                                                
Network Working Group                                    C. Castelluccia
Internet-Draft                                                     INRIA
Expires: August 15, 2005                                       F. Dupont
                                                                  Point6
                                                           G. Montenegro
                                                                Sun Labs
                                                       February 14, 2005


               A Simple Privacy Extension for Mobile IPv6
                  draft-dupont-mip6-privacyext-00.txt

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 15, 2005.

Copyright Notice

   Copyright (C) The Internet Society (2005).

Abstract

   This draft presents a simple privacy extension for Mobile IPv6 that
   prevents eavesdroppers from identifying the packets sent or received
   from a particular mobile node.  This extension also allows a mobile
   node to hide its identity from correspondent nodes when the mobile



Castelluccia, et al.    Expires August 15, 2005                 [Page 1]


Internet-Draft             MIPv6 Privacy Ext               February 2005


   node initiates the communication.

1.  Introduction

   In Mobile IPv6 [RFC3775], the home address of a mobile node is
   included in the packets that it sends and receives.

   As a result any node in the network can identify packets that belong
   to a particular mobile node (and use them to perform some kind of
   traffic analysis) and track its movements (i.e., its care-of address)
   and usage.  We propose a solution to prevent such tracking while
   still using route optimisation.

   In particular our proposal solves the two following problems:

   -  Privacy of mobile client from its correspondent node and from any
      eavesdroppers in the network: the mobile node connects to a remote
      node (a server for example) and wants to hide it identity (i.e.,
      its home address) from this node and from any eavesdropper in the
      network while still being able to move.

   -  Privacy of mobile server from eavesdroppers: the remote node
      initiates the communication and the mobile node is able to hide
      its identity (and therefore its locations) from any eavesdropper
      in the network (but not from the remote node).

   We do not solve the problem of privacy of a mobile server from its
   correspondent nodes.  In this case a mobile node still needs to
   reveal its care-of address to its correspondent nodes to ensure
   optimal routing.  If this level of privacy is desired, one possible
   solution is bi-directional encrypted tunneling via the home agent.
   Full privacy is then provided at the cost of routing performance.  It
   should be noted that [HMIPv6] in revealing the regional care-of
   address (RCoA) instead of the care-of address might be an other
   alternative.

   In this draft we only look at privacy issues in Mobile IPv6 and
   assume that a mobile node's identity is not revealed by other
   protocols such as AAA, IKE,...and by the applications (i.e.
   applications must not include any IP address in their payloads.)

2.  Problem statement

   In Mobile IPv6, the home address of a mobile node is included in
   cleartext in the packets it sends and receives.  In fact, packets
   sent by a mobile node includes a home address option that contains
   its home address.  Packets sent by a correspondent node to a given
   mobile node contains a routing header that includes the mobile home



Castelluccia, et al.    Expires August 15, 2005                 [Page 2]


Internet-Draft             MIPv6 Privacy Ext               February 2005


   address.  As a result, any eavesdropper within the network can easily
   identify packets that belong to a particular mobile node (and use
   them to perform some kind of traffic analysis) and track mobile
   movements and usage.

3.  Possible solutions

   Several solutions are possible, all with their limitations:

   -  IPv6 privacy extension: a solution could be to used the privacy
      extension described in [RFC3041] to configure the home address and
      the care-of addresses.  While this solution represents a marked
      improvement over the default address configuration methods
      [RFC2462], and should be used for the home and care-of addresses,
      we contend that this is not sufficient.  [RFC3041] causes nodes to
      generate global-scope addresses from interface identifiers that
      change over time, even in cases where the interface contains an
      embedded IEEE identifier.  As a result if [RFC3041] is used to
      generate the home address, this address will change periodically
      but the network prefix (64 highest bits) will remain unchanged.
      This network prefix can still reveal much information about the
      mobile node's identity to an eavesdropper.  This mechanism
      described in [RFC3041] must be used for the home address and
      care-of addresses in Mobile IPv6 but one should not rely on it to
      get full privacy protection.

   -  Home address option encryption: an other solution could be to
      encrypt the home address option.  This solution is not
      satisfactory because
         (1) it would require to modify IPsec implementation (security
         associations should then be indexed with the care-of address
         and therefore would need to be updated at each movement of the
         mobile node) and
         (2) it would make the usage of firewalls difficult (currently
         firewalls look at the home address option to perform some
         filtering).
      Futhermore this solution does not solve the problem of incoming
      packets that contain a routing header which reveals the home
      address.

   -  IPsec bi-directional Tunnel (mobile VPN): A solution could be to
      open a bi-directional IPsec tunnel between the mobile node and its
      home agent [RFC3024].  This solution has the following
      disadvantages:
         (1) addition of extra bandwidth (packets need to be
         encapsulated) and processing overhead,
         (2) the routing is suboptimal.




Castelluccia, et al.    Expires August 15, 2005                 [Page 3]


Internet-Draft             MIPv6 Privacy Ext               February 2005


4.  Our Proposal

   In our scheme a mobile node uses the privacy extension described in
   [RFC3041] to configure its home address and care-of addresses.  A
   mobile node must use an interface identifier for its home address
   that is different from the one used for its care-of addresses.  It
   should also use a new interface identifier when configuring a new
   care-of address.  As a result, it would be more difficult for an
   eaversdropper to identify a mobile node's identity and track its
   movement.

   We also propose to assign to each mobile node a TMI (Temporary Mobile
   Identifier) that is a 128-bit long random number.  This TMI is used
   by the mobile node's home agent and correspondent nodes to identify
   the mobile node.  This TMI might be used by the correspondent node to
   index the correspondent IPsec security association to the mobile and
   might be used by firewalls to do filtering.

4.1  Protocol description

   Two cases must be considered:

   -  Mobile Client  (The mobile node initiates the communication).

   -  Mobile Server (the correspondent node initiates the
      communication).

4.1.1  Mobile client

   The mobile then uses standard Mobile IPv6 with the TMI as its home
   address.  Packets sent and received by a mobile node will contain its
   TMI instead of its home address.  As a result, the mobile identity is
   hidden from the correspondent node and from potential eavesdroppers
   in the network.

   Note that in this case the correspondent node must never use the home
   address, i.e., the TMI that is not routable, but must use the care-of
   address (Mobile IPv6 should be modified to provide such
   functionality.)

4.1.2  Mobile Server

   In this case, the correspondent node knows the mobile identity by
   definition.  If a mobile node wants to hide its mobility, i.e.  its
   care-of address, to a particular correspondent node, it must not send
   any binding update to this correspondent node and use bi-directional
   tunneling.  As a result the packets that are sent to the mobile node
   are addressed to its home address and encapsulated by the home agent



Castelluccia, et al.    Expires August 15, 2005                 [Page 4]


Internet-Draft             MIPv6 Privacy Ext               February 2005


   to its current care-of address.  The decision to send or not to send
   a binding update to a correspondent node is a policy issue that is
   out of the scope of this draft.  Any eavesdroppers between the home
   agent and the mobile node is able to identify and track the mobile
   movement by looking at the inner packet.  Therefore we suggest to
   encrypt the packets that are sent between the mobile node and its
   home agent.

   If the mobile node decides to use route optimization, it then sends a
   binding update to its correspondent node.  This binding update
   contains the TMI in the home address option and the actual home
   address is encoded in a newly defined binding update sub-option.  Of
   course to preserve privacy the binding update must be encrypted (the
   security association should be indexed with the TMI and not the home
   address).  The correspondent node uses the binding update to bind the
   TMI with the home address and the care-of address.

   Subsequent packets between the mobile node and the correspondent node
   will contain the TMI in the home address option and in the routing
   header extension instead of the actual home address.  As a result an
   eavesdropper won't be able to identify the packets belonging to a
   particular node.

4.2  Temporary Mobile Identifier (TMI)

4.2.1  TMI generation

   The TMI of a mobile node should be globally unique and must be
   locally unique.  By locally unique we mean that two mobile nodes
   communicating with the same correspondent node/or home agent must use
   different TMIs but two mobile nodes communicating with different
   correspondent nodes can use the same TMI.  The consequences of two
   mobile nodes using the same TMI with the same correspondent node is
   similar than the consequences of two mobile nodes using the same home
   address with standard mobile IPv6.  The correspondent node might get
   confused...

   We propose derive the TMI from the SHA-1 message digest of the mobile
   node's home address.  The mobile node's home address being globally
   unique, the TMI collision probability is therefore very small.
   Furthermore the probably of two mobile nodes generating the same TMI
   and communicating with the same correspondent node is even smaller
   and negligible.

   SHA-1 was chosen because its particular properties were adequate to
   produce the desired level of randomness and uniqueness.  IPv6 nodes
   are already required to implement SHA-1 as part of IPsec [RFC2401].




Castelluccia, et al.    Expires August 15, 2005                 [Page 5]


Internet-Draft             MIPv6 Privacy Ext               February 2005


4.2.2  TMI management

   The TMI of a mobile user must be changed periodically (every few
   minutes, hours or days) in order to avoid TMI leakage as explained in
   [RFC3041]...

   For example, the digest for the new TMI can be generated as follows:
   new digest = SHA-1 (home address | old digest), where "|" stands for
   concatenation.

   A dedicated prefix of 16 bits should used and TMI allocated into this
   prefix (i.e., an address in this prefix is known to be a TMI).  This
   has some drawbacks and many advantages:

   -  the first 16 bits are fixed (but 112 bits should be enough to keep
      the collision probability very close to zero).

   -  a TMI is very easy to recognize by bad guys.

   +  any mobile node can be automatically authorized to use any address
      in this prefix.

   +  this prefix can be marked as unroutable, i.e., a wrong packet to a
      TMI destination will be dropped by the first router, not the first
      default free router.  In general misuses of TMI become very easy
      to detect.

5.  Security Considerations

   This document address some privacy issues in the mobile IPv6
   protocols.  Even if privacy does not provide real security (i.e.,
   security through obscurity is poor security) then it makes the job of
   bad guys (eavesdroppers, rogue correspondents, ...) harder so should
   improve the overall security.

6.  Acknowledgments

   John Wells (INRIA), Karim El-Malki (Ericsson), Hesham Soliman
   (Ericsson), Jean-Michel Combes (France Telecom DR&D), Imad Add
   (INRIA), Pars Mutaf (INRIA)...

7.  History

   This document was directly extracted from an old proposition by the
   first two authors.  CBID (Crypto-Based IDentifier) and HMIPv6
   extensions / improvements were removed to keep the first version of
   this draft very small.




Castelluccia, et al.    Expires August 15, 2005                 [Page 6]


Internet-Draft             MIPv6 Privacy Ext               February 2005


8.  IANA Considerations

   Allocation of the needed prefix is the subject of [ID.cgpref].

9.  References

9.1  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", RFC 2119, BCP 14, March 1997.

   [RFC2462]  Thomson, S. and T. Narten, "IPv6 Stateless Address
              Autoconfiguration", RFC 2462, December 1998.

   [RFC3041]  Narten, T. and R. Draves, "Privacy Extensions for
              Stateless Address Autoconfiguration in IPv6", RFC 3041,
              January 2001.

   [RFC3775]  Johnson, D., Perkins, C. and J. Arkko, "Mobility Support
              in IPv6", RFC 3775, June 2004.

9.2  Informative References

   [HMIPv6]   Soliman, H., Castelluccia, C., El Malki, K. and L.
              Bellier, "Hierarchical Mobile IPv6 mobility management
              (HMIPv6)", draft-ietf-mipshop-hmipv6-04.txt (work in
              progress), December 2005.

   [ID.cgpref]
              Dupont, F., Ed., "An IPv6 Prefix for Cryptographically
              Generated IDs", draft-dupont-ipv6-cgpref-00.txt (work in
              progress), January 2005.

   [RFC2401]  Kent, S. and R. Atkinson, "Security Architecture for the
              Internet Protocol", RFC 2401, November 1998.

   [RFC3024]  Montenegro, G., Ed., "Reverse Tunneling for Mobile IP,
              revised", RFC 3024, December 2001.


Authors' Addresses

   Claude Castelluccia
   INRIA

   EMail: Claude.Castelluccia@inria.fr





Castelluccia, et al.    Expires August 15, 2005                 [Page 7]


Internet-Draft             MIPv6 Privacy Ext               February 2005


   Francis Dupont
   Point6
   c/o GET/ENST Bretagne

   EMail: Francis.Dupont@enst-bretagne.fr


   Gabriel Montenegro
   Sun Labs

   EMail: gab@sun.com








































Castelluccia, et al.    Expires August 15, 2005                 [Page 8]


Internet-Draft             MIPv6 Privacy Ext               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.




Castelluccia, et al.    Expires August 15, 2005                 [Page 9]