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