[Search] [pdf|bibtex] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03                                                   
Network Working Group                                          W. Haddad
Internet-Draft                                         Ericsson Research
Expires: December 28, 2006                                   E. Nordmark
                                                        Sun Microsystems
                                                               F. Dupont
                                                              M. Bagnulo
                                                                B. Patil
                                                           June 26, 2006

      Privacy for Mobile and Multi-homed Nodes: Problem Statement

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-

   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

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

   This Internet-Draft will expire on December 28, 2006.

Copyright Notice

   Copyright (C) The Internet Society (2006).


   This memo describes the privacy in mobility and multi-homing problem

Haddad, et al.          Expires December 28, 2006               [Page 1]

Internet-Draft         MoMiPriv Problem Statement              June 2006


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Conventions used in this document  . . . . . . . . . . . . . .  4
   3.  Glossary . . . . . . . . . . . . . . . . . . . . . . . . . . .  5
   4.  Problem Statement  . . . . . . . . . . . . . . . . . . . . . .  7
     4.1.  Location Privacy vs. Privacy . . . . . . . . . . . . . . .  7
     4.2.  The MAC Layer Problem  . . . . . . . . . . . . . . . . . .  8
     4.3.  The IP Layer Problem . . . . . . . . . . . . . . . . . . .  9
     4.4.  The Security Problem . . . . . . . . . . . . . . . . . . . 11
       4.4.1.  The IPsec Problem  . . . . . . . . . . . . . . . . . . 11
       4.4.2.  The Secure Neighbor Discovery (SEND) Problem . . . . . 12
     4.5.  The Interdependency Problem  . . . . . . . . . . . . . . . 13
   5.  Security Considerations  . . . . . . . . . . . . . . . . . . . 14
   6.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15
   7.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 15
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17
   Intellectual Property and Copyright Statements . . . . . . . . . . 19

Haddad, et al.          Expires December 28, 2006               [Page 2]

Internet-Draft         MoMiPriv Problem Statement              June 2006

1.  Introduction

   In the near future, mobility and multi-homing functionalities will
   coexist in the majority of end hosts, such as terminals, PDAs, etc.
   For this purpose, Mobile IPv6 [MIPv6] protocol has been designed to
   provide a solution for the mobility at the network layer while Multi-
   homing is still an ongoing work.

   MIPv6 does not provide any mechanism to protect the mobile node's
   privacy when moving across the Internet, while in the multi-homing
   area, the privacy may well be supported in any potential solution but
   may probably lack some features.  This is mainly due to the fact that
   the privacy issues are not limited to the IP layer only.

   This memo describes the privacy in mobility and multi-homing
   (momipriv) problem statement based on IPv6 only.

Haddad, et al.          Expires December 28, 2006               [Page 3]

Internet-Draft         MoMiPriv Problem Statement              June 2006

2.  Conventions used in this document

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   document are to be interpreted as described in [TERM].

Haddad, et al.          Expires December 28, 2006               [Page 4]

Internet-Draft         MoMiPriv Problem Statement              June 2006

3.  Glossary

   For privacy related terminology, please refer to [PRITERM].

   MAC Address

   A MAC Address is a 48 bits unique value associated with a network
   adapter.  The MAC address uniqueness is by default global.  A MAC
   Address is also known as the device/hardware identifier.


   A communication facility or medium over which nodes can communicate
   at the link layer, such as an Ethernet (simple or bridged).  A link
   is the layer immediately below IP.

   IPv6 Address

   An IP address is a unique 128-bit IP layer identifier for an
   interface or a set of interfaces attached to an IP network.
   An IPv6 address can be unicast, i.e., identifier for a single
   interface, or anycast, i.e., an identifier for a set of interfaces,
   and a packet sent to an anycast address is delivered to only one
   interface, or multicast, i.e., an identifier for a set of interfaces
   and a packet sent to a multicast address is delivered to all these

   Interface Identifier

   A number used to identify a node's interface on a link.  The
   interface identifier is the remaining low-order bits in the node's IP
   address after the subnet prefix.

   Basic Service Set (BSS)

   A set of stations controlled by a single coordination function.

   Extended Service Set (ESS)

   A set of one or more interconnected basic service set (BSSs) and
   integrated local area networks (LANs) that appears as a single BSS to
   the logical link control layer at any station associated with one of

