idnits 2.17.00 (12 Aug 2021) /tmp/idnits8651/draft-haddad-alien-threat-model-00.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 25. -- Found old boilerplate from RFC 3978, Section 5.5 on line 624. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 601. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 608. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 614. ** 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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- 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 (January 23, 2007) is 5597 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 4285 (ref. 'MIPAuth') ** Obsolete normative reference: RFC 3775 (ref. 'MIPv6') (Obsoleted by RFC 6275) == Outdated reference: draft-ietf-ipv6-rfc2462bis has been published as RFC 4862 == Outdated reference: A later version (-04) exists of draft-haddad-alien-problem-statement-00 == Outdated reference: draft-ietf-shim6-hba has been published as RFC 5535 == Outdated reference: A later version (-08) exists of draft-ietf-mip6-cn-ipsec-03 == Outdated reference: draft-ietf-mipshop-cga-cba has been published as RFC 4866 == Outdated reference: draft-ietf-shim6-proto has been published as RFC 5533 Summary: 5 errors (**), 0 flaws (~~), 9 warnings (==), 7 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: July 27, 2007 E. Nordmark 5 Sun Microsystems, Inc. 6 F. Dupont 7 CELAR 8 M. Bagnulo 9 Universidad Carlos III de Madrid 10 B. Patil 11 Nokia 12 H. Tschofenig 13 Siemens 14 January 23, 2007 16 Anonymous Layers Identifiers (ALIen): Threat Model for Mobile and 17 Multihomed Nodes 18 draft-haddad-alien-threat-model-00.txt 20 Status of this Memo 22 By submitting this Internet-Draft, each author represents that any 23 applicable patent or other IPR claims of which he or she is aware 24 have been or will be disclosed, and any of which he or she becomes 25 aware will be disclosed, in accordance with Section 6 of BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF), its areas, and its working groups. Note that 29 other groups may also distribute working documents as Internet- 30 Drafts. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 The list of current Internet-Drafts can be accessed at 38 http://www.ietf.org/ietf/1id-abstracts.txt. 40 The list of Internet-Draft Shadow Directories can be accessed at 41 http://www.ietf.org/shadow.html. 43 This Internet-Draft will expire on July 27, 2007. 45 Copyright Notice 47 Copyright (C) The Internet Society (2007). 49 Abstract 51 This memo describes privacy threats related to the MAC and IP layers 52 identifiers in a mobile and multi-homed environment. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 58 3. Threat Model Applied to Privacy . . . . . . . . . . . . . . . 5 59 4. Threat Model Applied to Privacy on the MAC Layer . . . . . . . 7 60 4.1. Threats from Collecting Data . . . . . . . . . . . . . . . 7 61 4.1.1. Discovering the Identity Presence . . . . . . . . . . 7 62 4.1.2. Determining the Location . . . . . . . . . . . . . . . 8 63 5. Threat Model Applied to Privacy on the IP Layer . . . . . . . 10 64 5.1. Threats Against Privacy in Mobile IPv6 Protocol . . . . . 10 65 5.1.1. Quick Overview of MIPv6 Protocol . . . . . . . . . . . 10 66 5.1.2. Threats Related to MIPv6 BT Mode . . . . . . . . . . . 10 67 5.1.3. Threats Related to MIPv6 RO Mode . . . . . . . . . . . 11 68 6. Threat Model Applied to a Static Multi-homed Node . . . . . . 13 69 6.1. Threats againt Privacy on the MAC Layer . . . . . . . . . 13 70 6.2. Threats against Privacy on the IP Layer . . . . . . . . . 14 71 7. Security Considerations . . . . . . . . . . . . . . . . . . . 15 72 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 73 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17 74 9.1. Normative References . . . . . . . . . . . . . . . . . . . 17 75 9.2. Informative References . . . . . . . . . . . . . . . . . . 17 76 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19 77 Intellectual Property and Copyright Statements . . . . . . . . . . 21 79 1. Introduction 81 The ALIen problem statement document [ALIen] introduced new 82 attributes related to the privacy and described critical privacy 83 issues related to providing these attributes on both the IP and MAC 84 layers. In addition, ALIen highlighted the interdependency between 85 privacy issues on the MAC and IP layers and the need to solve them 86 all together. 88 This memo describes privacy threats and potential attacks related to 89 the MAC and IP layers identifiers in a mobile and multi-homed 90 environment. 92 2. Terminology 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 [RFC2119]. 98 In addition, it would be useful to describe the following entities 99 involved in defining threats against privacy: 101 Target 103 We use the term "target" to specify an entity who's privacy is 104 threatened by an adversary/malicious node. 106 Adversary/Malicious Node 108 This term refers to the entity that is trying to violate the 109 privacy of its target. 111 In addition, this draft uses the terminology described in [ALIen]. 113 3. Threat Model Applied to Privacy 115 Before listing threats against privacy, we start by describing the 116 privacy threat model, which will be applied on the MAC and IP layers 117 in order to perform our analysis. The locations of adversaries 118 violating privacy must be taken into account when analyzing different 119 threats. 121 In a mobile environment, the three main threats against privacy are 122 the following: 124 o Identifying 126 o Locating 128 o Tracing 130 In the ALIen context, a malicious node can identify its target via 131 its device identifier(s), i.e., MAC address and/or its IPv6 132 address(es). Once the identification procedure is achieved, it 133 becomes by itself a threat against privacy, since a malicious node 134 located in one particular place will be able to claim with certain 135 confidence that its target was present in the same place at a 136 specific time, by just capturing its MAC address. 138 The next logic step after identifying a target is to locate it with 139 maximum accuracy. The third step consists on tracing the target 140 (possibly in real-time) while it is moving across the Internet. 142 Performing these three steps allow the malicious node to gradually 143 increase its knowledge about its target by gathering more and more 144 information about it. These information may allow, for example to 145 build a profile of the target and then to launch specific attacks or 146 to misuse the obtained information in other ways (e.g., marketing 147 purposes, statistics, etc). Data gathered may include higher-layer 148 identifiers (e.g., email addresses) or pseudonyms, location 149 information, temporal information, mobility patterns, etc. 151 In order to access the MAC address of a targeted node in a WLAN, the 152 malicious node needs to be either on the same link or within the 153 distributed system (DS). However, in other scenarios, especially in 154 the ongoing deployment of public outdoor WLAN technologies, more 155 complex attacks involving multiple malicious nodes need to be 156 considered. 158 Actually, taking a look at today's WLAN deployments in some cities 159 like Chicago and New York [WIGLE] gives a clear picture of the high 160 density of APs already deployed. These examples of today's WLAN 161 deployment lead to the following conclusions: 163 o the high density of APs deployed nowadays greatly extends the 164 spatial and temporal coverage of the three main threats against 165 privacy mentioned above. 167 o the MAC address is becoming easier to detect and thus is causing a 168 growing privacy concern, in particular for mobility. 170 o in some existing public areas covered by WLAN technologies, any 171 efficient tracing of a designed target is greatly improved 172 whenever multiple co-operative malicious nodes are deployed in 173 different locations covered by WLAN technologies. 175 Based on the above, the suggested threat model when applied to the 176 MAC layer should take into consideration the classic scenario, where 177 one malicious node is collecting data on the link/DS and the scenario 178 where many malicious nodes are deployed in different locations, 179 within the WLAN covered area, and performing data collection while 180 collaborating together for identifying, locating and tracking 181 purposes. 183 4. Threat Model Applied to Privacy on the MAC Layer 185 We start our analyze by applying the threat model to the MAC layer. 187 4.1. Threats from Collecting Data 189 4.1.1. Discovering the Identity Presence 191 The WLAN technologies discloses the user's device identifier, i.e., 192 the MAC address, in each data frame sent/received by the mobile node 193 (MN) within the distribution system (DS) thus, making the device 194 identifier readable/available to any malicious eavesdropper located 195 on the link or in the same DS. 197 Based on this observation, collecting data on one particular link/DS, 198 coupled with prior knowledge of the targeted node's MAC address 199 allows the malicious node to check first if its target is located 200 within the covered area or not. 202 An eavesdropper can perform data collecting via two ways. The first 203 one is by positioning itself on the link/DS and sniffing packets 204 exchanged between the MNs and the APs. The second way consists on 205 deploying rogue access points in some particular areas. The ability 206 to deploy rogue access points requires a missing security protection 207 of the WLAN network. 209 In WLAN, the targeted MN does not even need to exchange data packets 210 with another node, to disclose its MAC address to a malicious node 211 eavesdropping on the same link than the MN. In fact, the target's 212 MAC address appears in control messages exchanged between the MN and 213 the AP(s) or between different MNs (adhoc mode). 215 In addition, identifying the target allows the malicious node to 216 learn the target's IPv6 address and the data sequence number. 218 On the other side, a malicious node collecting data from one 219 particular DS, may also try to conduct an active search for its 220 target within the DS by trying to connect to the target, using the 221 IPv6 address derived from the link local address, according to the 222 stateless address configuration protocol defined in [STAT]. In such 223 scenario, if the targeted node replies to the malicious node's 224 request while being located within the same DS, then its presence 225 will immediately be detected. 227 A malicious node may also choose and add new targets to its list, 228 based on other criterias, which are learned from collecting data. 229 For example, the frequency, timing and the presence duration of one 230 particular node may encourage the malicious eavsedeopper to learn 231 more in order to gradually build a profile for that node. 233 4.1.2. Determining the Location 235 After identifying its target within a DS, a malicious node may 236 attempt to determine its location. Such step can be performed by 237 different means. 239 But it should be noted first, that discovering the target's presence 240 on the MAC layer, implicitly maps its geographical location within a 241 specific area. Depending on the network topology and the link layer 242 technology, this area might be quite large or might have a fairly 243 irregular shape. Hence, the malicious node may want to learn the 244 most accurate location of its target. 246 It is also possible to determine the geographical location of the MN 247 with a certain accuracy at the physical layer. This is done by 248 identifying the Access Point (AP) to which, the MN is currently 249 attached and then trying to determine the geographical location of 250 the corresponding AP. 252 4.1.2.1. Tracing the Target 254 After identifying and locating its target, a malicious node located 255 in a particular DS, can use data collecting to trace its target in 256 real time within the entire ESS. 258 Tracing can be done either via the target's MAC address or its IPv6 259 address or via the data sequence number carried in each data frame or 260 through combining them. 262 On the other side, these information allow the malicious node to 263 break the unlinkability protection provided by changing the MAC 264 address, e.g., during a L2 handoff, since it will always be possible 265 to trace the MN by other tools than its MAC address. 267 4.1.2.2. Threats from Various Malicious Nodes 269 An efficient way to trace a target within an area covered by wireless 270 link layer technologies is by deploying many malicious nodes within 271 one specific area. 273 As it has been mentioned above, a malicious node located within a 274 specific DS can trace its target only within the DS. However, there 275 may be scenarios where tracing a particular target needs to go beyond 276 one specific DS boundaries. In addition, the target MN's MAC address 277 may change many times before the MN leaves the DS. Consequently, 278 even if the new DS is monitored by a malicious eavesdropper, it will 279 not be possible for him to identify the target anymore. 281 If the malicious nodes collaborate with each other, it would be 282 possible to keep tracing the target within a specific region. In 283 fact, the main goals behind collaborative tracing is to break the 284 unlinkability protection when provided in an independent way at the 285 MAC and IP layers. In fact, changing the MAC address alone while 286 keeping using the same IP address will always make the target 287 identifiable and traceable through different DSs. 289 Note that in addition to using the MAC and IP addresses, the sequence 290 number can also be used for tracing purposes. 292 5. Threat Model Applied to Privacy on the IP Layer 294 Learning the target's IP address discloses the topological location, 295 which may in turn reveal also geographical location information of 296 the target. For example, location specific extensions to the DNS 297 directory [LOC_DNS] can help to reveal further information about the 298 geographical location of a particular IP address. Tools are also 299 available, e.g., [HEO] that allows everyone to querry this 300 information using a graphical interface. Note that the location 301 information cannot be always correct, for example due to state 302 entries in the DNS, NATed IP addresses, usage of tunnels (e.g., VPN, 303 Mobile IP, etc.). 305 This information can be used to link the current target's location(s) 306 to the regular one and provide the eavesdropper more information 307 about its target's movements in real time. 309 5.1. Threats Against Privacy in Mobile IPv6 Protocol 311 In Mobile IPv6 protocol (described in [MIPv6]), threats against 312 privacy can originate from the correspondent node (CN) and/or from a 313 malicious node(s) located either between the MN and the CN or between 314 the MN and its home agent (HA). 316 5.1.1. Quick Overview of MIPv6 Protocol 318 MIPv6 protocol allows a mobile node to switch between different 319 networks, while keeping ongoing session(s) alive. For this purpose, 320 MIPv6 offers two modes to handle the mobility problem. The first 321 mode is the bidirectional tunnelling (BT) mode, which hides the MN's 322 movements from the CN by sending all data packets through the MN's 323 HA. Consequently, the BT mode provides a certain level of location 324 privacy by hiding the MN's current location from the CN. 326 The other mode is the route optimization (RO) mode, which allows the 327 MN to keep exchanging data packets on the direct path with the CN, 328 while moving outside its home network. For this purpose, the MN 329 needs to update the CN with its current new location each time it 330 switches to a new network. This is done by sending a binding update 331 (BU) message to the CN to update its binding cache entry (BCE) with 332 the MN's new location, i.e., care-of address (CoA). In addition, the 333 RO mode requires the MN and the CN to insert the MN's home address 334 (HoA) in each data packet exchanged between them. 336 5.1.2. Threats Related to MIPv6 BT Mode 338 As mentioned above, the BT mode keeps the CN totally unaware of the 339 MN's movements across the Internet. However, the MN must update its 340 HA with its new current location each time it switches to a new 341 network, in order to enable the HA to encapsulate data packets to its 342 new location, i.e., new CoA. 344 In the BT mode, tracing the MN can either be done via the MAC address 345 as described earlier, or by having a malicious node located somewhere 346 between the MN and the HA, and looking into the inner data packet 347 header. 349 On the other side, the MIPv6 protocol suggests that the tunnel 350 between the MN and the HA can be protected with ESP protocol. In 351 such case, the malicious node won't be able anymore to identify its 352 target (when located between the MN and the HA) thus making the 353 tracing impossible. However, tracing can always be possible at the 354 MAC layer. 356 5.1.3. Threats Related to MIPv6 RO Mode 358 The MIPv6 RO mode and all new optimizations, e.g., [OMIPv6], 359 [MIPSec], etc, requires that the MN sends a BU message to update the 360 CN in order to announce its new current location after each IP 361 handover, and to insert the MN's home address in each data packets 362 sent to/from the MN. 364 Consequently, threats against MN's privacy can emanate from a 365 malicious CN, which starts by establishing a session with the target, 366 i.e., by using its target's IPv6 HoA, sending it enough data packets 367 and then waiting till its target switches to the RO mode. 369 But it should be noted that the MN may not decide to switch to the RO 370 mode but keep using instead the BT mode, in order to avoid disclosing 371 its current location to the CN. 373 On the other side, a malicious node may position itself somewhere on 374 the direct path between the MN and the CN and learn the MN's current 375 location from sniffing the BU message(s) and/or the data packets 376 exchanged between the two entities. 378 Another possibility is to do the tracing on the MAC address. As 379 mentioned above, this requires the malicious node to be located on 380 the same link/DS than the MN. 382 The MIPv6 RO mode requires protecting all signalling messages 383 exchanged between the MN and the HA by an ESP tunnel. In such case, 384 a malicious node located between the MN and the HA cannot identify 385 its target. 387 However, the IETF has recently adopted a new authentication protocol 388 for MIPv6 [MIPAuth], which allows securing the BU/BA signalling 389 messages exchanged between the HA and the MN by using an 390 authentication option carried in the BU/BA messages. 392 MIP6_AUTH protocol may have a serious impact on the MN's privacy, 393 since it offers the malicious node a new location, i.e., the path 394 between the targeted MN and its HA, to identify, locate and trace its 395 target. This is in addition to positioning itself on the path 396 between the targeted MN and the CN. It should be noted also that the 397 path between the MN and the HA may be more interesting to use in 398 order to break the MN's privacy, since the MN may try to hide its 399 real identity (and consequently its location) from the CN, as 400 proposed in [MIPLOP] while still using the real IPv6 home address to 401 exchange signalling messages with its HA. 403 Furthermore, it would also be possible to learn the MN's pseudo- 404 identifier(s) used in exchanging data packets and signalling messages 405 between the MN and the CN on the direct path, by having two malicious 406 nodes located between the MN and the HA and between the MN and the CN 407 and collaborating together. 409 6. Threat Model Applied to a Static Multi-homed Node 411 A multi-homed node can be described as being attached to more than 412 one Internet Service Provider (ISP). Consequently, the multiple 413 addresses available to a multi-homed node are pre-defined and known 414 in advance in most of the cases. 416 The main goals behind providing the multi-homing feature are to allow 417 the multi-homed node to use multiple attachments in parallel and the 418 ability to switch between these different attachments during an 419 ongoing session(s), e.g., in case of a failure. 421 For these purposes, the SHIM6 WG specified a proposal to address 422 multi-homing issues, based on using the Hash Based Addresses 423 (described in [HBA]) and the SHIM6 protocol (described in [SHIM6]). 425 The HBA technology offers a new mechanism to provide a secure binding 426 between multiple addresses with different prefixes available to a 427 host within a multihomed site. This is achieved by generating the 428 interface identifiers of the addresses of a host as hashes of the 429 available prefixes and a random number. Then, the multiple addresses 430 are generated by prepending the different prefixes to the generated 431 interface identifiers. The result is a set of addresses that are 432 inherently bound. In addition, the HBA technology allows the CN to 433 verify if two HBA addresses belong to the same HBA set. 435 The SHIM6 protocol aims to eliminate any impact on upper layer 436 protocols by ensuring that they can keep operating unmodified in a 437 multi-homed environment while still seeing a stable IPv6 address. 439 For a static multi-homed, the main privacy concern are the ability to 440 identify the multi-homed node by an untrusted party and to discover 441 its available addresses. The untrusted party can be the CN itself or 442 a third party located somewhere between the multi-homed node and the 443 CN. 445 6.1. Threats againt Privacy on the MAC Layer 447 A malicious node can identify the targeted multi-homed node via its 448 MAC address. The ability to identify the target at the MAC layer 449 allows the malicious node to learn part or all available locators 450 used by the targeted node. However, it should be noted that for a 451 static target, a successful identification of the MAC address may 452 probably require more precise information concerning the geographical 453 location of the target. 455 6.2. Threats against Privacy on the IP Layer 457 In a multi-homed environment, threats against privacy on the IP layer 458 can emanate from the CN itself, in an attempt to learn part/all 459 multi-homed node's available locators. 461 For example, a malicious CN can use one pre-identified locator 462 belonging to its target, to establish a session with the target. 463 After that, the CN can try to push its target to switch (i.e., 464 disclose) to new locator(s) by stopping replying to packets sent with 465 the initial address, i.e., pretending a failure. In such scenario, 466 and in order to avoid interrupting ongoing session, the targeted node 467 may decide to switch to another (or more) locator(s), depending on 468 the CN willingness to re-start sending packets to the new locator. 470 On the other side, an untrusted third party located near its target 471 (e.g., based on prior knowledge of one of the target's locator) or 472 one particular CN, can correlate between different locators used by 473 the targeted node by eavesdropping on packets exchanged between the 474 two entities. 476 Depending on the final solution adopted, the attacker can also sniff 477 context establishment packets that will probably contain some or all 478 the locators available to the multi-homed node. 480 7. Security Considerations 482 This document aims to formalize a privacy threat model for the MAC 483 and IP layers and does not suggest any solutions to counter these 484 threats. Based on that, the suggested threat model does not add nor 485 amplify any existing attacks against the mobile or multi-homed node. 487 8. IANA Considerations 489 This document has no IANA considerations. 491 9. References 493 9.1. Normative References 495 [MIPAuth] Patel, A., Leung, K., Khalil, M., Akhtar, H., and K. 496 Chowdhury, "Authentication Protocol for Mobile IPv6", 497 RFC 4285, January 2006. 499 [MIPv6] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support 500 for IPv6", RFC 3775, June 2004. 502 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 503 Requirement Levels", March 1997. 505 [STAT] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 506 Address Autoconfiguration", Internet 507 Draft, draft-ietf-ipv6-rfc2462bis-08.txt, May 2005. 509 9.2. Informative References 511 [ALIen] Haddad, W., Nordmark, E., Dupont, F., Bagnulo, M., and B. 512 Patil, "Anonymous Layers Identifiers for Mobile and Multi- 513 homed Nodes: Problem Statement", Internet 514 Draft, draft-haddad-alien-problem-statement-00.txt, 515 January 2007. 517 [HBA] Bagnulo, M., "Hash Based Addresses (HBA)", Internet 518 Draft, draft-ietf-shim6-hba-02.txt, October 2006. 520 [HEO] "High Earth Orbit", February 2005. 522 [LOC_DNS] Davis, C., Vixie, P., Goodwin, T., and I. Dickinson, "A 523 Means for Expressing Location Information in the Domain 524 Name System", RFC 1876, January 1996. 526 [MIPLOP] Montenegro, G., Castelluccia, C., and F. Dupont, "A 527 Simple Privacy Extension for Mobile IPv6", Mobile and 528 Wireless Communication Networks", IEEE MCWN, October 2004. 530 [MIPSec] Dupont, F. and J-M. Combes, "", Internet 531 Draft, draft-ietf-mip6-cn-ipsec-03.txt, August 2006. 533 [OMIPv6] Arkko, J., Vogt, C., and W. Haddad, "Enhanced Route 534 Optimization for Mobile IPv6", Internet 535 Draft, draft-ietf-mipshop-cga-cba-02.txt, December 2006. 537 [SHIM6] Nordmark, E. and M. Bagnulo, "Level 3 multihoming shim 538 protocol", Internet Draft, draft-ietf-shim6-proto-07.txt, 539 November 2006. 541 [WIGLE] "Wireless Geographic Logging Engine, 542 http://wigle.net/gps/gps/Map/", 2006. 544 Authors' Addresses 546 Wassim Haddad 547 Ericsson Research 548 Torshamnsgatan 23 549 SE-164 Stockholm 550 Sweden 552 Phone: +46 84044079 553 Email: Wassim.Haddad@ericsson.com 555 Erik Nordmark 556 Sun Microsystems, Inc. 557 17 Network Circle 558 Mountain View, CA 559 USA 561 Email: Erik.Nordmark@sun.com 563 Francis Dupont 564 CELAR 565 France 567 Email: Francis.Dupont@fdupont.fr 569 Marcelo Bagnulo 570 Universidad Carlos III de Madrid 571 Av. Universidad 30, leganes 572 Madrid 28911 573 Spain 575 Email: Marcelo@it.uc3m.es 577 Basavaraj Patil 578 Nokia 579 6000 Connection Drive 580 Irving, Tx 75039 581 USA 583 Email: Basavaraj.Patil@nokia.com 584 Hannes Tschofenig 585 Siemens 586 Otto-Hahn-Ring 6 587 Munich, Bayern 81739 588 Germany 590 Email: Hannes.Tschofenig@siemens.com 592 Intellectual Property Statement 594 The IETF takes no position regarding the validity or scope of any 595 Intellectual Property Rights or other rights that might be claimed to 596 pertain to the implementation or use of the technology described in 597 this document or the extent to which any license under such rights 598 might or might not be available; nor does it represent that it has 599 made any independent effort to identify any such rights. Information 600 on the procedures with respect to rights in RFC documents can be 601 found in BCP 78 and BCP 79. 603 Copies of IPR disclosures made to the IETF Secretariat and any 604 assurances of licenses to be made available, or the result of an 605 attempt made to obtain a general license or permission for the use of 606 such proprietary rights by implementers or users of this 607 specification can be obtained from the IETF on-line IPR repository at 608 http://www.ietf.org/ipr. 610 The IETF invites any interested party to bring to its attention any 611 copyrights, patents or patent applications, or other proprietary 612 rights that may cover technology that may be required to implement 613 this standard. Please address the information to the IETF at 614 ietf-ipr@ietf.org. 616 Disclaimer of Validity 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 AND THE INTERNET 621 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 622 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 623 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 624 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 626 Copyright Statement 628 Copyright (C) The Internet Society (2007). This document is subject 629 to the rights, licenses and restrictions contained in BCP 78, and 630 except as set forth therein, the authors retain all their rights. 632 Acknowledgment 634 Funding for the RFC Editor function is currently provided by the 635 Internet Society.