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