idnits 2.17.1 draft-haddad-momipriv-problem-statement-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 22. -- Found old boilerplate from RFC 3978, Section 5.5 on line 646. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 623. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 630. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 636. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (October 23, 2005) is 6759 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Downref: Normative reference to an Informational RFC: RFC 3792 (ref. 'CGA') -- Possible downref: Non-RFC (?) normative reference: ref. 'EPSPR' -- Possible downref: Non-RFC (?) normative reference: ref. 'LOPRIPEC' ** Obsolete normative reference: RFC 3775 (ref. 'MIPv6') (Obsoleted by RFC 6275) -- No information found for draft-montavont-mobileip-multihoming-problem-statement - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'MULTI' == Outdated reference: A later version (-08) exists of draft-ietf-mobike-protocol-04 == Outdated reference: A later version (-11) exists of draft-ietf-ipv6-2461bis-05 ** Downref: Normative reference to an Informational RFC: RFC 3756 (ref. 'NDPT') == Outdated reference: A later version (-06) exists of draft-haddad-alien-privacy-terminology-00 ** Downref: Normative reference to an Informational draft: draft-haddad-alien-privacy-terminology (ref. 'PRITERM') -- Possible downref: Non-RFC (?) normative reference: ref. 'Priv-NG' -- No information found for draft-ietf-ipv6-privacy-address-v2 - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'Privacy' -- Possible downref: Non-RFC (?) normative reference: ref. 'WLAN-IID' Summary: 9 errors (**), 0 flaws (~~), 5 warnings (==), 15 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group W. Haddad 3 Internet-Draft Ericsson Research 4 Expires: April 26, 2006 E. Nordmark 5 Sun Microsystems 6 F. Dupont 7 Point6 8 M. Bagnulo 9 UC3M 10 B. Patil 11 Nokia 12 October 23, 2005 14 Privacy for Mobile and Multi-homed Nodes: MoMiPriv Problem Statement 15 draft-haddad-momipriv-problem-statement-02 17 Status of this Memo 19 By submitting this Internet-Draft, each author represents that any 20 applicable patent or other IPR claims of which he or she is aware 21 have been or will be disclosed, and any of which he or she becomes 22 aware will be disclosed, in accordance with Section 6 of BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF), its areas, and its working groups. Note that 26 other groups may also distribute working documents as Internet- 27 Drafts. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 The list of current Internet-Drafts can be accessed at 35 http://www.ietf.org/ietf/1id-abstracts.txt. 37 The list of Internet-Draft Shadow Directories can be accessed at 38 http://www.ietf.org/shadow.html. 40 This Internet-Draft will expire on April 26, 2006. 42 Copyright Notice 44 Copyright (C) The Internet Society (2005). 46 Abstract 48 This memo describes the privacy in mobility and multi-homing problem 49 statement. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 54 2. Conventions used in this document . . . . . . . . . . . . . . 4 55 3. Glossary . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 56 4. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 7 57 4.1. Location Privacy vs. Privacy . . . . . . . . . . . . . . . 7 58 4.2. The MAC Layer Problem . . . . . . . . . . . . . . . . . . 8 59 4.3. The IP Layer Problem . . . . . . . . . . . . . . . . . . . 9 60 4.4. The Security Problem . . . . . . . . . . . . . . . . . . . 11 61 4.4.1. The IPsec Problem . . . . . . . . . . . . . . . . . . 11 62 4.4.2. The Secure Neighbor Discovery (SEND) Problem . . . . . 12 63 4.5. The Interdependency Problem . . . . . . . . . . . . . . . 13 64 5. Security Considerations . . . . . . . . . . . . . . . . . . . 14 65 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15 66 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 67 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17 68 Intellectual Property and Copyright Statements . . . . . . . . . . 19 70 1. Introduction 72 In the near future, mobility and multi-homing functionalities will 73 coexist in the majority of end hosts, such as terminals, PDAs, etc. 74 For this purpose, Mobile IPv6 [MIPv6] protocol has been designed to 75 provide a solution for the mobility at the network layer while Multi- 76 homing is still an ongoing work. 78 MIPv6 does not provide any mechanism to protect the mobile node's 79 privacy when moving across the Internet, while in the multi-homing 80 area, the privacy may well be supported in any potential solution but 81 may probably lack some features. This is mainly due to the fact that 82 the privacy issues are not limited to the IP layer only. 84 This memo describes the privacy in mobility and multi-homing 85 (momipriv) problem statement based on IPv6 only. 87 2. Conventions used in this document 89 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 90 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 91 document are to be interpreted as described in [TERM]. 93 3. Glossary 95 For privacy related terminology, please refer to [PRITERM]. 97 MAC Address 99 A MAC Address is a 48 bits unique value associated with a network 100 adapter. The MAC address uniqueness is by default global. A MAC 101 Address is also known as the device/hardware identifier. 103 Link 105 A communication facility or medium over which nodes can communicate 106 at the link layer, such as an Ethernet (simple or bridged). A link 107 is the layer immediately below IP. 109 IPv6 Address 111 An IP address is a unique 128-bit IP layer identifier for an 112 interface or a set of interfaces attached to an IP network. 113 An IPv6 address can be unicast, i.e., identifier for a single 114 interface, or anycast, i.e., an identifier for a set of interfaces, 115 and a packet sent to an anycast address is delivered to only one 116 interface, or multicast, i.e., an identifier for a set of interfaces 117 and a packet sent to a multicast address is delivered to all these 118 interfaces. 120 Interface Identifier 122 A number used to identify a node's interface on a link. The 123 interface identifier is the remaining low-order bits in the node's IP 124 address after the subnet prefix. 126 Basic Service Set (BSS) 128 A set of stations controlled by a single coordination function. 130 Extended Service Set (ESS) 132 A set of one or more interconnected basic service set (BSSs) and 133 integrated local area networks (LANs) that appears as a single BSS to 134 the logical link control layer at any station associated with one of 135 those BSSs. 137 Distribution System (DS) 139 A system used to interconnect a set of basic service sets (BSSs) and 140 integrated local area networks (LANs) to create an extended service 141 set (ESS). 143 4. Problem Statement 145 The growing ability to trace a mobile node by an untrusted third 146 party, especially in public access networks, is a direct and serious 147 violation of the mobile user's privacy and can cause serious damage 148 to its personal, social and professional life. Privacy becomes a 149 real concern especially when the mobile node (MN) uses permanent 150 device and/or network identifiers. Unfortunately, the privacy 151 problem is not limited to a single layer and should not be solved 152 independantly on one layer. 154 Protecting the user's privacy can be achieved, in many scenarios, by 155 providing one or many of the privacy aspects defined above with 156 regards to the mobile node's requirements and/or location. For this 157 purpose, we try in the rest of this document to use the terms defined 158 above, in order to highlight the issues in a more precise way. 160 It should be noted that this document focuses only on the privacy 161 problem for a mobile and multi-homed node only and does not make any 162 assumption regarding the privacy of a static node, e.g., static 163 correspondent node (CN). In addition, this document assumes that the 164 real IPv6 address is not hidden by default, i.e., any node is always 165 reachable via its real IPv6 address. 167 The problem statement is divided into four problems. The first two 168 problems focus on the MAC and IP layers identifiers associated with a 169 mobile device, i.e., MAC and IP addresses, and describe privacy 170 issues resulting from using these identifiers in the context of a 171 mobile and multi-homed environment. The third problem addresses 172 privacy issues resulting from applying security mechanisms, e.g., IP 173 Security (IPsec) and Securing Neighbor Discovery (SEND) while the 174 fourth problem highlights the interdependency between the three 175 problems, as being the main requirement to be considered when 176 designing any potential solution. 178 But before delving into these problems, a quick overview on 179 differences between location privacy and privacy is provided. 181 4.1. Location Privacy vs. Privacy 183 Before describing privacy problems related to the IP and the link 184 layer, it seems useful to highlight the differences between the 185 location privacy and privacy, in order to avoid a possible confusion 186 later. 188 Location privacy is the ability to prevent other parties from 189 learning one's current or past location [LOPRIPEC]. In order to get 190 such ability, the mobile node must conceal any relation between its 191 location and the personal identifiable information. Note that in the 192 momipriv context, the mobile node location refers normally to the 193 topological location and not the geographic one. The latter is 194 provided by other means (e.g., GPS) than an IPv6 address. But it 195 should be noted that it may possible sometimes to deduce the 196 geographical location from the topological one. 198 However, concealing any relation between the location and the user's 199 identifier(s) does not guarantee that the identifier(s) itself will 200 not be disclosed, since it may be possible to hide the real location 201 alone. But, having at least one user's identifier disclosed may be 202 enough (e.g., if coupled with prior knowledge about few possible 203 whereabouts) for other party to discover the user's current and/or 204 previous location(s). 206 For example, in a context limited to IP and MAC layers, the only 207 available identifiers and/or locators are the IP and MAC addresses, 208 and only the IP address carries information, which can directly 209 disclose the MN's location (note that mobile IPv6 discloses both the 210 mobile node's home and current locations). 212 The MAC address alone does not provide any hint regarding the mobile 213 node current/previous location. But if the other party has already 214 established the link between the target and its MAC address and 215 gained knowledge about some of the user's possible current/future 216 whereabouts, then it will be possible to locate and even track the 217 target. 219 On the other side, it should be noted that the two main privacy 220 aspects, i.e., anonymity and pseudonymity, provide implicitly the 221 location privacy feature by concealing the real user's identifiers 222 regardless of his/her location(s). 223 Actually, in both privacy aspects, real identifiers are replaced by 224 static or dynamic ones, thus making the other party no more able to 225 identify its target even at the correct location, i.e., any past/ 226 current location information becomes practically useless for locating 227 and tracking purposes. 229 4.2. The MAC Layer Problem 231 The first problem focus on the MAC layer and is raising growing 232 concerns related to the user's privacy, especially with the massive 233 ongoing indoor/outdoor deployment of WLAN technologies. 235 A mobile device attached to a particular link is uniquely identified 236 on that link by its MAC address, i.e., the device identifier. In 237 addition, the device identifier is disclosed in any packet sent by/to 238 the MN when it reaches that particular link, thus making it a very 239 efficient tool to trace a mobile user in a shared wireless medium 240 access. Similar problems have caused bad press for cellular 241 operators. 243 For example, a malicious node located in one distributed system (DS) 244 can trace a mobile node via its device identifier while moving in the 245 entire ESS, and learn enough information about the user's activities 246 and whereabouts. Having these information available in the wrong 247 hands, especially with the exact time when they occur, may have bad 248 consequences on the user. 250 Another concern on the MAC layer, which can also be exploited by an 251 eavesdropper to trace its victim, is the sequence number (SQN) 252 carried by the frame header. The sequence number is incremented by 1 253 for each data frame and allows the bad guy to trace its targeted 254 node, in addition to the MAC address. 255 In addition, the sequence number allows also the malicious node to 256 keep tracing the MN, if/when the real MAC address is replaced by one 257 or many pseudo-identifier(s) during an ongoing session [WLAN-IID]. 259 In addition, it should be noted that even if the real MN's device 260 identifier remains undisclosed during all ongoing session(s), it may 261 probably not be enough to provide the unlinkability protection on the 262 MAC layer, between ongoing session(s). 263 Actually, in a scenario, where the malicious node is located on the 264 link or within the distributed system, replacing the real MAC address 265 with a static pseudo-identifier, i.e., to provide pseudonymity, or 266 with temporary ones, i.e., to provide anonymity, it will always be 267 possible to break the unlinkability protection provided by the MAC 268 layer if the MN's IPv6 address remains unchanged. 270 Note that in such scenario, even a periodical change of the sequence 271 number won't prevent the eavesdropper from correlating ongoing 272 session(s), pseudo-identifiers and the mobile node. 274 However, it should be mentioned that replacing the real device 275 identifier with static/dynamic pseudo-identifiers, in order to 276 provide anonymity/pseudonymity, during an ongoing session(s), raises 277 another critical issue on the MAC layer level, which concerns the 278 uniqueness of these new pseudo-identifier(s). 280 In fact, any temporary/static identifiers MUST be unique within the 281 Extended Service Set (ESS) and the distributed system (DS). 283 4.3. The IP Layer Problem 285 The second problem focus on the IP layer and analyzes the privacy 286 problems related to IPv6 only. 288 A MN can configure its IPv6 address either from a DHCP server or by 289 itself. The latter scenario is called the stateless address 290 autoconfiguration [STAT], and discloses the MN MAC address in the 291 IPv6 address, thus enabling an eavesdropper to easily learn both 292 addresses in this case. 294 In order to mitigate the privacy concerns raised from using the 295 stateless address auto-configuration, [Privacy] introduced a method 296 allowing to periodically change the MN's interface identifier. 297 However, being limited to the interface identifier only, such change 298 discloses the real network identifier, which in turn can reveal 299 enough information about the topological location, the user or can 300 even be the exact piece of information needed by the eavesdropper. 301 Another limitation to its efficiency lays in the fact that such 302 change cannot occur during an ongoing session. 304 While using only a different IPv6 address for each new session may 305 prevent/mitigate the ability to trace a MN on the IP layer level, it 306 remains always possible to trace it through its device identifier(s) 307 on the MAC layer level, i.e., when a malicious node (or another one) 308 is also attached to the same link/DS than its target. 309 Consequently, it will be possible to learn all IPv6 addresses used by 310 the MN by correlating different sessions, thus breaking any 311 unlinkability protection provided at the IP layer. 313 MIPv6 allows an MN to move across the Internet while ensuring optimal 314 routing (i.e., by using route optimization (RO)) mode and keeping 315 ongoing session(s) alive. Although these two features make the RO 316 mode protocol looks efficient, they disclose the MN's home IPv6 317 address and its current location, i.e., care-of address (CoA), in 318 each data packet exchanged between the MN and the correspondent node 319 (CN). 321 Furthermore, each time a MN switches to a new network, it has to send 322 in clear a binding update (BU) message to the CN to notify it about 323 its new location. 325 Consequently, MIPv6 RO mode discloses to a malicious node located 326 between the MN and the CN, all data required to identify, locate and 327 trace in real time its mobile target, once it moves outside its home 328 network(s) [Priv-NG]. 330 MIPv6 defines another mode called the bidirectional tunneling (BT), 331 which allows the MN to hide its movements and locations from the CN 332 by sending all data packets through its HA (i.e., encapsulated). In 333 such mode, the CN uses only the MN's home IPv6 address to communicate 334 with the MN. 336 But if the CN initiates a session with a MN then it has to use the 337 MN's home IPv6 address. In such scenario, if the MN wants to keep 338 its movements hidden from the CN, then it has to switch to the 339 bidirectional tunneling mode. 341 Consequently, all data packets sent/received by the MN are exchanged 342 through the MN's HA and the MN needs to update only its HA with its 343 location. 345 Although, the bi-directional tunneling mode allows hiding the MN's 346 care-of address to the CN, it can disclose its real identity, i.e., 347 IPv6 home address, and current location to a malicious node located 348 between the HA and the MN (e.g., by looking to the data packets inner 349 header), unless the HA-MN tunnel is protected by using the IP 350 Encapsulation Security Payload [ESP]. 352 In addition to mobility, the multi-homing feature allows a mobile 353 node to belong to different home networks and to switch between these 354 home networks without interrupting ongoing session(s) [MULTI]. 356 Although multi-homing can be considered as another aspect of 357 mobility, switching between different home networks, in addition to 358 moving between foreign networks, can disclose to a malicious node 359 well located between the multi-homed MN and the CN, part or all of 360 the MN's home IPv6 addresses, its device identifiers (e.g., when 361 stateless address autoconfiguring is used) and its location(s). Such 362 variety of identifiers can make the malicious eavesdropper's task 363 easier. 365 For example, a malicious node located between the MN and the CN can 366 start tracing its victim based on prior knowledge of one of its home 367 address or MAC address, and by tracking the BU messages (e.g., the MN 368 is using the RO mode). 369 After that, the malicious eavesdropper can correlate between 370 different signaling messages and possibly data packets to expand his 371 knowledge to other victim's home/MAC addresses. Learning new 372 identifiers offer the eavesdropper additional tools to detect and 373 track future movements. 375 4.4. The Security Problem 377 4.4.1. The IPsec Problem 379 [IPsec] provides a set of security services at the IP layer. These 380 security services are provided through the use of two traffic 381 security protocols, i.e., namely the Authentication Header [AH] and 382 the ESP protocols, and through the use of cryptographic key 383 management procedures and protocols, e.g., Internet Key Exchange 384 [IKE] protocol. 386 ESP and AH protocols make use of Security Associations (SAs) and a 387 major function of IKE protocol is to establish and maintain these 388 SAs. An SA is always identified by a static 32-bit parameter, i.e., 389 Security Paramater Index (SPI), and possibly IP addresses. 391 Based on above, an IPsec SPI can be used to trace a particular mobile 392 node from one place to another, even if its IP address may change, 393 (e.g., if [MobIKE] or [SCTP_IPsec] is used). Tracing remains 394 possible even if care is taken to change the MAC address at the same 395 time than the IP address. 396 Consequently, the IPsec SPI can be an efficient tool to break the 397 unlinkability protection provided by a change(s) of the IP and MAC 398 addresses (even if both addresses change at the same time), and also 399 to learn and link the MN's new pseudo-IDs. 401 This is particularly problematic for the Internet Key Exchange 402 protocol (described in [IKE]) SPIs, as there is no possibility for 403 efficiently re-negotiating IKE shared secret(s), i.e., SPIs, without 404 revealing the previous SPIs in the process. Note that re-negotiating 405 an IPsec SPI may be done within the protection of the IKE SA, hence 406 hiding the change from eavesdroppers [EPSPR]. 408 4.4.2. The Secure Neighbor Discovery (SEND) Problem 410 In order to protect against threats related to the IPv6 Neighbor 411 Discovery protocol [NDP] and described in [NDPT], the IETF has 412 standardized the [SEND] protocol, which specifies security mechanisms 413 for IPv6 NDP. 415 SEND protocol enables a secure neighbor cache discovery and 416 construction by relying on the cryptographically generated addresses 417 [CGA] technology to provide a proof of address ownership. 419 CGA technology consists on generating an RSA key pair and configuring 420 an IPv6 address(es) from hashing the derived public key and other 421 parameters. When using SEND protocol, the MN has to sign NDP 422 messages with its CGA private key. 424 However, it is important to mention that generating an RSA key pair 425 on small devices is a computationally expensive and lenghty 426 procedure, i.e., power consumption is relatively high. Consequently, 427 it is likely that such limitation may force the MN to use only one 428 RSA key pair for a relatively long period of time, e.g., during an 429 ongoing session. A more optimistic scenario would consist on 430 precomputing few key pairs and using them in a random way. 432 As a result, hiding both the MN's IP and MAC addresses and 433 periodically refreshing the SPI(s) (when they are used) and SQN(s) 434 may not be enough to prevent the malicious eavesdropper from tracing 435 the MN's movements by detecting its CGA public key(s) sent during the 436 Neighbor Discovery messages exchange, e.g., during a DAD procedure 437 following an IP handoff. Note also that tracing the public key(s) 438 can help the malicious node to link between different pseudo- 439 identifiers at the MAC and IP levels. 441 4.5. The Interdependency Problem 443 The MAC and IP layers problems described above highlight another 444 concern that needs to be addressed in order to protect the MN's 445 identifiers and/or hiding its locations: any change/update of the IP 446 address and the MAC pseudo-identifier, as well as all other static 447 parameter must be performed in a synchronized way. 449 Otherwise, a change/update for example at the IP layer only, may 450 allow the eavesdropper to keep tracing the MN via the device 451 identifier and/or other static parameters, and consequently to learn 452 how/when the MN's identifiers are modified on the MAC layer, thus 453 making such change(s) meaningless. 455 5. Security Considerations 457 This document is a problem statement, which describes privacy issues 458 related to a mobile and multi-homed node, and does not introduce 459 security considerations by itself. 461 However it should be noted that any potential solution for the 462 momipriv problem, which allows using temporary device identifiers, 463 dynamic pseudo-IP addresses and other parameters during an ongoing 464 session should not allow a malicious eavesdropper to learn how nor 465 when these identifiers are updated. 467 Any potential solution must protect against replaying messages using 468 old identifiers and/or hijacking an ongoing session during an update 469 of the identifiers. 471 Any potential solution should not allow exploiting any aspect of 472 privacy, in order to gain access to networks. 474 6. Acknowledgements 476 Soohong Daniel Park and Hannes Tschofenig have also contributed to 477 this document. Many thanks to them. 479 7. References 481 [AH] Kent, S., "IP Authentication Header", Internet 482 Draft, draft-ietf-ipsec-rfc2402bis-11.txt, March 2005. 484 [CGA] Aura, T., "Cryptographically Generated Addresses (CGA)", 485 RFC 3792, March 2005. 487 [EPSPR] Arkko, J., Nikander, P., and M. Naslund, "Enhancing 488 Privacy with Shared Pseudo Random Sequences", Security 489 Proposals, 13rd International Workshop, Cambridge, 490 April 2005. 492 [ESP] Kent, S., "IP Encapsulating Security Payload (ESP)", 493 Internet Draft, draft-ietf-ipsec-esp-v3-10.txt, 494 March 2005. 496 [IKE] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", 497 Internet Draft, draft-ietf-ipsec-ikev2-17.txt, 498 September 2004. 500 [IPsec] Kent, S. and K. Seo, "Security Architecture for the 501 Internet Protocol", Internet 502 Draft, draft-ietf-ipsec-rfc2401bis-06.txt, March 2005. 504 [LOPRIPEC] 505 Beresfold, A. and F. Stajano, "Location Privacy in 506 Pervasive Computing", IEEE Pervasive Computing, 2003. 508 [MIPv6] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support 509 in IPv6", RFC 3775, June 2004. 511 [MULTI] Montavont, N., Wakikawa, R., Ernst, T., Noel, T., Ng, C., 512 and K. Kuladinithi, "Analysis of Multihoming in Mobile 513 IPv6", Internet Draft, draft-montavont-mobileip- 514 multihoming-problem-statement-04.txt, June 2005. 516 [MobIKE] Eronen, P., "IKEv2 Mobility and Multihoming Protocol 517 (MOBIKE)", Internet 518 Draft, draft-ietf-mobike-protocol-04.txt, October 2005. 520 [NDP] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 521 "Neighbor Discovery for IPv6", Internet 522 Draft, draft-ietf-ipv6-2461bis-05.txt, October 2005. 524 [NDPT] Nikander, P., Kempf, J., and E. Nordmark, "IPv6 Neighbor 525 Discovery (ND) Trust Models and Threats", RFC 3756, 526 May 2004. 528 [PRITERM] Haddad, W. and E. Nordmark, "Privacy Terminology", 529 Internet 530 Draft, draft-haddad-alien-privacy-terminology-00.txt, 531 October 2005. 533 [Priv-NG] Escudero-Pascual, A., "Privacy in the Next Generation 534 Internet: Data Protection in the context of the European 535 Union Policy", PhD Dissertation, December 2002. 537 [Privacy] Narten, T., Draves, R., and S. Krishnan, "Privacy 538 Extensions for Stateless Address Autoconfiguration in 539 IPv6", 540 Internet-Draft, draft-ietf-ipv6-privacy-address-v2-04.txt, 541 May 2005. 543 [SCTP_IPsec] 544 Bellovin, S., Ioannidis, J., and A. Keromytis, "On the Use 545 of Stream Control Transmission Protocol (SCTP) with 546 IPsec", RFC 3554, July 2003. 548 [SEND] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "Secure 549 Neighbor Discovery (SEND)", RFC 3971, March 2005. 551 [STAT] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 552 Address Autoconfiguration", Internet 553 Draft, draft-ietf-ipv6-rfc2462bis-08.txt, May 2005. 555 [TERM] Bradner, S., "Key Words for Use in RFCs to Indicate 556 Requirement Levels", RFC 2119, BCP , March 1997. 558 [WLAN-IID] 559 Gruteser, M. and D. Grunwald, "Enhancing Location Privacy 560 in Wireless LAN Through Disposable Interface Identifiers: 561 A Quantitative Analysis", First ACM International 562 Workshop Wireless Mobile Applications and Services on WLAN 563 Hotspots, September 2003. 565 Authors' Addresses 567 Wassim Haddad 568 Ericsson Research 569 8400 Decarie Blvd. 570 Town of Mount Royal, QC 571 Canada 573 Phone: +1 514 345 7900 #2334 574 Email: Wassim.Haddad@ericsson.com 576 Erik Nordmark 577 Sun Microsystems 578 17 Network Circle 579 Menlo Park, CA 94025 580 USA 582 Phone: +1 650 786 2921 583 Email: Erik.Nordmark@sun.com 585 Francis Dupont 586 Point6 587 c/o GET/ENST Bretagne 588 2 rue de la Chataigneraie 589 CS 17607, 35576 Cesson-Sevigne Cedex 590 France 592 Fax: +33 2 99 12 70 30 593 Email: Francis.Dupont@enst-bretagne.fr 595 Marcelo Bagnulo 596 UC3M 597 Universidad Carlos III de Madrid 598 Av. Universidad 30 599 Leganes, Madrid 28911 600 Spain 602 Phone: +31 91 6249500 603 Email: Marcelo@it.uc3m.es 604 URI: http://www.it.uc3m.es 605 Basavaraj Patil 606 Nokia 607 6000 Connection Drive 608 Irving, TX 75039 609 USA 611 Phone: +1 972 8946709 612 Email: Basavaraj.Patil@nokia.com 614 Intellectual Property Statement 616 The IETF takes no position regarding the validity or scope of any 617 Intellectual Property Rights or other rights that might be claimed to 618 pertain to the implementation or use of the technology described in 619 this document or the extent to which any license under such rights 620 might or might not be available; nor does it represent that it has 621 made any independent effort to identify any such rights. Information 622 on the procedures with respect to rights in RFC documents can be 623 found in BCP 78 and BCP 79. 625 Copies of IPR disclosures made to the IETF Secretariat and any 626 assurances of licenses to be made available, or the result of an 627 attempt made to obtain a general license or permission for the use of 628 such proprietary rights by implementers or users of this 629 specification can be obtained from the IETF on-line IPR repository at 630 http://www.ietf.org/ipr. 632 The IETF invites any interested party to bring to its attention any 633 copyrights, patents or patent applications, or other proprietary 634 rights that may cover technology that may be required to implement 635 this standard. Please address the information to the IETF at 636 ietf-ipr@ietf.org. 638 Disclaimer of Validity 640 This document and the information contained herein are provided on an 641 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 642 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 643 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 644 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 645 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 646 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 648 Copyright Statement 650 Copyright (C) The Internet Society (2005). This document is subject 651 to the rights, licenses and restrictions contained in BCP 78, and 652 except as set forth therein, the authors retain all their rights. 654 Acknowledgment 656 Funding for the RFC Editor function is currently provided by the 657 Internet Society.