idnits 2.17.1 draft-haddad-alien-problem-statement-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. 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 and authors 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 (November 11, 2010) is 4913 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: 1 error (**), 0 flaws (~~), 3 warnings (==), 5 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 4 Intended status: Informational E. Nordmark 5 Expires: May 15, 2011 Oracle 6 F. Dupont 7 ISC 8 M. Bagnulo 9 UC3M 10 B. Patil 11 Nokia 12 November 11, 2010 14 Anonymous Layers Identifiers for Mobile and Multi-homed Nodes: Problem 15 Statement 16 draft-haddad-alien-problem-statement-04 18 Abstract 20 This memo describes the anonymous layers identifiers in mobility and 21 multi-homing problem statement. 23 Status of this Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at http://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on May 15, 2011. 40 Copyright Notice 42 Copyright (c) 2010 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (http://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 2. Conventions used in this document . . . . . . . . . . . . . . 4 59 3. Glossary . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 60 4. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 7 61 4.1. Location Privacy vs. Privacy . . . . . . . . . . . . . . . 7 62 4.2. The MAC Layer Problem . . . . . . . . . . . . . . . . . . 8 63 4.3. The IP Layer Problem . . . . . . . . . . . . . . . . . . . 9 64 4.4. The Security Problem . . . . . . . . . . . . . . . . . . . 11 65 4.4.1. The IPsec Problem . . . . . . . . . . . . . . . . . . 11 66 4.4.2. The Secure Neighbor Discovery (SeND) Problem . . . . . 12 67 4.5. The Interdependency Problem . . . . . . . . . . . . . . . 13 68 5. Security Considerations . . . . . . . . . . . . . . . . . . . 14 69 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15 70 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16 71 7.1. Normative References . . . . . . . . . . . . . . . . . . . 16 72 7.2. Informative References . . . . . . . . . . . . . . . . . . 16 73 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18 75 1. Introduction 77 In the near future, mobility and multi-homing functionalities will 78 coexist in the majority of end hosts, such as terminals, PDAs, etc. 79 For this purpose, Mobile IPv6 protocol (described in [MIPv6]) has 80 been designed to provide a solution for the mobility at the network 81 layer while Multi-homing is still an ongoing work. 83 MIPv6 does not provide any mechanism to protect the mobile node's 84 privacy when moving across the Internet, while in the multi-homing 85 area, the privacy may well be supported in any potential solution but 86 may probably lack some features. This is mainly due to the fact that 87 the privacy issues are not limited to the IP layer only. 89 This memo describes the anonymous layers identifiers (alien) in 90 mobility and multi-homing problem statement. 92 2. Conventions used in this document 94 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 95 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 96 document are to be interpreted as described in [TERM]. 98 3. Glossary 100 For privacy related terminology, please refer to [PRITERM]. 102 MAC Address 104 A MAC Address is a 48 bits unique value associated with a network 105 adapter. The MAC address uniqueness is by default global. A MAC 106 Address is also known as the device/hardware identifier. 108 Link 110 A communication facility or medium over which nodes can 111 communicate at the link layer, such as an Ethernet (simple or 112 bridged). A link is the layer immediately below IP. 114 IPv6 Address 116 An IP address is a unique 128-bit IP layer identifier for an 117 interface or a set of interfaces attached to an IP network. 118 An IPv6 address can be unicast, i.e., identifier for a single 119 interface, or anycast, i.e., an identifier for a set of 120 interfaces, and a packet sent to an anycast address is delivered 121 to only one interface, or multicast, i.e., an identifier for a set 122 of interfaces and a packet sent to a multicast address is 123 delivered to all these interfaces. 125 Interface Identifier 127 A number used to identify a node's interface on a link. The 128 interface identifier is the remaining low-order bits in the node's 129 IP address after the subnet prefix. 131 Basic Service Set (BSS) 133 A set of stations controlled by a single coordination function. 135 Extended Service Set (ESS) 137 A set of one or more interconnected basic service set (BSSs) and 138 integrated local area networks (LANs) that appears as a single BSS 139 to the logical link control layer at any station associated with 140 one of those BSSs. 142 Distribution System (DS) 144 A system used to interconnect a set of basic service sets (BSSs) 145 and integrated local area networks (LANs) to create an extended 146 service set (ESS). 148 4. Problem Statement 150 The growing ability to trace a mobile node by an untrusted third 151 party, especially in public access networks, is a direct and serious 152 violation of the mobile user's privacy and can cause serious damage 153 to its personal, social and professional life. Privacy becomes a 154 real concern especially when the mobile node (MN) uses permanent 155 device and/or network identifiers. Unfortunately, the privacy 156 problem is not limited to a single layer and should not be solved 157 independantly on one layer. 159 Protecting the user's privacy can be achieved, in many scenarios, by 160 providing one or many of the privacy aspects defined above with 161 regards to the mobile node's requirements and/or location. For this 162 purpose, we try in the rest of this document to use the terms defined 163 above, in order to highlight the issues in a more precise way. 165 It should be noted that this document focuses only on the privacy 166 problem for a mobile and multi-homed node only and does not make any 167 assumption regarding the privacy of a static node, e.g., static 168 correspondent node (CN). In addition, this document assumes that the 169 real IPv6 address is not hidden by default, i.e., any node is always 170 reachable via its real IPv6 address. 172 The alien problem statement is divided into four problems. The first 173 two problems focus on the MAC and IP layers identifiers associated 174 with a mobile device, i.e., MAC and IP addresses, and describe 175 privacy issues resulting from using these identifiers in the context 176 of a mobile and multi-homed environment. The third problem addresses 177 privacy issues resulting from applying security mechanisms, e.g., IP 178 Security (IPsec) and Securing Neighbor Discovery (SeND) while the 179 fourth problem highlights the interdependency between the three 180 problems, as being the main requirement to be considered when 181 designing any potential solution. 183 But before delving into these problems, a quick overview on 184 differences between location privacy and privacy is provided. 186 4.1. Location Privacy vs. Privacy 188 Before describing privacy problems related to the IP and the link 189 layer, it seems useful to highlight the differences between the 190 location privacy and privacy, in order to avoid a possible confusion 191 later. 193 Location privacy is the ability to prevent other parties from 194 learning one's current or past location [LOPRIPEC]. In order to get 195 such ability, the mobile node must conceal any relation between its 196 location and the personal identifiable information. Note that in the 197 alien context, the mobile node location refers normally to the 198 topological location and not the geographic one. The latter is 199 provided by other means (e.g., GPS) than an IPv6 address. But it 200 should be noted that it may possible sometimes to deduce the 201 geographical location from the topological one. 203 However, concealing any relation between the location and the user's 204 identifier(s) does not guarantee that the identifier(s) itself will 205 not be disclosed, since it may be possible to hide the real location 206 alone. But, having at least one user's identifier disclosed may be 207 enough (e.g., if coupled with prior knowledge about few possible 208 whereabouts) for other party to discover the user's current and/or 209 previous location(s). 211 For example, in a context limited to IP and MAC layers, the only 212 available identifiers and/or locators are the IP and MAC addresses, 213 and only the IP address carries information, which can directly 214 disclose the MN's location (note that mobile IPv6 discloses both the 215 mobile node's home and current locations). 217 The MAC address alone does not provide any hint regarding the mobile 218 node current/previous location. But if the other party has already 219 established the link between the target and its MAC address and 220 gained knowledge about some of the user's possible current/future 221 whereabouts, then it will be possible to locate and even track the 222 target. 224 On the other side, it should be noted that the two main privacy 225 aspects, i.e., anonymity and pseudonymity, provide implicitly the 226 location privacy feature by concealing the real user's identifiers 227 regardless of his location(s). 228 Actually, in both privacy aspects, real identifiers are replaced by 229 static or dynamic ones, thus making the other party no more able to 230 identify its target even at the correct location, i.e., any past/ 231 current location information becomes practically useless for locating 232 and tracking purposes. 234 4.2. The MAC Layer Problem 236 The first problem focus on the MAC layer and is raising growing 237 concerns related to the user's privacy, especially with the massive 238 ongoing indoor/outdoor deployment of WLAN technologies. 240 A mobile device attached to a particular link is uniquely identified 241 on that link by its MAC address, i.e., the device identifier. In 242 addition, the device identifier is disclosed in any packet sent by/to 243 the MN when it reaches that particular link, thus making it a very 244 efficient tool to trace a mobile user in a shared wireless medium 245 access. Similar problems have caused bad press for cellular 246 operators. 248 For example, a malicious node located in one distributed system (DS) 249 can trace a mobile node via its device identifier while moving in the 250 entire ESS, and learn enough information about the user's activities 251 and whereabouts. Having these information available in the wrong 252 hands, especially with the exact time when they occur, may have bad 253 consequences on the user. 255 Another concern on the MAC layer, which can also be exploited by an 256 eavesdropper to trace its victim, is the sequence number (SQN) 257 carried by the frame header. The sequence number is incremented by 258 one for each data frame and allows the bad guy to trace its targeted 259 node, in addition to the MAC address. 260 In addition, the sequence number allows also the malicious node to 261 keep tracing the MN, if/when the real MAC address is replaced by one 262 or many pseudo-identifier(s) during an ongoing session [WLAN-IID]. 264 In addition, it should be noted that even if the real MN's device 265 identifier remains undisclosed during all ongoing session(s), it may 266 probably not be enough to provide the unlinkability protection on the 267 MAC layer, between ongoing session(s). 268 Actually, in a scenario, where the malicious node is located on the 269 link or within the distributed system, replacing the real MAC address 270 with a static pseudo-identifier, i.e., to provide pseudonymity, or 271 with temporary ones, i.e., to provide anonymity, it will always be 272 possible to break the unlinkability protection provided by the MAC 273 layer if the MN's IPv6 address remains unchanged. 275 Note that in such scenario, even a periodical change of the sequence 276 number won't prevent the eavesdropper from correlating ongoing 277 session(s), pseudo-identifiers and the mobile node. 279 However, it should be mentioned that replacing the real device 280 identifier with static/dynamic pseudo-identifiers, in order to 281 provide anonymity/pseudonymity, during an ongoing session(s), raises 282 another critical issue on the MAC layer level, which concerns the 283 uniqueness of these new pseudo-identifier(s). 285 In fact, any temporary/static identifiers MUST be unique within the 286 Extended Service Set (ESS) and the distributed system (DS). 288 4.3. The IP Layer Problem 290 The second problem focus on the IP layer and analyzes the privacy 291 problems related to IPv6 only. 293 A MN can configure its IPv6 address either from a DHCP server or by 294 itself. The latter scenario is called the stateless address 295 autoconfiguration (described in [STAT]), and discloses the MN MAC 296 address in the IPv6 address, thus enabling an eavesdropper to easily 297 learn both addresses in this case. 299 In order to mitigate the privacy concerns raised from using the 300 stateless address auto-configuration, [Privacy] introduced a method 301 allowing to periodically change the MN's interface identifier. 302 However, being limited to the interface identifier only, such change 303 discloses the real network identifier, which in turn can reveal 304 enough information about the topological location, the user or can 305 even be the exact piece of information needed by the eavesdropper. 306 Another limitation to its efficiency lays in the fact that such 307 change cannot occur during an ongoing session. 309 While using only a different IPv6 address for each new session may 310 prevent/mitigate the ability to trace a MN on the IP layer level, it 311 remains always possible to trace it through its device identifier(s) 312 on the MAC layer level, i.e., when a malicious node (or another one) 313 is also attached to the same link/DS than its target. 314 Consequently, it will be possible to learn all IPv6 addresses used by 315 the MN by correlating different sessions, thus breaking any 316 unlinkability protection provided at the IP layer. 318 MIPv6 allows an MN to move across the Internet while ensuring optimal 319 routing (i.e., by using route optimization (RO)) mode and keeping 320 ongoing session(s) alive. Although these two features make the RO 321 mode protocol looks efficient, they disclose the MN's home IPv6 322 address and its current location, i.e., care-of address (CoA), in 323 each data packet exchanged between the MN and the correspondent node 324 (CN). 326 Furthermore, each time a MN switches to a new network, it has to send 327 in clear a binding update (BU) message to the CN to notify it about 328 its new location. 330 Consequently, MIPv6 RO mode discloses to a malicious node located 331 between the MN and the CN all parameters required to identify, locate 332 and trace in real time its mobile target, once it moves outside its 333 home network(s) (described first in [Priv-NG]). 335 MIPv6 defines another mode called the bidirectional tunneling (BT), 336 which allows the MN to hide its movements and locations from the CN 337 by sending all data packets through its HA (i.e., encapsulated). In 338 such mode, the CN uses only the MN's home IPv6 address to communicate 339 with the MN. 341 But if the CN initiates a session with a MN then it has to use the 342 MN's home IPv6 address. In such scenario, if the MN wants to keep 343 its movements hidden from the CN, then it has to switch to the 344 bidirectional tunneling mode. 346 Consequently, all data packets sent/received by the MN are exchanged 347 through the MN's HA and the MN needs to update only its HA with its 348 location. 350 Although, the bi-directional tunneling mode allows hiding the MN's 351 care-of address to the CN, it can disclose its real identity, i.e., 352 IPv6 home address, and current location to a malicious node located 353 between the HA and the MN (e.g., by looking to the data packets inner 354 header), unless the HA-MN tunnel is protected by using the IP 355 Encapsulating Security Payload protocol (described in [ESP]). 357 In addition to mobility, the multi-homing feature allows a mobile 358 node to belong to different home networks and to switch between these 359 home networks without interrupting ongoing session(s) (described in 360 [MULTI]). 362 Although multi-homing can be considered as another aspect of 363 mobility, switching between different home networks, in addition to 364 moving between foreign networks, can disclose to a malicious node 365 well located between the multi-homed MN and the CN, part or all of 366 the MN's home IPv6 addresses, its device identifiers (e.g., when 367 stateless address autoconfiguring is used) and its location(s). Such 368 variety of identifiers can make the malicious eavesdropper's task 369 easier. 371 For example, a malicious node located between the MN and the CN can 372 start tracing its victim based on prior knowledge of one of its home 373 address or MAC address, and by tracking the BU messages (e.g., the MN 374 is using the RO mode). 375 After that, the malicious eavesdropper can correlate between 376 different signaling messages and possibly data packets to expand his 377 knowledge to other victim's home/MAC addresses. Learning new 378 identifiers offers the eavesdropper additional tools to detect and 379 track future movements. 381 4.4. The Security Problem 383 4.4.1. The IPsec Problem 385 IP security (IPsec) protocol (described in [IPsec]) provides a set of 386 security services at the IP layer. These security services are 387 provided through the use of two traffic security protocols, i.e., 388 namely the Authentication Header [AH] and ESP, and through the use of 389 cryptographic key management procedures and protocols, e.g., Internet 390 Key Exchange protocol (described in [IKE]). 392 A main function of IKE protocol is to establish and maintain security 393 associations (SAs) used by ESP and AH protocols. An SA is always 394 identified by a static 32-bit parameter, i.e., Security Paramater 395 Index (SPI), and possibly IP addresses. 397 Based on above, an IPsec SPI can be used to trace a particular MN 398 from one place to another, even if its IP address may change (e.g., 399 if [MobIKE] or [SCTP_IPsec] is used). Tracing remains possible even 400 if care is taken to change the MAC address at the same time than the 401 IP address. 402 Consequently, the IPsec SPI can be an efficient tool to break the 403 unlinkability protection provided by a change(s) of the IP and MAC 404 addresses (even if both addresses change at the same time), and also 405 to learn and link the MN's new pseudo-IDs. 407 This is particularly problematic for the IKE SPIs, as there is no 408 possibility for efficiently re-negotiating IKE shared secret(s), 409 without revealing the previous SPIs in the process. Note that re- 410 negotiating an IPsec SPI may be done within the protection of the IKE 411 SA, hence hiding the change from eavesdroppers [EPSPR]. 413 4.4.2. The Secure Neighbor Discovery (SeND) Problem 415 In order to protect against threats related to the IPv6 Neighbor 416 Discovery protocol ([NDP] ) as described in [NDPT], the IETF has 417 standardized [SeND] protocol in order to specify security mechanisms 418 for IPv6 ND protocol. 420 SEND protocol enables a secure neighbor cache discovery and 421 construction by relying on the cryptographically generated addresses 422 technology (described in [CGA]) to provide a proof of address 423 ownership. 425 CGA technology consists on generating an RSA key pair and configuring 426 an IPv6 address(es) from hashing the derived public key and other 427 parameters. When using SEND protocol, the MN has to sign NDP 428 messages with its CGA private key. 430 However, it is important to mention that generating an RSA key pair 431 on small devices is a computationally expensive and lenghty 432 procedure, i.e., power consumption is relatively high. Consequently, 433 it is likely that such limitation may force the MN to use only one 434 RSA key pair for a relatively long period of time, e.g., during an 435 ongoing session. A more optimistic scenario would consist on 436 precomputing few key pairs and using them in a random way. 438 As a result, hiding both the MN's IP and MAC addresses and 439 periodically refreshing the SPI(s) (when they are used) and SQN(s) 440 may not be enough to prevent the malicious eavesdropper from tracing 441 the MN's movements by detecting ts CGA public key(s) sent during the 442 Neighbor Discovery messages exchange, e.g., during a DAD procedure 443 following an IP handoff. Note also that tracing the public key(s) 444 can help the malicious node to link between different pseudo- 445 identifiers at the MAC and IP levels. 447 4.5. The Interdependency Problem 449 The MAC and IP layers problems described above highlight another 450 concern that needs to be addressed in order to protect the MN's 451 identifiers and/or hiding its locations: any change/update of the IP 452 address and the MAC pseudo-identifier, as well as all other static 453 parameter must be performed in a synchronized way. 455 Otherwise, a change/update for example at the IP layer only, may 456 allow the eavesdropper to keep tracing the MN via the device 457 identifier and/or other static parameters, and consequently to learn 458 how/when the MN's identifiers are modified on the MAC layer, thus 459 making such change(s) meaningless. 461 5. Security Considerations 463 This document is a problem statement, which describes privacy issues 464 related to a mobile and multi-homed node, and does not introduce 465 security considerations by itself. 467 However it should be noted that any potential solution for the alien 468 problem, which allows using temporary device identifiers, dynamic 469 pseudo-IP addresses and other parameters during an ongoing session 470 should not allow a malicious eavesdropper to learn how nor when these 471 identifiers are updated. 473 Any potential solution must protect against replaying messages using 474 old identifiers and/or hijacking an ongoing session during an update 475 of the identifiers. 477 Any potential solution should not allow exploiting any privacy aspect 478 in order to gain access to networks. 480 6. Acknowledgements 482 Soohong Daniel Park and Hannes Tschofenig have contributed to this 483 document. Many thanks to them. 485 7. References 487 7.1. Normative References 489 [TERM] Bradner, S., "Key Words for Use in RFCs to Indicate 490 Requirement Levels", RFC 2119, BCP , March 1997. 492 7.2. Informative References 494 [AH] Kent, S., "IP Authentication Header", RFC 4302, 495 December 2005. 497 [CGA] Aura, T., "Cryptographically Generated Addresses (CGA)", 498 RFC 3792, March 2005. 500 [EPSPR] Arkko, J., Nikander, P., and M. Naslund, "Enhancing 501 Privacy with Shared Pseudo Random Sequences", Security 502 Proposals, 13rd International Workshop, Cambridge, 503 April 2005. 505 [ESP] Kent, S., "IP Encapsulating Security Payload (ESP)", 506 RFC 4303, December 2005. 508 [IKE] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", 509 RFC 4306, December 2005. 511 [IPsec] Kent, S. and K. Seo, "Security Architecture for the 512 Internet Protocol", RFC 4301, December 2005. 514 [LOPRIPEC] 515 Beresfold, A. and F. Stajano, "Location Privacy in 516 Pervasive Computing", IEEE Pervasive Computing, 2003. 518 [MIPv6] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support 519 in IPv6", RFC 3775, June 2004. 521 [MULTI] Montavont, N., Wakikawa, R., Ernst, T., Ng, C., and K. 522 Kuladinithi, "Motivations and Scenarios for Using Multiple 523 Interfaces and Global Addresses", Internet Draft, draft- 524 ietf-monami6-multihoming-motivation-scenario-02.txt, 525 July 2007. 527 [MobIKE] Eronen, P., "IKEv2 Mobility and Multihoming Protocol 528 (MOBIKE)", RFC 4555, June 2006. 530 [NDP] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 531 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 532 September 2007. 534 [NDPT] Nikander, P., Kempf, J., and E. Nordmark, "IPv6 Neighbor 535 Discovery (ND) Trust Models and Threats", RFC 3756, 536 May 2004. 538 [PRITERM] Haddad, W. and E. Nordmark, "Privacy Terminology", 539 Internet 540 Draft, draft-haddad-alien-privacy-terminology-04.txt, 541 June 2008. 543 [Priv-NG] Escudero-Pascual, A., "Privacy in the Next Generation 544 Internet: Data Protection in the context of the European 545 Union Policy", PhD Dissertation, December 2002. 547 [Privacy] Narten, T., Draves, R., and S. Krishnan, "Privacy 548 Extensions for Stateless Address Autoconfiguration in 549 IPv6", RFC 4941, September 2007. 551 [SCTP_IPsec] 552 Bellovin, S., Ioannidis, J., and A. Keromytis, "On the Use 553 of Stream Control Transmission Protocol (SCTP) with 554 IPsec", RFC 3554, July 2003. 556 [STAT] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 557 Address Autoconfiguration", RFC 4862, September 2007. 559 [SeND] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "Secure 560 Neighbor Discovery (SeND)", RFC 3971, March 2005. 562 [WLAN-IID] 563 Gruteser, M. and D. Grunwald, "Enhancing Location Privacy 564 in Wireless LAN Through Disposable Interface Identifiers: 565 A Quantitative Analysis", First ACM International 566 Workshop Wireless Mobile Applications and Services on WLAN 567 Hotspots, September 2003. 569 Authors' Addresses 571 Wassim Haddad 572 Ericsson 573 300 Holger Way 574 San Jose, CA 95134 575 USA 577 Phone: +1 646 2562030 578 Email: Wassim.Haddad@ericsson.com 580 Erik Nordmark 581 Oracle 582 17 Network Circle 583 Menlo Park, CA 94025 584 USA 586 Phone: +1 650 786 2921 587 Email: Erik.Nordmark@oracle.com 589 Francis Dupont 590 ISC 591 Rennes 592 Bretagne 593 France 595 Email: Francis.Dupont@fdupont.fr 597 Marcelo Bagnulo 598 UC3M 599 Universidad Carlos III de Madrid 600 Av. Universidad 30 601 Leganes, Madrid 28911 602 Spain 604 Phone: +31 91 6249500 605 Email: Marcelo@it.uc3m.es 606 URI: http://www.it.uc3m.es 607 Basavaraj Patil 608 Nokia 609 6000 Connection Drive 610 Irving, TX 75039 611 USA 613 Phone: +1 972 8946709 614 Email: Basavaraj.Patil@nokia.com