Haddad, et al.          Expires December 28, 2006               [Page 5]

Internet-Draft         MoMiPriv Problem Statement              June 2006

   those BSSs.

   Distribution System (DS)

   A system used to interconnect a set of basic service sets (BSSs) and
   integrated local area networks (LANs) to create an extended service
   set (ESS).

Haddad, et al.          Expires December 28, 2006               [Page 6]

Internet-Draft         MoMiPriv Problem Statement              June 2006

4.  Problem Statement

   The growing ability to trace a mobile node by an untrusted third
   party, especially in public access networks, is a direct and serious
   violation of the mobile user's privacy and can cause serious damage
   to its personal, social and professional life.  Privacy becomes a
   real concern especially when the mobile node (MN) uses permanent
   device and/or network identifiers.  Unfortunately, the privacy
   problem is not limited to a single layer and should not be solved
   independantly on one layer.

   Protecting the user's privacy can be achieved, in many scenarios, by
   providing one or many of the privacy aspects defined above with
   regards to the mobile node's requirements and/or location.  For this
   purpose, we try in the rest of this document to use the terms defined
   above, in order to highlight the issues in a more precise way.

   It should be noted that this document focuses only on the privacy
   problem for a mobile and multi-homed node only and does not make any
   assumption regarding the privacy of a static node, e.g., static
   correspondent node (CN).  In addition, this document assumes that the
   real IPv6 address is not hidden by default, i.e., any node is always
   reachable via its real IPv6 address.

   The problem statement is divided into four problems.  The first two
   problems focus on the MAC and IP layers identifiers associated with a
   mobile device, i.e., MAC and IP addresses, and describe privacy
   issues resulting from using these identifiers in the context of a
   mobile and multi-homed environment.  The third problem addresses
   privacy issues resulting from applying security mechanisms, e.g., IP
   Security (IPsec) and Securing Neighbor Discovery (SEND) while the
   fourth problem highlights the interdependency between the three
   problems, as being the main requirement to be considered when
   designing any potential solution.

   But before delving into these problems, a quick overview on
   differences between location privacy and privacy is provided.

4.1.  Location Privacy vs. Privacy

   Before describing privacy problems related to the IP and the link
   layer, it seems useful to highlight the differences between the
   location privacy and privacy, in order to avoid a possible confusion

   Location privacy is the ability to prevent other parties from
   learning one's current or past location [LOPRIPEC].  In order to get
   such ability, the mobile node must conceal any relation between its

Haddad, et al.          Expires December 28, 2006               [Page 7]

Internet-Draft         MoMiPriv Problem Statement              June 2006

   location and the personal identifiable information.  Note that in the
   momipriv context, the mobile node location refers normally to the
   topological location and not the geographic one.  The latter is
   provided by other means (e.g., GPS) than an IPv6 address.  But it
   should be noted that it may possible sometimes to deduce the
   geographical location from the topological one.

   However, concealing any relation between the location and the user's
   identifier(s) does not guarantee that the identifier(s) itself will
   not be disclosed, since it may be possible to hide the real location
   alone.  But, having at least one user's identifier disclosed may be
   enough (e.g., if coupled with prior knowledge about few possible
   whereabouts) for other party to discover the user's current and/or
   previous location(s).

   For example, in a context limited to IP and MAC layers, the only
   available identifiers and/or locators are the IP and MAC addresses,
   and only the IP address carries information, which can directly
   disclose the MN's location (note that mobile IPv6 discloses both the
   mobile node's home and current locations).

   The MAC address alone does not provide any hint regarding the mobile
   node current/previous location.  But if the other party has already
   established the link between the target and its MAC address and
   gained knowledge about some of the user's possible current/future
   whereabouts, then it will be possible to locate and even track the

   On the other side, it should be noted that the two main privacy
   aspects, i.e., anonymity and pseudonymity, provide implicitly the
   location privacy feature by concealing the real user's identifiers
   regardless of his/her location(s).
   Actually, in both privacy aspects, real identifiers are replaced by
   static or dynamic ones, thus making the other party no more able to
   identify its target even at the correct location, i.e., any past/
   current location information becomes practically useless for locating
   and tracking purposes.

