MIP6 Working Group                                             Rajeev Koodli
INTERNET DRAFT                                         Nokia Research Center
2 February 2007

    IP Address Location Privacy and Mobile IPv6: Problem Statement

    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 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

    The list of current Internet-Drafts can be accessed at

    The list of Internet-Draft Shadow Directories can be accessed at

    This document is a submission of the IETF MIP6 WG. Comments should
    be directed to the MIP6 WG mailing list, mip6@ietf.org.


    In this document, we discuss Location Privacy as applicable to
    Mobile IPv6.   We document the concerns arising from revealing Home
    Address to an on-looker and from disclosing Care of Address to a

Koodli                    Expires 2 August 2007                  [Page i]

Internet Draft        IP Location Privacy Problem         2 February 2007


Abstract                                                                      i

 1.  Introduction                                                             1

 2.  Definitions                                                              3

 3.  Problem Definition                                                       4
      3.1.  Disclosing the Care-of Address to the Correspondent Node          4
      3.2.  Revealing the Home Address to On-lookers   .  .  .  .  .  .  .    4
      3.3.  Problem Scope .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .   4

 4.  Problem Illustration                                                     5

 5.  Conclusion                                                               8

 6.  IANA Considerations                                                      8

 7.  Security Considerations                                                  8

 8.  Acknowledgment                                                           9

 9.  References                                                               9
      9.1.  Normative References   .  .  .  .  .  .  .  .  .  .  .  .  .  .   9
      9.2.  Informative References   .  .  .  .  .  .  .  .  .  .  .  .  .    9

10.  Author's Address                                                        10

 A.  Background                                                              11

Intellectual Property Statement                                              12

Disclaimer of Validity                                                       12

Koodli                    Expires 2 August 2007                      [Page ii]

Internet Draft        IP Location Privacy Problem            2 February 2007

Copyright Statement                                                          13

Acknowledgment                                                               13

    1. Introduction

    The problems of location privacy, and privacy when using IP
    for communication have become important.   IP privacy is broadly
    concerned with protecting user communication from unwittingly
    revealing information that could be used to analyze and gather
    sensitive user data.   Examples include gathering data at certain
    vantage points, collecting information related to specific traffic,
    and monitoring (perhaps) certain populations of users for activity
    during specific times of the day, etc.   In this document, we refer
    to this as the "profiling" problem.

    Location privacy is concerned with the problem of revealing
    roaming, which we define here as the process of a Mobile Node
    (MN) moving from one network to another with or without on-going
    sessions.   A constant identifier with global scope can reveal
    roaming.   Examples are a device identifier such as an IP address,
    and a user identifier such as a SIP [9] URI [2].   Often, a binding
    between these two identifiers is available, e.g., through DNS [5].
    Traffic analysis of such IP and Upper Layer Protocol identifiers
    on single network can indicate device and user roaming.   Roaming
    could also be inferred by means of profiling constant fields in IP
    communication across multiple network movements.   For example, an
    Interface Identifier (IID) [10 ] in the IPv6 address that remains
    unchanged across networks could suggest roaming.   The SPI in the
    IPsec [4] header is another field that may be subject to such
    profiling and inference.   Inferring roaming in this way typically
    requires traffic analysis across multiple networks, or colluding
    attackers, or both.   When location privacy is compromised, it could
    lead to more targetted profiling of user communication.

    As can be seen, the location privacy problem spans multiple
    protocol layers.   Nevertheless, it is important to understand and

Koodli                    Expires 2 August 2007                  [Page 1]

