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