4.2.  The MAC Layer Problem

   The first problem focus on the MAC layer and is raising growing
   concerns related to the user's privacy, especially with the massive
   ongoing indoor/outdoor deployment of WLAN technologies.

   A mobile device attached to a particular link is uniquely identified
   on that link by its MAC address, i.e., the device identifier.  In
   addition, the device identifier is disclosed in any packet sent by/to
   the MN when it reaches that particular link, thus making it a very

Haddad, et al.          Expires December 28, 2006               [Page 8]

Internet-Draft         MoMiPriv Problem Statement              June 2006

   efficient tool to trace a mobile user in a shared wireless medium
   access.  Similar problems have caused bad press for cellular

   For example, a malicious node located in one distributed system (DS)
   can trace a mobile node via its device identifier while moving in the
   entire ESS, and learn enough information about the user's activities
   and whereabouts.  Having these information available in the wrong
   hands, especially with the exact time when they occur, may have bad
   consequences on the user.

   Another concern on the MAC layer, which can also be exploited by an
   eavesdropper to trace its victim, is the sequence number (SQN)
   carried by the frame header.  The sequence number is incremented by 1
   for each data frame and allows the bad guy to trace its targeted
   node, in addition to the MAC address.
   In addition, the sequence number allows also the malicious node to
   keep tracing the MN, if/when the real MAC address is replaced by one
   or many pseudo-identifier(s) during an ongoing session [WLAN-IID].

   In addition, it should be noted that even if the real MN's device
   identifier remains undisclosed during all ongoing session(s), it may
   probably not be enough to provide the unlinkability protection on the
   MAC layer, between ongoing session(s).
   Actually, in a scenario, where the malicious node is located on the
   link or within the distributed system, replacing the real MAC address
   with a static pseudo-identifier, i.e., to provide pseudonymity, or
   with temporary ones, i.e., to provide anonymity, it will always be
   possible to break the unlinkability protection provided by the MAC
   layer if the MN's IPv6 address remains unchanged.

   Note that in such scenario, even a periodical change of the sequence
   number won't prevent the eavesdropper from correlating ongoing
   session(s), pseudo-identifiers and the mobile node.

   However, it should be mentioned that replacing the real device
   identifier with static/dynamic pseudo-identifiers, in order to
   provide anonymity/pseudonymity, during an ongoing session(s), raises
   another critical issue on the MAC layer level, which concerns the
   uniqueness of these new pseudo-identifier(s).

   In fact, any temporary/static identifiers MUST be unique within the
   Extended Service Set (ESS) and the distributed system (DS).

4.3.  The IP Layer Problem

   The second problem focus on the IP layer and analyzes the privacy
   problems related to IPv6 only.

Haddad, et al.          Expires December 28, 2006               [Page 9]

Internet-Draft         MoMiPriv Problem Statement              June 2006

   A MN can configure its IPv6 address either from a DHCP server or by
   itself.  The latter scenario is called the stateless address
   autoconfiguration [STAT], and discloses the MN MAC address in the
   IPv6 address, thus enabling an eavesdropper to easily learn both
   addresses in this case.

   In order to mitigate the privacy concerns raised from using the
   stateless address auto-configuration, [Privacy] introduced a method
   allowing to periodically change the MN's interface identifier.
   However, being limited to the interface identifier only, such change
   discloses the real network identifier, which in turn can reveal
   enough information about the topological location, the user or can
   even be the exact piece of information needed by the eavesdropper.
   Another limitation to its efficiency lays in the fact that such
   change cannot occur during an ongoing session.

   While using only a different IPv6 address for each new session may
   prevent/mitigate the ability to trace a MN on the IP layer level, it
   remains always possible to trace it through its device identifier(s)
   on the MAC layer level, i.e., when a malicious node (or another one)
   is also attached to the same link/DS than its target.
   Consequently, it will be possible to learn all IPv6 addresses used by
   the MN by correlating different sessions, thus breaking any
   unlinkability protection provided at the IP layer.

   MIPv6 allows an MN to move across the Internet while ensuring optimal
   routing (i.e., by using route optimization (RO)) mode and keeping
   ongoing session(s) alive.  Although these two features make the RO
   mode protocol looks efficient, they disclose the MN's home IPv6
   address and its current location, i.e., care-of address (CoA), in
   each data packet exchanged between the MN and the correspondent node

   Furthermore, each time a MN switches to a new network, it has to send
   in clear a binding update (BU) message to the CN to notify it about
   its new location.

   Consequently, MIPv6 RO mode discloses to a malicious node located
   between the MN and the CN, all data required to identify, locate and
   trace in real time its mobile target, once it moves outside its home
   network(s) [Priv-NG].

   MIPv6 defines another mode called the bidirectional tunneling (BT),
   which allows the MN to hide its movements and locations from the CN
   by sending all data packets through its HA (i.e., encapsulated).  In
   such mode, the CN uses only the MN's home IPv6 address to communicate
   with the MN.