Internet Draft        IP Location Privacy Problem         2 February 2007

    specify the problem as applicable to concerned protocols in order
    to at least mitigate the effects of the problem.   In this context,
    it is particularly important to Mobile IP, which defines a global
    identifier (Home Address) that can reveal device roaming, and in
    conjunction with a corresponding user identifier (such as a SIP
    URI), can also reveal user roaming.   Furthermore, a user may not
    wish to reveal roaming to correspondent(s), which translates to the
    use of Care-of Address.   As with Home Address, the Care-of Address
    can also reveal the topological location of the Mobile Node.

    This document describes the concerns arising from the use of Home
    Address from a visited network.   This document also outlines the
    considerations in disclosing a Care-of Address.   This document
    is primarily concerned with the vulnerabilities arising from
    possible traffic analysis along the MN - CN path and the MN - HA
    path, where the disclosure of Mobile IP addresses is sufficient to
    reveal roaming.   This document does not consider inferring roaming
    from profiling fields such as an IID or an SPI for the following
    reasons:   First, such inference could be done independently, so the
    problem is not specific to Mobile IP. Second, with Mobile IP, it
    is sufficient to simply monitor the usage of Home Address from a
    single visited network in order to deduce roaming.   In other words,
    the attackers need not conduct traffic profiling across multiple
    networks, or collude with each other, or do both in order to infer
    roaming when Mobile IP is used.   Hence, we limit the scope of this
    document to revealing the Mobile IP addresses.

    This document is only concerned with IP Address Location Privacy
    in the context of Mobile IPv6.   It does not address the overall
    privacy problem.   For instance, it does not address privacy
    issues related to MAC addresses or the relationship of IP and MAC
    addresses [3], or the Upper Layer Protocol addresses.   Solution
    to the problem specified here should provide protection against
    roaming disclosure due to using Mobile IPv6 addresses from a
    visited network.

Koodli                    Expires 2 August 2007                  [Page 2]

Internet Draft        IP Location Privacy Problem         2 February 2007

    This document assumes that the reader is familiar with the basic
    operation of Mobile IPv6 [1] and the associated terminology defined
    therein.   For convenience, we provide some definitions below.

    2. Definitions

     -  Mobile Node (MN): A Mobile IPv6 Mobile Node that freely roams
        around networks

     -  Correspondent Node (CN): A Mobile IPv6 that node corresponds
        with a MN

     -  Home Network:   The network where the MN is normally present
        when it is not roaming

     -  Visited Network:   A network which a MN uses to access Internet
        when it is roaming

     -  Home Agent:   A router on the MN's home network which provides
        forwarding support when the MN is roaming

     -  Home Address (HoA): The MN's unicast IP address valid on its
        home network

     -  Care-of Address (CoA): The MN's unicast IP address valid on the
        visited network

     -  Reverse Tunneling or Bidirectional Tunneling:   A mechanism used
        for packet forwarding between the MN and its Home Agent

     -  Route Optimization:   A mechanism which allows direct routing
        of packets between a roaming MN and its CN, without having to
        traverse the home network.

Koodli                    Expires 2 August 2007                  [Page 3]

