idnits 2.17.00 (12 Aug 2021) /tmp/idnits8586/draft-haddad-alien-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 23. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 624. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 635. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 642. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 648. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. 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.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust 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 (June 25, 2008) is 5078 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Obsolete informational reference (is this intentional?): RFC 4306 (ref. 'IKE') (Obsoleted by RFC 5996) -- Obsolete informational reference (is this intentional?): RFC 3775 (ref. 'MIPv6') (Obsoleted by RFC 6275) == Outdated reference: A later version (-03) exists of draft-ietf-monami6-multihoming-motivation-scenario-02 == Outdated reference: A later version (-06) exists of draft-haddad-alien-privacy-terminology-04 -- Obsolete informational reference (is this intentional?): RFC 4941 (ref. 'Privacy') (Obsoleted by RFC 8981) Summary: 2 errors (**), 0 flaws (~~), 3 warnings (==), 10 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group W. Haddad 3 Internet-Draft Qualcomm 4 Intended status: Informational E. Nordmark 5 Expires: December 27, 2008 Sun Microsystems 6 F. Dupont 7 ISC 8 M. Bagnulo 9 UC3M 10 B. Patil 11 Nokia Siemens Networks 12 June 25, 2008 14 Anonymous Layers Identifiers for Mobile and Multi-homed Nodes: Problem 15 Statement 16 draft-haddad-alien-problem-statement-02 18 Status of this Memo 20 By submitting this Internet-Draft, each author represents that any 21 applicable patent or other IPR claims of which he or she is aware 22 have been or will be disclosed, and any of which he or she becomes 23 aware will be disclosed, in accordance with Section 6 of BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF), its areas, and its working groups. Note that 27 other groups may also distribute working documents as Internet- 28 Drafts. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 The list of current Internet-Drafts can be accessed at 36 http://www.ietf.org/ietf/1id-abstracts.txt. 38 The list of Internet-Draft Shadow Directories can be accessed at 39 http://www.ietf.org/shadow.html. 41 This Internet-Draft will expire on December 27, 2008. 43 Abstract 45 This memo describes the anonymous layers identifiers in mobility and 46 multi-homing problem statement. 48 Table of Contents 50 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 51 2. Conventions used in this document . . . . . . . . . . . . . . 4 52 3. Glossary . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 53 4. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 7 54 4.1. Location Privacy vs. Privacy . . . . . . . . . . . . . . . 7 55 4.2. The MAC Layer Problem . . . . . . . . . . . . . . . . . . 8 56 4.3. The IP Layer Problem . . . . . . . . . . . . . . . . . . . 9 57 4.4. The Security Problem . . . . . . . . . . . . . . . . . . . 11 58 4.4.1. The IPsec Problem . . . . . . . . . . . . . . . . . . 11 59 4.4.2. The Secure Neighbor Discovery (SeND) Problem . . . . . 12 60 4.5. The Interdependency Problem . . . . . . . . . . . . . . . 13 61 5. Security Considerations . . . . . . . . . . . . . . . . . . . 14 62 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15 63 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16 64 7.1. Normative References . . . . . . . . . . . . . . . . . . . 16 65 7.2. Informative References . . . . . . . . . . . . . . . . . . 16 66 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18 67 Intellectual Property and Copyright Statements . . . . . . . . . . 20 69 1. Introduction 71 In the near future, mobility and multi-homing functionalities will 72 coexist in the majority of end hosts, such as terminals, PDAs, etc. 73 For this purpose, Mobile IPv6 protocol (described in [MIPv6]) has 74 been designed to provide a solution for the mobility at the network 75 layer while Multi-homing is still an ongoing work. 77 MIPv6 does not provide any mechanism to protect the mobile node's 78 privacy when moving across the Internet, while in the multi-homing 79 area, the privacy may well be supported in any potential solution but 80 may probably lack some features. This is mainly due to the fact that 81 the privacy issues are not limited to the IP layer only. 83 This memo describes the anonymous layers identifiers (alien) in 84 mobility and multi-homing problem statement. 86 2. Conventions used in this document 88 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 89 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 90 document are to be interpreted as described in [TERM]. 92 3. Glossary 94 For privacy related terminology, please refer to [PRITERM]. 96 MAC Address 98 A MAC Address is a 48 bits unique value associated with a network 99 adapter. The MAC address uniqueness is by default global. A MAC 100 Address is also known as the device/hardware identifier. 102 Link 104 A communication facility or medium over which nodes can 105 communicate at the link layer, such as an Ethernet (simple or 106 bridged). A link is the layer immediately below IP. 108 IPv6 Address 110 An IP address is a unique 128-bit IP layer identifier for an 111 interface or a set of interfaces attached to an IP network. 112 An IPv6 address can be unicast, i.e., identifier for a single 113 interface, or anycast, i.e., an identifier for a set of 114 interfaces, and a packet sent to an anycast address is delivered 115 to only one interface, or multicast, i.e., an identifier for a set 116 of interfaces and a packet sent to a multicast address is 117 delivered to all these interfaces. 119 Interface Identifier 121 A number used to identify a node's interface on a link. The 122 interface identifier is the remaining low-order bits in the node's 123 IP address after the subnet prefix. 125 Basic Service Set (BSS) 127 A set of stations controlled by a single coordination function. 129 Extended Service Set (ESS) 131 A set of one or more interconnected basic service set (BSSs) and 132 integrated local area networks (LANs) that appears as a single BSS 133 to the logical link control layer at any station associated with 134 one of those BSSs. 136 Distribution System (DS) 138 A system used to interconnect a set of basic service sets (BSSs) 139 and integrated local area networks (LANs) to create an extended 140 service set (ESS). 142 4. Problem Statement 144 The growing ability to trace a mobile node by an untrusted third 145 party, especially in public access networks, is a direct and serious 146 violation of the mobile user's privacy and can cause serious damage 147 to its personal, social and professional life. Privacy becomes a 148 real concern especially when the mobile node (MN) uses permanent 149 device and/or network identifiers. Unfortunately, the privacy 150 problem is not limited to a single layer and should not be solved 151 independantly on one layer. 153 Protecting the user's privacy can be achieved, in many scenarios, by 154 providing one or many of the privacy aspects defined above with 155 regards to the mobile node's requirements and/or location. For this 156 purpose, we try in the rest of this document to use the terms defined 157 above, in order to highlight the issues in a more precise way. 159 It should be noted that this document focuses only on the privacy 160 problem for a mobile and multi-homed node only and does not make any 161 assumption regarding the privacy of a static node, e.g., static 162 correspondent node (CN). In addition, this document assumes that the 163 real IPv6 address is not hidden by default, i.e., any node is always 164 reachable via its real IPv6 address. 166 The alien problem statement is divided into four problems. The first 167 two problems focus on the MAC and IP layers identifiers associated 168 with a mobile device, i.e., MAC and IP addresses, and describe 169 privacy issues resulting from using these identifiers in the context 170 of a mobile and multi-homed environment. The third problem addresses 171 privacy issues resulting from applying security mechanisms, e.g., IP 172 Security (IPsec) and Securing Neighbor Discovery (SeND) while the 173 fourth problem highlights the interdependency between the three 174 problems, as being the main requirement to be considered when 175 designing any potential solution. 177 But before delving into these problems, a quick overview on 178 differences between location privacy and privacy is provided. 180 4.1. Location Privacy vs. Privacy 182 Before describing privacy problems related to the IP and the link 183 layer, it seems useful to highlight the differences between the 184 location privacy and privacy, in order to avoid a possible confusion 185 later. 187 Location privacy is the ability to prevent other parties from 188 learning one's current or past location [LOPRIPEC]. In order to get 189 such ability, the mobile node must conceal any relation between its 190 location and the personal identifiable information. Note that in the 191 alien context, the mobile node location refers normally to the 192 topological location and not the geographic one. The latter is 193 provided by other means (e.g., GPS) than an IPv6 address. But it 194 should be noted that it may possible sometimes to deduce the 195 geographical location from the topological one. 197 However, concealing any relation between the location and the user's 198 identifier(s) does not guarantee that the identifier(s) itself will 199 not be disclosed, since it may be possible to hide the real location 200 alone. But, having at least one user's identifier disclosed may be 201 enough (e.g., if coupled with prior knowledge about few possible 202 whereabouts) for other party to discover the user's current and/or 203 previous location(s). 205 For example, in a context limited to IP and MAC layers, the only 206 available identifiers and/or locators are the IP and MAC addresses, 207 and only the IP address carries information, which can directly 208 disclose the MN's location (note that mobile IPv6 discloses both the 209 mobile node's home and current locations). 211 The MAC address alone does not provide any hint regarding the mobile 212 node current/previous location. But if the other party has already 213 established the link between the target and its MAC address and 214 gained knowledge about some of the user's possible current/future 215 whereabouts, then it will be possible to locate and even track the 216 target. 218 On the other side, it should be noted that the two main privacy 219 aspects, i.e., anonymity and pseudonymity, provide implicitly the 220 location privacy feature by concealing the real user's identifiers 221 regardless of his location(s). 222 Actually, in both privacy aspects, real identifiers are replaced by 223 static or dynamic ones, thus making the other party no more able to 224 identify its target even at the correct location, i.e., any past/ 225 current location information becomes practically useless for locating 226 and tracking purposes. 228 4.2. The MAC Layer Problem 230 The first problem focus on the MAC layer and is raising growing 231 concerns related to the user's privacy, especially with the massive 232 ongoing indoor/outdoor deployment of WLAN technologies. 234 A mobile device attached to a particular link is uniquely identified 235 on that link by its MAC address, i.e., the device identifier. In 236 addition, the device identifier is disclosed in any packet sent by/to 237 the MN when it reaches that particular link, thus making it a very 238 efficient tool to trace a mobile user in a shared wireless medium 239 access. Similar problems have caused bad press for cellular 240 operators. 242 For example, a malicious node located in one distributed system (DS) 243 can trace a mobile node via its device identifier while moving in the 244 entire ESS, and learn enough information about the user's activities 245 and whereabouts. Having these information available in the wrong 246 hands, especially with the exact time when they occur, may have bad 247 consequences on the user. 249 Another concern on the MAC layer, which can also be exploited by an 250 eavesdropper to trace its victim, is the sequence number (SQN) 251 carried by the frame header. The sequence number is incremented by 252 one for each data frame and allows the bad guy to trace its targeted 253 node, in addition to the MAC address. 254 In addition, the sequence number allows also the malicious node to 255 keep tracing the MN, if/when the real MAC address is replaced by one 256 or many pseudo-identifier(s) during an ongoing session [WLAN-IID]. 258 In addition, it should be noted that even if the real MN's device 259 identifier remains undisclosed during all ongoing session(s), it may 260 probably not be enough to provide the unlinkability protection on the 261 MAC layer, between ongoing session(s). 262 Actually, in a scenario, where the malicious node is located on the 263 link or within the distributed system, replacing the real MAC address 264 with a static pseudo-identifier, i.e., to provide pseudonymity, or 265 with temporary ones, i.e., to provide anonymity, it will always be 266 possible to break the unlinkability protection provided by the MAC 267 layer if the MN's IPv6 address remains unchanged. 269 Note that in such scenario, even a periodical change of the sequence 270 number won't prevent the eavesdropper from correlating ongoing 271 session(s), pseudo-identifiers and the mobile node. 273 However, it should be mentioned that replacing the real device 274 identifier with static/dynamic pseudo-identifiers, in order to 275 provide anonymity/pseudonymity, during an ongoing session(s), raises 276 another critical issue on the MAC layer level, which concerns the 277 uniqueness of these new pseudo-identifier(s). 279 In fact, any temporary/static identifiers MUST be unique within the 280 Extended Service Set (ESS) and the distributed system (DS). 282 4.3. The IP Layer Problem 284 The second problem focus on the IP layer and analyzes the privacy 285 problems related to IPv6 only. 287 A MN can configure its IPv6 address either from a DHCP server or by 288 itself. The latter scenario is called the stateless address 289 autoconfiguration (described in [STAT]), and discloses the MN MAC 290 address in the IPv6 address, thus enabling an eavesdropper to easily 291 learn both addresses in this case. 293 In order to mitigate the privacy concerns raised from using the 294 stateless address auto-configuration, [Privacy] introduced a method 295 allowing to periodically change the MN's interface identifier. 296 However, being limited to the interface identifier only, such change 297 discloses the real network identifier, which in turn can reveal 298 enough information about the topological location, the user or can 299 even be the exact piece of information needed by the eavesdropper. 300 Another limitation to its efficiency lays in the fact that such 301 change cannot occur during an ongoing session. 303 While using only a different IPv6 address for each new session may 304 prevent/mitigate the ability to trace a MN on the IP layer level, it 305 remains always possible to trace it through its device identifier(s) 306 on the MAC layer level, i.e., when a malicious node (or another one) 307 is also attached to the same link/DS than its target. 308 Consequently, it will be possible to learn all IPv6 addresses used by 309 the MN by correlating different sessions, thus breaking any 310 unlinkability protection provided at the IP layer. 312 MIPv6 allows an MN to move across the Internet while ensuring optimal 313 routing (i.e., by using route optimization (RO)) mode and keeping 314 ongoing session(s) alive. Although these two features make the RO 315 mode protocol looks efficient, they disclose the MN's home IPv6 316 address and its current location, i.e., care-of address (CoA), in 317 each data packet exchanged between the MN and the correspondent node 318 (CN). 320 Furthermore, each time a MN switches to a new network, it has to send 321 in clear a binding update (BU) message to the CN to notify it about 322 its new location. 324 Consequently, MIPv6 RO mode discloses to a malicious node located 325 between the MN and the CN all parameters required to identify, locate 326 and trace in real time its mobile target, once it moves outside its 327 home network(s) (described first in [Priv-NG]). 329 MIPv6 defines another mode called the bidirectional tunneling (BT), 330 which allows the MN to hide its movements and locations from the CN 331 by sending all data packets through its HA (i.e., encapsulated). In 332 such mode, the CN uses only the MN's home IPv6 address to communicate 333 with the MN. 335 But if the CN initiates a session with a MN then it has to use the 336 MN's home IPv6 address. In such scenario, if the MN wants to keep 337 its movements hidden from the CN, then it has to switch to the 338 bidirectional tunneling mode. 340 Consequently, all data packets sent/received by the MN are exchanged 341 through the MN's HA and the MN needs to update only its HA with its 342 location. 344 Although, the bi-directional tunneling mode allows hiding the MN's 345 care-of address to the CN, it can disclose its real identity, i.e., 346 IPv6 home address, and current location to a malicious node located 347 between the HA and the MN (e.g., by looking to the data packets inner 348 header), unless the HA-MN tunnel is protected by using the IP 349 Encapsulating Security Payload protocol (described in [ESP]). 351 In addition to mobility, the multi-homing feature allows a mobile 352 node to belong to different home networks and to switch between these 353 home networks without interrupting ongoing session(s) (described in 354 [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 offers 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 IP security (IPsec) protocol (described in [IPsec]) provides a set of 380 security services at the IP layer. These security services are 381 provided through the use of two traffic security protocols, i.e., 382 namely the Authentication Header [AH] and ESP, and through the use of 383 cryptographic key management procedures and protocols, e.g., Internet 384 Key Exchange protocol (described in [IKE]). 386 A main function of IKE protocol is to establish and maintain security 387 associations (SAs) used by ESP and AH protocols. An SA is always 388 identified by a static 32-bit parameter, i.e., Security Paramater 389 Index (SPI), and possibly IP addresses. 391 Based on above, an IPsec SPI can be used to trace a particular MN 392 from one place to another, even if its IP address may change (e.g., 393 if [MobIKE] or [SCTP_IPsec] is used). Tracing remains possible even 394 if care is taken to change the MAC address at the same time than the 395 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 IKE SPIs, as there is no 402 possibility for efficiently re-negotiating IKE shared secret(s), 403 without revealing the previous SPIs in the process. Note that re- 404 negotiating an IPsec SPI may be done within the protection of the IKE 405 SA, hence hiding the change from eavesdroppers [EPSPR]. 407 4.4.2. The Secure Neighbor Discovery (SeND) Problem 409 In order to protect against threats related to the IPv6 Neighbor 410 Discovery protocol ([NDP] ) as described in [NDPT], the IETF has 411 standardized [SeND] protocol in order to specify security mechanisms 412 for IPv6 ND protocol. 414 SEND protocol enables a secure neighbor cache discovery and 415 construction by relying on the cryptographically generated addresses 416 technology (described in [CGA]) to provide a proof of address 417 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 ts 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 alien 462 problem, which allows using temporary device identifiers, dynamic 463 pseudo-IP addresses and other parameters during an ongoing session 464 should not allow a malicious eavesdropper to learn how nor when these 465 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 privacy aspect 472 in order to gain access to networks. 474 6. Acknowledgements 476 Soohong Daniel Park and Hannes Tschofenig have contributed to this 477 document. Many thanks to them. 479 7. References 481 7.1. Normative References 483 [TERM] Bradner, S., "Key Words for Use in RFCs to Indicate 484 Requirement Levels", RFC 2119, BCP , March 1997. 486 7.2. Informative References 488 [AH] Kent, S., "IP Authentication Header", RFC 4302, 489 December 2005. 491 [CGA] Aura, T., "Cryptographically Generated Addresses (CGA)", 492 RFC 3792, March 2005. 494 [EPSPR] Arkko, J., Nikander, P., and M. Naslund, "Enhancing 495 Privacy with Shared Pseudo Random Sequences", Security 496 Proposals, 13rd International Workshop, Cambridge, 497 April 2005. 499 [ESP] Kent, S., "IP Encapsulating Security Payload (ESP)", 500 RFC 4303, December 2005. 502 [IKE] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", 503 RFC 4306, December 2005. 505 [IPsec] Kent, S. and K. Seo, "Security Architecture for the 506 Internet Protocol", RFC 4301, December 2005. 508 [LOPRIPEC] 509 Beresfold, A. and F. Stajano, "Location Privacy in 510 Pervasive Computing", IEEE Pervasive Computing, 2003. 512 [MIPv6] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support 513 in IPv6", RFC 3775, June 2004. 515 [MULTI] Montavont, N., Wakikawa, R., Ernst, T., Ng, C., and K. 516 Kuladinithi, "Motivations and Scenarios for Using Multiple 517 Interfaces and Global Addresses", Internet Draft, draft- 518 ietf-monami6-multihoming-motivation-scenario-02.txt, 519 July 2007. 521 [MobIKE] Eronen, P., "IKEv2 Mobility and Multihoming Protocol 522 (MOBIKE)", RFC 4555, June 2006. 524 [NDP] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 525 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 526 September 2007. 528 [NDPT] Nikander, P., Kempf, J., and E. Nordmark, "IPv6 Neighbor 529 Discovery (ND) Trust Models and Threats", RFC 3756, 530 May 2004. 532 [PRITERM] Haddad, W. and E. Nordmark, "Privacy Terminology", 533 Internet 534 Draft, draft-haddad-alien-privacy-terminology-04.txt, 535 June 2008. 537 [Priv-NG] Escudero-Pascual, A., "Privacy in the Next Generation 538 Internet: Data Protection in the context of the European 539 Union Policy", PhD Dissertation, December 2002. 541 [Privacy] Narten, T., Draves, R., and S. Krishnan, "Privacy 542 Extensions for Stateless Address Autoconfiguration in 543 IPv6", RFC 4941, September 2007. 545 [SCTP_IPsec] 546 Bellovin, S., Ioannidis, J., and A. Keromytis, "On the Use 547 of Stream Control Transmission Protocol (SCTP) with 548 IPsec", RFC 3554, July 2003. 550 [STAT] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 551 Address Autoconfiguration", RFC 4862, September 2007. 553 [SeND] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "Secure 554 Neighbor Discovery (SeND)", RFC 3971, March 2005. 556 [WLAN-IID] 557 Gruteser, M. and D. Grunwald, "Enhancing Location Privacy 558 in Wireless LAN Through Disposable Interface Identifiers: 559 A Quantitative Analysis", First ACM International 560 Workshop Wireless Mobile Applications and Services on WLAN 561 Hotspots, September 2003. 563 Authors' Addresses 565 Wassim Haddad 566 Qualcomm 567 500 Somerset Corporate Blvd 568 Bridgewater, NJ 08807 569 USA 571 Phone: +1 908 9385027 572 Email: whaddad@qualcomm.com 574 Erik Nordmark 575 Sun Microsystems 576 17 Network Circle 577 Menlo Park, CA 94025 578 USA 580 Phone: +1 650 786 2921 581 Email: Erik.Nordmark@sun.com 583 Francis Dupont 584 ISC 585 Rennes 586 Bretagne 587 France 589 Email: Francis.Dupont@fdupont.fr 591 Marcelo Bagnulo 592 UC3M 593 Universidad Carlos III de Madrid 594 Av. Universidad 30 595 Leganes, Madrid 28911 596 Spain 598 Phone: +31 91 6249500 599 Email: Marcelo@it.uc3m.es 600 URI: http://www.it.uc3m.es 601 Basavaraj Patil 602 Nokia Siemens Networks 603 6000 Connection Drive 604 Irving, TX 75039 605 USA 607 Phone: +1 972 8946709 608 Email: Basavaraj.Patil@nokia.com 610 Full Copyright Statement 612 Copyright (C) The IETF Trust (2008). 614 This document is subject to the rights, licenses and restrictions 615 contained in BCP 78, and except as set forth therein, the authors 616 retain all their rights. 618 This document and the information contained herein are provided on an 619 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 620 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 621 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 622 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 623 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 624 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 626 Intellectual Property 628 The IETF takes no position regarding the validity or scope of any 629 Intellectual Property Rights or other rights that might be claimed to 630 pertain to the implementation or use of the technology described in 631 this document or the extent to which any license under such rights 632 might or might not be available; nor does it represent that it has 633 made any independent effort to identify any such rights. Information 634 on the procedures with respect to rights in RFC documents can be 635 found in BCP 78 and BCP 79. 637 Copies of IPR disclosures made to the IETF Secretariat and any 638 assurances of licenses to be made available, or the result of an 639 attempt made to obtain a general license or permission for the use of 640 such proprietary rights by implementers or users of this 641 specification can be obtained from the IETF on-line IPR repository at 642 http://www.ietf.org/ipr. 644 The IETF invites any interested party to bring to its attention any 645 copyrights, patents or patent applications, or other proprietary 646 rights that may cover technology that may be required to implement 647 this standard. Please address the information to the IETF at 648 ietf-ipr@ietf.org.