Haddad, et al.          Expires December 28, 2006              [Page 10]

Internet-Draft         MoMiPriv Problem Statement              June 2006

   But if the CN initiates a session with a MN then it has to use the
   MN's home IPv6 address.  In such scenario, if the MN wants to keep
   its movements hidden from the CN, then it has to switch to the
   bidirectional tunneling mode.

   Consequently, all data packets sent/received by the MN are exchanged
   through the MN's HA and the MN needs to update only its HA with its

   Although, the bi-directional tunneling mode allows hiding the MN's
   care-of address to the CN, it can disclose its real identity, i.e.,
   IPv6 home address, and current location to a malicious node located
   between the HA and the MN (e.g., by looking to the data packets inner
   header), unless the HA-MN tunnel is protected by using the IP
   Encapsulation Security Payload [ESP].

   In addition to mobility, the multi-homing feature allows a mobile
   node to belong to different home networks and to switch between these
   home networks without interrupting ongoing session(s) [MULTI].

   Although multi-homing can be considered as another aspect of
   mobility, switching between different home networks, in addition to
   moving between foreign networks, can disclose to a malicious node
   well located between the multi-homed MN and the CN, part or all of
   the MN's home IPv6 addresses, its device identifiers (e.g., when
   stateless address autoconfiguring is used) and its location(s).  Such
   variety of identifiers can make the malicious eavesdropper's task

   For example, a malicious node located between the MN and the CN can
   start tracing its victim based on prior knowledge of one of its home
   address or MAC address, and by tracking the BU messages (e.g., the MN
   is using the RO mode).
   After that, the malicious eavesdropper can correlate between
   different signaling messages and possibly data packets to expand his
   knowledge to other victim's home/MAC addresses.  Learning new
   identifiers offer the eavesdropper additional tools to detect and
   track future movements.

4.4.  The Security Problem

4.4.1.  The IPsec Problem

   [IPsec] provides a set of security services at the IP layer.  These
   security services are provided through the use of two traffic
   security protocols, i.e., namely the Authentication Header [AH] and
   the ESP protocols, and through the use of cryptographic key

Haddad, et al.          Expires December 28, 2006              [Page 11]

Internet-Draft         MoMiPriv Problem Statement              June 2006

   management procedures and protocols, e.g., Internet Key Exchange
   [IKE] protocol.

   ESP and AH protocols make use of Security Associations (SAs) and a
   major function of IKE protocol is to establish and maintain these
   SAs.  An SA is always identified by a static 32-bit parameter, i.e.,
   Security Paramater Index (SPI), and possibly IP addresses.

   Based on above, an IPsec SPI can be used to trace a particular mobile
   node from one place to another, even if its IP address may change,
   (e.g., if [MobIKE] or [SCTP_IPsec] is used).  Tracing remains
   possible even if care is taken to change the MAC address at the same
   time than the IP address.
   Consequently, the IPsec SPI can be an efficient tool to break the
   unlinkability protection provided by a change(s) of the IP and MAC
   addresses (even if both addresses change at the same time), and also
   to learn and link the MN's new pseudo-IDs.

   This is particularly problematic for the Internet Key Exchange
   protocol (described in [IKE]) SPIs, as there is no possibility for
   efficiently re-negotiating IKE shared secret(s), i.e., SPIs, without
   revealing the previous SPIs in the process.  Note that re-negotiating
   an IPsec SPI may be done within the protection of the IKE SA, hence
   hiding the change from eavesdroppers [EPSPR].