Internet Draft        IP Location Privacy Problem         2 February 2007

    3. Problem Definition

    3.1. Disclosing the Care-of Address to the Correspondent Node

    When a Mobile IP MN roams from its home network to a visited
    network or from one visited network to another, use of Care-of
    Address in communication with a correspondent reveals that the
    MN has roamed.   This assumes that the correspondent is able to
    associate the Care-of Address to Home Address, for instance by
    inspecting the Binding Cache Entry.   The Home Address itself is
    assumed to have been obtained by whatever means (e.g., through DNS

    3.2. Revealing the Home Address to On-lookers

    When a Mobile IP MN roams from its home network to a visited
    network or from one visited network to another, use of Home Address
    in communication reveals to an on-looker that the MN has roamed.
    When a binding of Home Address to a user identifier (such as
    a SIP URI) is available, the Home Address can be used to also
    determine that the user has roamed.   This problem is independent
    of whether the MN uses Care-of Address to communicate directly
    with the correspondent (i.e., uses route optimization), or the MN
    communicates via the Home Agent (i.e., uses reverse tunneling).

    Location privacy may be compromised if an on-looker is present
    on the MN - HA path (when bidirectional tunneling is used), or
    when the on-looker is present on the MN and CN path (when route
    optimization is used).

    3.3. Problem Scope

    With existing Mobile IPv6 solutions, there is some protection
    against location privacy.   If a Mobile Node uses reverse tunneling
    with ESP encryption, then the Home Address is not revealed on
    the MN - HA path.   So, eavesdroppers on the MN - HA path cannot

Koodli                    Expires 2 August 2007                 [Page 4]

Internet Draft        IP Location Privacy Problem        2 February 2007

    determine roaming.   They could, however, still profile fields in
    the ESP header; however, this problem is not specific to Mobile
    IPv6 location privacy.

    When a MN uses reverse tunneling (regardless of ESP encryption),
    the correspondent does not have access to the Care-of Address.
    Hence, it cannot determine that the MN has roamed.

    Hence, the location privacy problem is particularly applicable when
    Mobile IPv6 route optimization is used or when reverse tunneling
    is used without protecting the inner IP packet containing the Home

    4. Problem Illustration

    This section is intended to provide an illustration of the problem
    defined in the previous section.

    Consider a Mobile Node at its home network.   Whenever it is
    involved in IP communication, its correspondents can see an
    IP address valid on the home network.   Elaborating further,
    the users involved in peer - peer communication are likely
    to see a user-friendly identifier such as a SIP URI, and the
    communication end-points in the IP stack will see IP addresses.
    Users uninterested in or unaware of IP communication details will
    not see any difference when the MN acquires a new IP address.
    Of course any user can ``tcpdump'' or ``ethereal'' a session,
    capture IP packets and map the MN's IP address to an approximate
    geo-location.   This mapping may reveal the home location of a
    user, but a correspondent cannot ascertain whether the user has
    actually roamed or not.   Assessing the physical location based on
    IP addresses has some similarities to assessing the geographical
    location based on the area-code of a telephone number.   The
    granularity of the physical area corresponding to an IP address
    can vary depending on how sophisticated the available tools are,
    how often an ISP conducts its network re-numbering, etc.   And,

Koodli                    Expires 2 August 2007               [Page 5]

Internet Draft        IP Location Privacy Problem      2 February 2007

    an IP address cannot also guarantee that a peer is at a certain
    geographic area due to technologies such as VPN and tunneling.

    When the MN roams to another network, the location privacy problem
    consists of two parts:   revealing information to its correspondents
    and to on-lookers.

    With its correspondents, the MN can either communicate directly
    or reverse tunnel its packets through the Home Agent.   Using
    reverse tunneling does not reveal Care-of Address of the MN,
    although end-to-end delay may vary depending on the particular
    scenario.   With those correspondents with which it can disclose its
    Care-of Address ``on the wire'', the MN has the option of using
    route-optimized communication.   The transport protocol still sees
    the Home Address with route optimization.   Unless the correspondent
    runs some packet capturing utility, the user cannot see which mode
    (reverse tunneling or route optimization) is being used, but knows
    that it is communicating with the same peer whose URI it knows.
    This is similar to conversing with a roaming cellphone user whose
    phone number, like the URI, remains unchanged.

    Regardless of whether the MN uses route optimization or reverse
    tunneling (without ESP encryption), its Home Address is revealed
    in data packets.   When equipped with an ability to inspect packets
    ``on the wire'', an on-looker on the MN - HA path can determine
    that the MN has roamed and could possibly also determine that
    the user has roamed.   This could compromise the location privacy
    even if the MN took steps to hide its roaming information from a

    The above description is valid regardless of whether a Home Address
    is statically allocated or is dynamically allocated.   In either
    case, the mapping of IP address to geo-location will most likely
    yield results with the same level of granularity.   With the freely
    available tools on the Internet, this granularity is the physical
    address of the ISP or the organization which registers ownership of
    a prefix chunk.   Since an ISP or an organization is not, rightly,
    required to provide a blue-print of its subnets, the granularity

Koodli                    Expires 2 August 2007                 [Page 6]

Internet Draft        IP Location Privacy Problem        2 February 2007

    remains fairly coarse for a mobile wireless network.   However,
    sophisticated attackers might be able to conduct site mapping and
    obtain more fine-grained subnet information.

    A compromise in location privacy could lead to more targetted
    profiling of user data.   An eavesdropper may specifically track
    the traffic containing the Home Address, and monitor the movement
    of the Mobile Node with changing Care-of Address.   The profiling
    problem is not specific to Mobile IPv6, but could be triggered
    by a compromise in location privacy due to revealing the Home
    Address.   A correspondent may take advantage of the knowledge that
    a user has roamed when Care-of Address is revealed, and modulate
    actions based on such a knowledge.   Such an information could cause
    concern to a mobile user especially when the correspondent turns
    out be untrustworthy.   For these reasons, appropriate management
    interfaces on the MN to guard against the misuse of location
    information should be considered.

    Applying existing techniques to thwart profiling may have
    implications to Mobile IPv6 signaling performance.   For instance,
    changing the Care-of Address often would cause additional Return
    Routability [1] and binding management signaling.   And, changing
    the Home Address often has implications on IPsec security
    association management.   Solutions should be careful in considering
    the cost of change of either Care-of Address or Home Address on

    When roaming, a MN may treat its home network nodes as any other
    correspondents.   Reverse tunneling is perhaps sufficient for home
    network communication, since route-optimized communication will
    traverse the identical path.   Hence, a MN can avoid revealing its
    Care-of Address to its home network correspondents simply by using
    reverse tunneling.   The Proxy Neighbor Advertisements [7] from the
    Home Agent could serve as hints to the home network nodes that the
    Mobile Node is away.   However, they will not be able to know the
    Mobile Node's current point of attachment unless the MN uses route
    optimization with them.

Koodli                    Expires 2 August 2007                  [Page 7]

Internet Draft        IP Location Privacy Problem         2 February 2007

    5. Conclusion

    In this document, we have discussed the location privacy problem
    as applicable to Mobile IPv6.   The problem can be summarized
    as follows:   disclosing Care-of Address to a correspondent and
    revealing Home Address to an on-looker can compromise the location
    privacy of a Mobile Node, and hence that of a user.   We have seen
    that bidirectional tunneling allows a MN to protect its Care-of
    Address to the CN. And, ESP encryption of inner IP packet allows
    the MN to protect its Home Address from the on-lookers on the MN -
    HA path.   However, with route optimization, the MN will reveal its
    Care-of Address to the CN. Moreover, route optimization causes the
    Home Address to be revealed to on-lookers in the data packets as
    well as in Mobile IPv6 signaling messages.   The solutions to this
    problem are expected to be protocol specifications assuming the
    existing Mobile IPv6 functional entities, namely, the Mobile Node,
    its Home Agent and the Correspondent Node.

    6. IANA Considerations

    There are no IANA considerations introduced by this draft.

    7. Security Considerations

    This document discusses the location privacy problem specific to
    Mobile IPv6.   Any solution must be able to protect (e.g., using
    encryption) the Home Address from disclosure to on-lookers in
    data packets when using route optimization or reverse tunneling.
    In addition, solutions must consider protecting the Mobile IPv6
    signaling messages from disclosing the Home Address along the MN -
    HA and MN - CN paths.

    Disclosing the Care-of Address is inevitable if a MN wishes to
    use route optimization.   Regardless of whether Care-of Address
    is an on-link address of the MN on the visited link or that of
    a co-operating proxy, mere presence of Binding Cache entry is

Koodli                    Expires 2 August 2007                [Page 8]

Internet Draft        IP Location Privacy Problem       2 February 2007

    sufficient for a CN to ascertain roaming.   Hence, a MN concerned
    with location privacy should exercise prudence in determining
    whether to use route optimization with, especially previously
    unacquainted, correspondents.

    The solutions should also consider the use of temporary addresses
    and their implications on Mobile IPv6 signaling as discussed in
    Section 4.   Use of IP addresses with privacy extensions [6] could
    be especially useful for Care-of Addresses if appropriate tradeoffs
    with Return Routability signaling are taken into account.

    8. Acknowledgment

    Thanks to James Kempf, Qiu Ying, Sam Xia and Lakshminath Dondeti
    for the review and feedback.   Thanks to Jari Arkko and Kilian
    Weniger for the last call review and for suggesting improvements
    and text.

    9. References

    9.1. Normative References

    [1]  D. Johnson, C. Perkins, and J. Arkko. Mobility Support in
         IPv6. Request for Comments 3775, Internet Engineering Task
         Force, June 2004.

    9.2. Informative References

    [2]  T. Berners-Lee, R. Fielding, and L. Masinter. Uniform Resource
         Identifiers (URI): Generic Syntax. Request for Comments (Draft
         Standard) 2396, Internet Engineering Task Force, August 1998.

Koodli                    Expires 2 August 2007                 [Page 9]

Internet Draft        IP Location Privacy Problem        2 February 2007

    [3]  W. Haddad and et al., Privacy for Mobile and Multi-homed
         Nodes:   MoMiPriv Problem Statement (work in progress).
         Internet Draft, Internet Engineering Task Force, October 2004.

    [4]  S. Kent and K. Seo. Security Architecture for the Internet
         Protocol. Request for Comments (Proposed Standard) 4301,
         Internet Engineering Task Force, December 2005.

    [5]  P. V. Mockapetris. Domain names - implementation and
         specification. Request for Comments (Standard) 1035, Internet
         Engineering Task Force, November 1987.

    [6]  T. Narten and R. Draves. Privacy Extensions for Stateless
         Address Autoconfiguration in IPv6. Request for Comments 3041,
         Internet Engineering Task Force, January 2001.

    [7]  T. Narten, E. Nordmark, and W. Simpson. Neighbor Discovery for
         IP Version 6 (IPv6). Request for Comments (Draft Standard)
         2461, Internet Engineering Task Force, December 1998.

    [8]  J. Polk, J. Schnizlein, and M. Linsner. DHCP Option for
         Coordinate-based Location Configuration Information. Request
         for Comments 3825, Internet Engineering Task Force, July 2004.

    [9]  J. Rosenberg and et al. SIP: Session Initiation Protocol.
         Request for Comments (Proposed Standard) 3261, Internet
         Engineering Task Force, June 2002.

    [10] S. Thomson and T. Narten. IPv6 Stateless Address
         Autoconfiguration. Request for Comments (Draft Standard) 2462,
         Internet Engineering Task Force, December 1998.

    10. Author's Address

      Rajeev Koodli
      Nokia Research Center
      975 Page Mill Road, 200

Koodli                    Expires 2 August 2007               [Page 10]

Internet Draft        IP Location Privacy Problem       2 February 2007

      Palo Alto, CA 94034 USA
      Phone: +1 408 425 6684
      Fax: +1 650 625 2502
      E-Mail: Rajeev.Koodli@nokia.com

    A. Background

    The location privacy topic is broad and often has different
    connotations.   It also spans multiple layers in the OSI reference
    model.   Besides, there are attributes beyond an IP address alone
    that can reveal hints about location.   For instance, even if a
    correspondent is communicating with the same end-point it is used
    to, the ``time of the day'' attribute can reveal a hint to the
    user.   Some roaming cellphone users may have noticed that their SMS
    messages carry a timestamp of their ``home network'' timezone (for
    location privacy or otherwise) which can reveal that the user is in
    a different timezone when messages are sent during ``normal'' time
    of the day.   Furthermore, tools exist on the Internet which can map
    an IP address to the physical address of an ISP or the organization
    which owns the prefix chunk.   Taking this to another step, with
    in-built GPS receivers on IP hosts, applications can be devised
    to map geo-locations to IP network information.   Even without GPS
    receivers, geo-location can also be obtained in environments where
    [Geopriv] is supported, for instance as a DHCP option [8].

    In summary, a user's physical location can be determined or
    guessed with some certainty and with varying levels of granularity
    by different means even though IP addresses themselves do not
    inherently provide any geo-location information.   It is perhaps
    useful to bear this broad scope in mind as the problem of IP
    address location privacy in the presence of IP Mobility is

Koodli                    Expires 2 August 2007               [Page 11]

Internet Draft        IP Location Privacy Problem       2 February 2007

    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

    Disclaimer of Validity

    This document and the information contained herein are provided

Koodli                    Expires 2 August 2007               [Page 12]

Internet Draft        IP Location Privacy Problem        2 February 2007

    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.


    Funding for the RFC Editor function is currently provided by the
    Internet Society.

Koodli                    Expires 2 August 2007                [Page 13]