idnits 2.17.00 (12 Aug 2021) /tmp/idnits10786/draft-haddad-alien-threat-model-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.ii or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) 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 and authors 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 (March 9, 2009) is 4821 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 (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group W. Haddad 3 Internet-Draft 4 Intended status: Informational E. Nordmark 5 Expires: September 10, 2009 Sun Microsystems, Inc. 6 F. Dupont 7 ISC 8 M. Bagnulo 9 Universidad Carlos III de Madrid 10 B. Patil 11 Nokia 12 H. Tschofenig 13 Nokia Siemens 14 March 9, 2009 16 Anonymous Layers Identifiers (ALIen): Threat Model for Mobile and 17 Multihomed Nodes 18 draft-haddad-alien-threat-model-03 20 Status of this Memo 22 This Internet-Draft is submitted to IETF in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF), its areas, and its working groups. Note that 27 other groups may also distribute working documents as Internet- 28 Drafts. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 The list of current Internet-Drafts can be accessed at 36 http://www.ietf.org/ietf/1id-abstracts.txt. 38 The list of Internet-Draft Shadow Directories can be accessed at 39 http://www.ietf.org/shadow.html. 41 This Internet-Draft will expire on September 10, 2009. 43 Copyright Notice 45 Copyright (c) 2009 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents in effect on the date of 50 publication of this document (http://trustee.ietf.org/license-info). 51 Please review these documents carefully, as they describe your rights 52 and restrictions with respect to this document. 54 Abstract 56 This memo describes privacy threats related to the MAC and IP layers 57 identifiers in a mobile and multi-homed environment. 59 Table of Contents 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 62 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 63 3. Threat Model Applied to Privacy . . . . . . . . . . . . . . . 6 64 4. Threat Model Applied to Privacy on the MAC Layer . . . . . . . 8 65 4.1. Threats from Collecting Data . . . . . . . . . . . . . . . 8 66 4.1.1. Discovering the Identity Presence . . . . . . . . . . 8 67 4.1.2. Determining the Location . . . . . . . . . . . . . . . 9 68 5. Threat Model Applied to Privacy on the IP Layer . . . . . . . 11 69 5.1. Threats Against Privacy in Mobile IPv6 Protocol . . . . . 11 70 5.1.1. Quick Overview of MIPv6 Protocol . . . . . . . . . . . 11 71 5.1.2. Threats Related to MIPv6 BT Mode . . . . . . . . . . . 11 72 5.1.3. Threats Related to MIPv6 RO Mode . . . . . . . . . . . 12 73 6. Threat Model Applied to a Static Multi-homed Node . . . . . . 14 74 6.1. Threats againt Privacy on the MAC Layer . . . . . . . . . 14 75 6.2. Threats against Privacy on the IP Layer . . . . . . . . . 15 76 7. Security Considerations . . . . . . . . . . . . . . . . . . . 16 77 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 78 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18 79 9.1. Normative References . . . . . . . . . . . . . . . . . . . 18 80 9.2. Informative References . . . . . . . . . . . . . . . . . . 18 81 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20 83 1. Introduction 85 The ALIen problem statement document [ALIen] introduced new 86 attributes related to the privacy and described critical privacy 87 issues related to providing these attributes on both the IP and MAC 88 layers. In addition, ALIen highlighted the interdependency between 89 privacy issues on the MAC and IP layers and the need to solve them 90 all together. 92 This memo describes privacy threats and potential attacks related to 93 the MAC and IP layers identifiers in a mobile and multi-homed 94 environment. 96 2. Terminology 98 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 99 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 100 document are to be interpreted as described in [RFC2119]. 102 In addition, it would be useful to describe the following entities 103 involved in defining threats against privacy: 105 Target 107 We use the term "target" to specify an entity who's privacy is 108 threatened by an adversary/malicious node. 110 Adversary/Malicious Node 112 This term refers to the entity that is trying to violate the 113 privacy of its target. 115 In addition, this draft uses the terminology described in [ALIen]. 117 3. Threat Model Applied to Privacy 119 Before listing threats against privacy, we start by describing the 120 privacy threat model, which will be applied on the MAC and IP layers 121 in order to perform our analysis. The locations of adversaries 122 violating privacy must be taken into account when analyzing different 123 threats. 125 In a mobile environment, the three main threats against privacy are 126 the following: 128 o Identifying 130 o Locating 132 o Tracing 134 In the ALIen context, a malicious node can identify its target via 135 its device identifier(s), i.e., MAC address and/or its IPv6 136 address(es). Once the identification procedure is achieved, it 137 becomes by itself a threat against privacy, since a malicious node 138 located in one particular place will be able to claim with certain 139 confidence that its target was present in the same place at a 140 specific time, by just capturing its MAC address. 142 The next logic step after identifying a target is to locate it with 143 maximum accuracy. The third step consists on tracing the target 144 (possibly in real-time) while it is moving across the Internet. 146 Performing these three steps allow the malicious node to gradually 147 increase its knowledge about its target by gathering more and more 148 information about it. These information may allow, for example to 149 build a profile of the target and then to launch specific attacks or 150 to misuse the obtained information in other ways (e.g., marketing 151 purposes, statistics, etc). Data gathered may include higher-layer 152 identifiers (e.g., email addresses) or pseudonyms, location 153 information, temporal information, mobility patterns, etc. 155 In order to access the MAC address of a targeted node in a WLAN, the 156 malicious node needs to be either on the same link or within the 157 distributed system (DS). However, in other scenarios, especially in 158 the ongoing deployment of public outdoor WLAN technologies, more 159 complex attacks involving multiple malicious nodes need to be 160 considered. 162 Actually, taking a look at today's WLAN deployments in some cities 163 like Chicago and New York [WIGLE] gives a clear picture of the high 164 density of APs already deployed. These examples of today's WLAN 165 deployment lead to the following conclusions: 167 o the high density of APs deployed nowadays greatly extends the 168 spatial and temporal coverage of the three main threats against 169 privacy mentioned above. 171 o the MAC address is becoming easier to detect and thus is causing a 172 growing privacy concern, in particular for mobility. 174 o in some existing public areas covered by WLAN technologies, any 175 efficient tracing of a designed target is greatly improved 176 whenever multiple co-operative malicious nodes are deployed in 177 different locations covered by WLAN technologies. 179 Based on the above, the suggested threat model when applied to the 180 MAC layer should take into consideration the classic scenario, where 181 one malicious node is collecting data on the link/DS and the scenario 182 where many malicious nodes are deployed in different locations, 183 within the WLAN covered area, and performing data collection while 184 collaborating together for identifying, locating and tracking 185 purposes. 187 4. Threat Model Applied to Privacy on the MAC Layer 189 We start our analyze by applying the threat model to the MAC layer. 191 4.1. Threats from Collecting Data 193 4.1.1. Discovering the Identity Presence 195 The WLAN technologies discloses the user's device identifier, i.e., 196 the MAC address, in each data frame sent/received by the mobile node 197 (MN) within the distribution system (DS) thus, making the device 198 identifier readable/available to any malicious eavesdropper located 199 on the link or in the same DS. 201 Based on this observation, collecting data on one particular link/DS, 202 coupled with prior knowledge of the targeted node's MAC address 203 allows the malicious node to check first if its target is located 204 within the covered area or not. 206 An eavesdropper can perform data collecting via two ways. The first 207 one is by positioning itself on the link/DS and sniffing packets 208 exchanged between the MNs and the APs. The second way consists on 209 deploying rogue access points in some particular areas. The ability 210 to deploy rogue access points requires a missing security protection 211 of the WLAN network. 213 In WLAN, the targeted MN does not even need to exchange data packets 214 with another node, to disclose its MAC address to a malicious node 215 eavesdropping on the same link than the MN. In fact, the target's 216 MAC address appears in control messages exchanged between the MN and 217 the AP(s) or between different MNs (adhoc mode). 219 In addition, identifying the target allows the malicious node to 220 learn the target's IPv6 address and the data sequence number. 222 On the other side, a malicious node collecting data from one 223 particular DS, may also try to conduct an active search for its 224 target within the DS by trying to connect to the target, using the 225 IPv6 address derived from the link local address, according to the 226 stateless address configuration protocol defined in [STAT]. In such 227 scenario, if the targeted node replies to the malicious node's 228 request while being located within the same DS, then its presence 229 will immediately be detected. 231 A malicious node may also choose and add new targets to its list, 232 based on other criterias, which are learned from collecting data. 233 For example, the frequency, timing and the presence duration of one 234 particular node may encourage the malicious eavsedeopper to learn 235 more in order to gradually build a profile for that node. 237 4.1.2. Determining the Location 239 After identifying its target within a DS, a malicious node may 240 attempt to determine its location. Such step can be performed by 241 different means. 243 But it should be noted first, that discovering the target's presence 244 on the MAC layer, implicitly maps its geographical location within a 245 specific area. Depending on the network topology and the link layer 246 technology, this area might be quite large or might have a fairly 247 irregular shape. Hence, the malicious node may want to learn the 248 most accurate location of its target. 250 It is also possible to determine the geographical location of the MN 251 with a certain accuracy at the physical layer. This is done by 252 identifying the Access Point (AP) to which, the MN is currently 253 attached and then trying to determine the geographical location of 254 the corresponding AP. 256 4.1.2.1. Tracing the Target 258 After identifying and locating its target, a malicious node located 259 in a particular DS, can use data collecting to trace its target in 260 real time within the entire ESS. 262 Tracing can be done either via the target's MAC address or its IPv6 263 address or via the data sequence number carried in each data frame or 264 through combining them. 266 On the other side, these information allow the malicious node to 267 break the unlinkability protection provided by changing the MAC 268 address, e.g., during a L2 handoff, since it will always be possible 269 to trace the MN by other tools than its MAC address. 271 4.1.2.2. Threats from Various Malicious Nodes 273 An efficient way to trace a target within an area covered by wireless 274 link layer technologies is by deploying many malicious nodes within 275 one specific area. 277 As it has been mentioned above, a malicious node located within a 278 specific DS can trace its target only within the DS. However, there 279 may be scenarios where tracing a particular target needs to go beyond 280 one specific DS boundaries. In addition, the target MN's MAC address 281 may change many times before the MN leaves the DS. Consequently, 282 even if the new DS is monitored by a malicious eavesdropper, it will 283 not be possible for him to identify the target anymore. 285 If the malicious nodes collaborate with each other, it would be 286 possible to keep tracing the target within a specific region. In 287 fact, the main goals behind collaborative tracing is to break the 288 unlinkability protection when provided in an independent way at the 289 MAC and IP layers. In fact, changing the MAC address alone while 290 keeping using the same IP address will always make the target 291 identifiable and traceable through different DSs. 293 Note that in addition to using the MAC and IP addresses, the sequence 294 number can also be used for tracing purposes. 296 5. Threat Model Applied to Privacy on the IP Layer 298 Learning the target's IP address discloses the topological location, 299 which may in turn reveal also geographical location information of 300 the target. For example, location specific extensions to the DNS 301 directory [LOC_DNS] can help to reveal further information about the 302 geographical location of a particular IP address. Tools are also 303 available, e.g., [HEO] that allows everyone to querry this 304 information using a graphical interface. Note that the location 305 information cannot be always correct, for example due to state 306 entries in the DNS, NATed IP addresses, usage of tunnels (e.g., VPN, 307 Mobile IP, etc.). 309 This information can be used to link the current target's location(s) 310 to the regular one and provide the eavesdropper more information 311 about its target's movements in real time. 313 5.1. Threats Against Privacy in Mobile IPv6 Protocol 315 In Mobile IPv6 protocol (described in [MIPv6]), threats against 316 privacy can originate from the correspondent node (CN) and/or from a 317 malicious node(s) located either between the MN and the CN or between 318 the MN and its home agent (HA). 320 5.1.1. Quick Overview of MIPv6 Protocol 322 MIPv6 protocol allows a mobile node to switch between different 323 networks, while keeping ongoing session(s) alive. For this purpose, 324 MIPv6 offers two modes to handle the mobility problem. The first 325 mode is the bidirectional tunnelling (BT) mode, which hides the MN's 326 movements from the CN by sending all data packets through the MN's 327 HA. Consequently, the BT mode provides a certain level of location 328 privacy by hiding the MN's current location from the CN. 330 The other mode is the route optimization (RO) mode, which allows the 331 MN to keep exchanging data packets on the direct path with the CN, 332 while moving outside its home network. For this purpose, the MN 333 needs to update the CN with its current new location each time it 334 switches to a new network. This is done by sending a binding update 335 (BU) message to the CN to update its binding cache entry (BCE) with 336 the MN's new location, i.e., care-of address (CoA). In addition, the 337 RO mode requires the MN and the CN to insert the MN's home address 338 (HoA) in each data packet exchanged between them. 340 5.1.2. Threats Related to MIPv6 BT Mode 342 As mentioned above, the BT mode keeps the CN totally unaware of the 343 MN's movements across the Internet. However, the MN must update its 344 HA with its new current location each time it switches to a new 345 network, in order to enable the HA to encapsulate data packets to its 346 new location, i.e., new CoA. 348 In the BT mode, tracing the MN can either be done via the MAC address 349 as described earlier, or by having a malicious node located somewhere 350 between the MN and the HA, and looking into the inner data packet 351 header. 353 On the other side, the MIPv6 protocol suggests that the tunnel 354 between the MN and the HA can be protected with ESP protocol. In 355 such case, the malicious node won't be able anymore to identify its 356 target (when located between the MN and the HA) thus making the 357 tracing impossible. However, tracing can always be possible at the 358 MAC layer. 360 5.1.3. Threats Related to MIPv6 RO Mode 362 The MIPv6 RO mode and all new optimizations, e.g., [OMIPv6], 363 [MIPSec], etc, requires that the MN sends a BU message to update the 364 CN in order to announce its new current location after each IP 365 handover, and to insert the MN's home address in each data packets 366 sent to/from the MN. 368 Consequently, threats against MN's privacy can emanate from a 369 malicious CN, which starts by establishing a session with the target, 370 i.e., by using its target's IPv6 HoA, sending it enough data packets 371 and then waiting till its target switches to the RO mode. 373 But it should be noted that the MN may not decide to switch to the RO 374 mode but keep using instead the BT mode, in order to avoid disclosing 375 its current location to the CN. 377 On the other side, a malicious node may position itself somewhere on 378 the direct path between the MN and the CN and learn the MN's current 379 location from sniffing the BU message(s) and/or the data packets 380 exchanged between the two entities. 382 Another possibility is to do the tracing on the MAC address. As 383 mentioned above, this requires the malicious node to be located on 384 the same link/DS than the MN. 386 The MIPv6 RO mode requires protecting all signalling messages 387 exchanged between the MN and the HA by an ESP tunnel. In such case, 388 a malicious node located between the MN and the HA cannot identify 389 its target. 391 However, the IETF has recently adopted a new authentication protocol 392 for MIPv6 [MIPAuth], which allows securing the BU/BA signalling 393 messages exchanged between the HA and the MN by using an 394 authentication option carried in the BU/BA messages. 396 MIP6_AUTH protocol may have a serious impact on the MN's privacy, 397 since it offers the malicious node a new location, i.e., the path 398 between the targeted MN and its HA, to identify, locate and trace its 399 target. This is in addition to positioning itself on the path 400 between the targeted MN and the CN. It should be noted also that the 401 path between the MN and the HA may be more interesting to use in 402 order to break the MN's privacy, since the MN may try to hide its 403 real identity (and consequently its location) from the CN, as 404 proposed in [MIPLOP] while still using the real IPv6 home address to 405 exchange signalling messages with its HA. 407 Furthermore, it would also be possible to learn the MN's pseudo- 408 identifier(s) used in exchanging data packets and signalling messages 409 between the MN and the CN on the direct path, by having two malicious 410 nodes located between the MN and the HA and between the MN and the CN 411 and collaborating together. 413 6. Threat Model Applied to a Static Multi-homed Node 415 A multi-homed node can be described as being attached to more than 416 one Internet Service Provider (ISP). Consequently, the multiple 417 addresses available to a multi-homed node are pre-defined and known 418 in advance in most of the cases. 420 The main goals behind providing the multi-homing feature are to allow 421 the multi-homed node to use multiple attachments in parallel and the 422 ability to switch between these different attachments during an 423 ongoing session(s), e.g., in case of a failure. 425 For these purposes, the SHIM6 WG specified a proposal to address 426 multi-homing issues, based on using the Hash Based Addresses 427 (described in [HBA]) and the SHIM6 protocol (described in [SHIM6]). 429 The HBA technology offers a new mechanism to provide a secure binding 430 between multiple addresses with different prefixes available to a 431 host within a multihomed site. This is achieved by generating the 432 interface identifiers of the addresses of a host as hashes of the 433 available prefixes and a random number. Then, the multiple addresses 434 are generated by prepending the different prefixes to the generated 435 interface identifiers. The result is a set of addresses that are 436 inherently bound. In addition, the HBA technology allows the CN to 437 verify if two HBA addresses belong to the same HBA set. 439 The SHIM6 protocol aims to eliminate any impact on upper layer 440 protocols by ensuring that they can keep operating unmodified in a 441 multi-homed environment while still seeing a stable IPv6 address. 443 For a static multi-homed, the main privacy concern are the ability to 444 identify the multi-homed node by an untrusted party and to discover 445 its available addresses. The untrusted party can be the CN itself or 446 a third party located somewhere between the multi-homed node and the 447 CN. 449 6.1. Threats againt Privacy on the MAC Layer 451 A malicious node can identify the targeted multi-homed node via its 452 MAC address. The ability to identify the target at the MAC layer 453 allows the malicious node to learn part or all available locators 454 used by the targeted node. However, it should be noted that for a 455 static target, a successful identification of the MAC address may 456 probably require more precise information concerning the geographical 457 location of the target. 459 6.2. Threats against Privacy on the IP Layer 461 In a multi-homed environment, threats against privacy on the IP layer 462 can emanate from the CN itself, in an attempt to learn part/all 463 multi-homed node's available locators. 465 For example, a malicious CN can use one pre-identified locator 466 belonging to its target, to establish a session with the target. 467 After that, the CN can try to push its target to switch (i.e., 468 disclose) to new locator(s) by stopping replying to packets sent with 469 the initial address, i.e., pretending a failure. In such scenario, 470 and in order to avoid interrupting ongoing session, the targeted node 471 may decide to switch to another (or more) locator(s), depending on 472 the CN willingness to re-start sending packets to the new locator. 474 On the other side, an untrusted third party located near its target 475 (e.g., based on prior knowledge of one of the target's locator) or 476 one particular CN, can correlate between different locators used by 477 the targeted node by eavesdropping on packets exchanged between the 478 two entities. 480 Depending on the final solution adopted, the attacker can also sniff 481 context establishment packets that will probably contain some or all 482 the locators available to the multi-homed node. 484 7. Security Considerations 486 This document aims to formalize a privacy threat model for the MAC 487 and IP layers and does not suggest any solutions to counter these 488 threats. Based on that, the suggested threat model does not add nor 489 amplify any existing attacks against the mobile or multi-homed node. 491 8. IANA Considerations 493 This document has no IANA considerations. 495 9. References 497 9.1. Normative References 499 [MIPAuth] Patel, A., Leung, K., Khalil, M., Akhtar, H., and K. 500 Chowdhury, "Authentication Protocol for Mobile IPv6", 501 RFC 4285, January 2006. 503 [MIPv6] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support 504 for IPv6", RFC 3775, June 2004. 506 [OMIPv6] Arkko, J., Vogt, C., and W. Haddad, "Enhanced Route 507 Optimization for Mobile IPv6", RFC 4866, May 2007. 509 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 510 Requirement Levels", March 1997. 512 [STAT] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 513 Address Autoconfiguration", RFC 4862, September 2007. 515 9.2. Informative References 517 [ALIen] Haddad, W., Nordmark, E., Dupont, F., Bagnulo, M., and B. 518 Patil, "Anonymous Layers Identifiers for Mobile and Multi- 519 homed Nodes: Problem Statement", Internet 520 Draft, draft-haddad-alien-problem-statement-02.txt, 521 October 2007. 523 [HBA] Bagnulo, M., "Hash Based Addresses (HBA)", Internet 524 Draft, draft-ietf-shim6-hba-05.txt, December 2007. 526 [HEO] "High Earth Orbit", February 2005. 528 [LOC_DNS] Davis, C., Vixie, P., Goodwin, T., and I. Dickinson, "A 529 Means for Expressing Location Information in the Domain 530 Name System", RFC 1876, January 1996. 532 [MIPLOP] Montenegro, G., Castelluccia, C., and F. Dupont, "A 533 Simple Privacy Extension for Mobile IPv6", Mobile and 534 Wireless Communication Networks", IEEE MCWN, October 2004. 536 [MIPSec] Dupont, F. and J-M. Combes, "Using IPsec between Mobile 537 and Correspondent IPv6 Nodes", Internet 538 Draft, draft-ietf-mip6-cn-ipsec-07.txt, Februray 2008. 540 [SHIM6] Nordmark, E. and M. Bagnulo, "Shim6: Level 3 Multihoming 541 Shim Protocol for IPv6", Internet 542 Draft, draft-ietf-shim6-proto-10.txt, February 2008. 544 [WIGLE] "Wireless Geographic Logging Engine, 545 http://wigle.net/gps/gps/Map/", 2006. 547 Authors' Addresses 549 Wassim Haddad 550 USA 552 Phone: +1 6462568041 553 Email: wmhaddad@gmail.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 ISC 565 Rennes 566 France 568 Email: Francis.Dupont@fdupont.fr 570 Marcelo Bagnulo 571 Universidad Carlos III de Madrid 572 Av. Universidad 30, leganes 573 Madrid 28911 574 Spain 576 Email: Marcelo@it.uc3m.es 578 Basavaraj Patil 579 Nokia 580 6000 Connection Drive 581 Irving, Tx 75039 582 USA 584 Email: Basavaraj.Patil@nsn.com 585 Hannes Tschofenig 586 Nokia Siemens Networks 587 Linnoitustie 6 588 Espoo 02600 589 Finland 591 Email: Hannes.Tschofenig@nsn.com