4.4.2.  The Secure Neighbor Discovery (SEND) Problem

   In order to protect against threats related to the IPv6 Neighbor
   Discovery protocol [NDP] and described in [NDPT], the IETF has
   standardized the [SEND] protocol, which specifies security mechanisms
   for IPv6 NDP.

   SEND protocol enables a secure neighbor cache discovery and
   construction by relying on the cryptographically generated addresses
   [CGA] technology to provide a proof of address ownership.

   CGA technology consists on generating an RSA key pair and configuring
   an IPv6 address(es) from hashing the derived public key and other
   parameters.  When using SEND protocol, the MN has to sign NDP
   messages with its CGA private key.

   However, it is important to mention that generating an RSA key pair
   on small devices is a computationally expensive and lenghty
   procedure, i.e., power consumption is relatively high.  Consequently,
   it is likely that such limitation may force the MN to use only one
   RSA key pair for a relatively long period of time, e.g., during an
   ongoing session.  A more optimistic scenario would consist on
   precomputing few key pairs and using them in a random way.

Haddad, et al.          Expires December 28, 2006              [Page 12]

Internet-Draft         MoMiPriv Problem Statement              June 2006

   As a result, hiding both the MN's IP and MAC addresses and
   periodically refreshing the SPI(s) (when they are used) and SQN(s)
   may not be enough to prevent the malicious eavesdropper from tracing
   the MN's movements by detecting ts CGA public key(s) sent during the
   Neighbor Discovery messages exchange, e.g., during a DAD procedure
   following an IP handoff.  Note also that tracing the public key(s)
   can help the malicious node to link between different pseudo-
   identifiers at the MAC and IP levels.

4.5.  The Interdependency Problem

   The MAC and IP layers problems described above highlight another
   concern that needs to be addressed in order to protect the MN's
   identifiers and/or hiding its locations: any change/update of the IP
   address and the MAC pseudo-identifier, as well as all other static
   parameter must be performed in a synchronized way.

   Otherwise, a change/update for example at the IP layer only, may
   allow the eavesdropper to keep tracing the MN via the device
   identifier and/or other static parameters, and consequently to learn
   how/when the MN's identifiers are modified on the MAC layer, thus
   making such change(s) meaningless.

Haddad, et al.          Expires December 28, 2006              [Page 13]

Internet-Draft         MoMiPriv Problem Statement              June 2006

5.  Security Considerations

   This document is a problem statement, which describes privacy issues
   related to a mobile and multi-homed node, and does not introduce
   security considerations by itself.

   However it should be noted that any potential solution for the
   momipriv problem, which allows using temporary device identifiers,
   dynamic pseudo-IP addresses and other parameters during an ongoing
   session should not allow a malicious eavesdropper to learn how nor
   when these identifiers are updated.

   Any potential solution must protect against replaying messages using
   old identifiers and/or hijacking an ongoing session during an update
   of the identifiers.

   Any potential solution should not allow exploiting any aspect of
   privacy, in order to gain access to networks.

Haddad, et al.          Expires December 28, 2006              [Page 14]

Internet-Draft         MoMiPriv Problem Statement              June 2006

6.  Acknowledgements

   Soohong Daniel Park and Hannes Tschofenig have contributed to this
   document.  Many thanks to them.

7.  References

   [AH]       Kent, S., "IP Authentication Header", RFC 4302,
              December 2005.

   [CGA]      Aura, T., "Cryptographically Generated Addresses (CGA)",
              RFC 3792, March 2005.

   [EPSPR]    Arkko, J., Nikander, P., and M. Naslund, "Enhancing
              Privacy with Shared Pseudo Random Sequences", Security
              Proposals, 13rd International Workshop, Cambridge,
              April 2005.

   [ESP]      Kent, S., "IP Encapsulating Security Payload (ESP)",
              RFC 4303, December 2005.

   [IKE]      Kaufman, C., "Internet Key Exchange (IKEv2) Protocol",
              RFC 4306, December 2005.

   [IPsec]    Kent, S. and K. Seo, "Security Architecture for the
              Internet Protocol", RFC 4301, December 2005.

              Beresfold, A. and F. Stajano, "Location Privacy in
              Pervasive Computing", IEEE Pervasive Computing, 2003.

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

   [MULTI]    Montavont, N., Wakikawa, R., Ernst, T., Ng, C., and K.
              Kuladinithi, "Analysis of Multihoming in Mobile IPv6",
              Internet Draft, draft-ietf-monami6-mipv6-analysis-00.txt,
              February 2006.

   [MobIKE]   Eronen, P., "IKEv2 Mobility and Multihoming Protocol
              (MOBIKE)", RFC 4555, June 2006.

   [NDP]      Narten, T., Nordmark, E., Simpson, W., and H. Soliman,
              "Neighbor Discovery for IPv6", Internet
              Draft, draft-ietf-ipv6-2461bis-06.txt, May 2006.

   [NDPT]     Nikander, P., Kempf, J., and E. Nordmark, "IPv6 Neighbor
              Discovery (ND) Trust Models and Threats", RFC 3756,

Haddad, et al.          Expires December 28, 2006              [Page 15]

Internet-Draft         MoMiPriv Problem Statement              June 2006

              May 2004.

   [PRITERM]  Haddad, W. and E. Nordmark, "Privacy Terminology",
              Draft, draft-haddad-alien-privacy-terminology-01.txt,
              June 2006.

   [Priv-NG]  Escudero-Pascual, A., "Privacy in the Next Generation
              Internet: Data Protection in the context of the European
              Union Policy", PhD Dissertation, December 2002.

   [Privacy]  Narten, T., Draves, R., and S. Krishnan, "Privacy
              Extensions for Stateless Address Autoconfiguration in
              Internet-Draft, draft-ietf-ipv6-privacy-address-v2-04.txt,
              May 2005.

              Bellovin, S., Ioannidis, J., and A. Keromytis, "On the Use
              of Stream Control Transmission Protocol (SCTP) with
              IPsec", RFC 3554, July 2003.

   [SEND]     Arkko, J., Kempf, J., Zill, B., and P. Nikander, "Secure
              Neighbor Discovery (SEND)", RFC 3971, March 2005.

   [STAT]     Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless
              Address Autoconfiguration", Internet
              Draft, draft-ietf-ipv6-rfc2462bis-08.txt, May 2005.

   [TERM]     Bradner, S., "Key Words for Use in RFCs to Indicate
              Requirement Levels", RFC 2119, BCP , March 1997.

              Gruteser, M. and D. Grunwald, "Enhancing Location Privacy
              in Wireless LAN Through Disposable Interface Identifiers:
              A Quantitative Analysis", First ACM International
              Workshop Wireless Mobile Applications and Services on WLAN
              Hotspots, September 2003.

Haddad, et al.          Expires December 28, 2006              [Page 16]

Internet-Draft         MoMiPriv Problem Statement              June 2006

Authors' Addresses

   Wassim Haddad
   Ericsson Research
   Torshamnsgatan 23
   SE-164 Stockholm

   Phone: +46 84044079
   Email: Wassim.Haddad@ericsson.com

   Erik Nordmark
   Sun Microsystems
   17 Network Circle
   Menlo Park, CA 94025

   Phone: +1 650 786 2921
   Email: Erik.Nordmark@sun.com

   Francis Dupont

   Email: Francis.Dupont@point6.fr

   Marcelo Bagnulo
   Universidad Carlos III de Madrid
   Av. Universidad 30
   Leganes, Madrid 28911

   Phone: +31 91 6249500
   Email: Marcelo@it.uc3m.es
   URI:   http://www.it.uc3m.es

Haddad, et al.          Expires December 28, 2006              [Page 17]

Internet-Draft         MoMiPriv Problem Statement              June 2006

   Basavaraj Patil
   6000 Connection Drive
   Irving, TX 75039

   Phone: +1 972 8946709
   Email: Basavaraj.Patil@nokia.com

Haddad, et al.          Expires December 28, 2006              [Page 18]

Internet-Draft         MoMiPriv Problem Statement              June 2006

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

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

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.


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

Haddad, et al.          Expires December 28, 2006              [Page 19]