idnits 2.17.1 draft-chunduri-karp-is-is-gap-analysis-03.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 date (October 22, 2012) is 4203 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC4107' is defined on line 520, but no explicit reference was found in the text == Outdated reference: A later version (-10) exists of draft-ietf-karp-crypto-key-table-03 == Outdated reference: A later version (-07) exists of draft-ietf-karp-threats-reqs-06 == Outdated reference: A later version (-16) exists of draft-yeung-g-ikev2-05 Summary: 0 errors (**), 0 flaws (~~), 5 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Working Group U. Chunduri 3 Internet-Draft A. Tian 4 Intended status: Informational W. Lu 5 Expires: April 25, 2013 Ericsson Inc., 6 October 22, 2012 8 KARP IS-IS security gap analysis 9 draft-chunduri-karp-is-is-gap-analysis-03 11 Abstract 13 This document analyzes the threats applicable for Intermediate system 14 to Intermediate system (IS-IS) routing protocol and security gaps 15 according to the KARP Design Guide. This document also provides 16 specific requirements to address the gaps with both manual and auto 17 key management protocols. 19 Status of this Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at http://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 This Internet-Draft will expire on April 25, 2013. 36 Copyright Notice 38 Copyright (c) 2012 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (http://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with respect 46 to this document. Code Components extracted from this document must 47 include Simplified BSD License text as described in Section 4.e of 48 the Trust Legal Provisions and are provided without warranty as 49 described in the Simplified BSD License. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 54 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 55 1.2. Acronyms . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 2. Current State . . . . . . . . . . . . . . . . . . . . . . . . 4 57 2.1. Key Usage . . . . . . . . . . . . . . . . . . . . . . . . 4 58 2.1.1. Sub network Independent . . . . . . . . . . . . . . . 4 59 2.1.2. Sub network dependent . . . . . . . . . . . . . . . . 5 60 2.2. Key Agility . . . . . . . . . . . . . . . . . . . . . . . 5 61 2.3. Security Issues . . . . . . . . . . . . . . . . . . . . . 5 62 2.3.1. Replay Attacks . . . . . . . . . . . . . . . . . . . . 6 63 2.3.1.1. Current Recovery mechanism for LSPs . . . . . . . 7 64 2.3.2. Spoofing Attacks . . . . . . . . . . . . . . . . . . . 7 65 2.3.3. DoS Attacks . . . . . . . . . . . . . . . . . . . . . 8 66 3. Gap Analysis and Security Requirements . . . . . . . . . . . . 8 67 3.1. Manual Key Management . . . . . . . . . . . . . . . . . . 8 68 3.2. Key Management Protocols . . . . . . . . . . . . . . . . . 10 69 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 70 5. Security Considerations . . . . . . . . . . . . . . . . . . . 10 71 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11 72 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 73 7.1. Normative References . . . . . . . . . . . . . . . . . . . 11 74 7.2. Informative References . . . . . . . . . . . . . . . . . . 11 75 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12 77 1. Introduction 79 This document analyzes the current state of Intermediate system to 80 Intermediate system (IS-IS) protocol according to the requirements 81 set forth in [RFC6518] for both manual and key management protocols. 83 With currently published work, IS-IS meets some of the requirements 84 expected from a manually keyed routing protocol. Integrity 85 protection is expanded with more cryptographic algorithms and also 86 limited algorithm agility (HMAC-SHA family) is provided with 87 [RFC5310]. Basic form of Intra-connection re-keying capability is 88 provided by the specification [RFC5310] with some gaps as explained 89 in Section 3. 91 This draft summarizes the current state of cryptographic key usage in 92 IS-IS protocol and several previous efforts to analyze IS-IS 93 security. This includes base IS-IS specification [RFC1195], 94 [RFC5304], [RFC5310] and the OPSEC working group document [RFC6039]. 95 Authors would like to acknowledge all the previous work done in the 96 above documents. 98 This document also analyzes applicability of various threats as 99 described in [ietf-karp-threats-reqs] to IS-IS, lists gaps and 100 provides specific recommendations to thwart the applicable threats 101 for both manual keying and for auto key management mechanisms. 103 1.1. Requirements Language 105 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 106 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 107 document are to be interpreted as described in RFC 2119 [RFC2119]. 109 1.2. Acronyms 111 IGP - Interior Gateway Protocol. 113 IIH - IS-IS HELLO PDU. 115 IPv4 - Internet Protocol version 4. 117 KMP - Key Management Protocol (auto key management). 119 LSP - IS-IS Link State PDU. 121 MKM - Manual Key management Protocols. 123 NONCE - Number Once. 125 SA - Security Association. 127 SNP - Sequence number PDU. 129 2. Current State 131 IS-IS is specified in International Standards Organization (ISO) 132 10589, with extensions to support Internet Protocol version 4 (IPv4) 133 described in [RFC1195]. The specification includes an authentication 134 mechanism that allows for any authentication algorithm and also 135 specifies the algorithm for clear text passwords. Further [RFC5304] 136 extends the authentication mechanism to work with HMAC-MD5 and also 137 modifies the base protocol for more effectiveness. [RFC5310] 138 provides algorithm agility, with new generic crypto authentication 139 mechanism (CRYPTO_AUTH) for IS-IS. The CRYPTO_AUTH also introduces 140 Key ID mechanism that map to unique IS-IS Security Associations 141 (SAs). 143 The following sections describe the current authentication key usage 144 for various IS-IS messages, current key change methodologies and the 145 various potential security threats. 147 2.1. Key Usage 149 IS-IS can be provisioned with a per interface, peer-to-peer key for 150 IS-IS HELLO PDUs (IIH) and a group key for Link State PDUs (LSPs) and 151 Sequence number PDUs (SNPs). If provisioned, IIH packets potentially 152 can use the same group key used for LSPs and SNPs. 154 2.1.1. Sub network Independent 156 Link State PDUs, Complete and partial Sequence Number PDUs come under 157 Sub network Independent messages. For protecting Level-1 SNPs and 158 Level-1 LSPs, provisioned Area Authentication key is used. Level-2 159 SNPs as well as Level-2 LSPs use the provisioned domain 160 authentication key. 162 Since authentication is performed on the LSPs transmitted by an IS, 163 rather than on the LSP packets transmitted to a specific neighbor, it 164 is implied that all the ISes within a single flooding domain must be 165 configured with the same key in order for authentication to work 166 correctly. This is also true for SNP packets, though they are 167 limited to link local scope in broadcast networks. 169 If multiple instances share the circuits as specified in [I-D.ietf- 170 isis-mi], instance specific authentication credentials can be used to 171 protect the LSPs and SNPs with in an area or domain. It is important 172 to note, [I-D.ietf-isis-mi] also allows usage of topology specific 173 authentication credentials with in an instance for the LSPs and SNPs. 175 2.1.2. Sub network dependent 177 IS-IS HELLO PDUs use the Link Level Authentication key, which may be 178 different from that of Link State PDUs (LSPs) and Sequence number 179 PDUs (SNPs). This could be particularly true for point-to-point 180 links. In broadcast networks it is possible to provision the same 181 common key used for LSPs and SNPs, to protect IIH messages. This 182 allows neighbor discovery and adjacency formation with more than one 183 neighbor on the same physical interface. 185 2.2. Key Agility 187 Key roll over without effecting the routing protocols operation in 188 general and IS-IS in particular, is necessary for effective key 189 management protocol integration. 191 Current HMAC-MD5 crypto authentication as defined in [RFC5304], 192 suggests a transition mode, so that ISes use a set of keys when 193 verifying the authentication value, to allow key changes. This 194 approach will allow changing the authentication key manually without 195 bringing down the adjacency and without dropping any control packet. 196 But, this can increase the load on control plane for the key 197 transition duration as each control packet may have to be verified by 198 more than one key and also allows to mount a potential Denial of 199 Service (DoS) attack in the transition duration. 201 The above situation is improved with the introduction of Key ID 202 mechanism as defined in [RFC5310]. With this, the receiver 203 determines the active security association (SA) by looking at the Key 204 ID field in the incoming PDU and need not try with other keys, when 205 the integrity check or digest verification fails. But, neither Key 206 co-ordination across the group nor exact key change mechanism is 207 clearly defined. [RFC5310] says: " Normally, an implementation would 208 allow the network operator to configure a set of keys in a key chain, 209 with each key in the chain having a fixed lifetime. The actual 210 operation of these mechanisms is outside the scope of this document." 212 2.3. Security Issues 214 The following section analyzes various security threats possible, in 215 the current state for IS-IS protocol. 217 2.3.1. Replay Attacks 219 Replaying a captured protocol packet to cause damage is a common 220 threat for any protocol. Securing the packet with cryptographic 221 authentication information alone can not mitigate this threat 222 completely. Though this problem is more prevalent in broadcast 223 networks it is important to note, most of the IGP deployments use 224 P2P-over-lan [RFC5309], which makes an adversary replay 'easier' than 225 the traditional P2P networks 227 In intra-session replay attacks a secured protocol packet of the 228 current session is replayed, can cause damage, if there is no other 229 mechanism to confirm this is a replay packet. In inter-session 230 replay attacks, captured packet from one of the previous session can 231 be replayed to cause the damage. IS-IS packets are vulnerable to 232 both these attacks, as there is no sequence number verification for 233 IIH packets and SNP packets. Also with current manual key management 234 periodic key changes across the group are done rarely. Thus the 235 intra-connection and inter-connection replay requirements are not 236 met. 238 IS-IS specifies the use of the HMAC-MD5 [RFC5304] and HMAC-SHA-1 239 family in [RFC5310], to protect IS-IS packets. An adversary could 240 replay old IIHs or replay old SNPs that would cause churn in the 241 network or bring down the adjacencies. 243 1. At the time of adjacency bring up an IS sends IIH packet with 244 empty neighbor list (TLV 6) and with the authentication 245 information as per provisioned authentication mechanism. If this 246 packet is replayed later on the broadcast network, all ISes in 247 the broadcast network can bounce the adjacency to create a huge 248 churn in the network. 250 2. Today LSPs have intra-session replay protection as LSP header 251 contains 32-bit sequence number which is verified for every 252 received packet against the local LSP database. On the other 253 hand, if a node in the network is out of service (is undergoing 254 some sort of high availability condition, or an upgrade) for more 255 than LSP refresh time and the rest of the network ages out the 256 LSPs of the node under consideration, an adversary can 257 potentially plunge in inter-session replay attacks in the 258 network. If the key is not changed in the above circumstances, 259 attack can be launched by replaying a old LSP with higher 260 sequence number and fewer prefixes or fewer adjacencies. This 261 may force the receiver to accept and remove the routes from the 262 routing table, which eventually causes traffic disruption to 263 those prefixes. However, as per the IS-IS specification there is 264 a built-in recovery mechanism for LSPs from inter-session replay 265 attacks and it is further discussed in Section 2.3.1.1. 267 3. In any IS-IS network (broadcast or otherwise), if a old and an 268 empty Complete Sequence Number packet (CSNP) is replayed this can 269 cause LSP flood in the network. Similarly a replayed Partial 270 Sequence Number packet (PSNP) can cause LSP flood in the 271 broadcast network. 273 2.3.1.1. Current Recovery mechanism for LSPs 275 In the event of inter-session replay attack by an adversary, as LSP 276 with higher sequence number gets accepted, it also gets propagated 277 until it reaches the originating node of the LSP. The originator 278 recognizes the LSP is "newer" than in the local database and this 279 prompts the originator to flood a newer version of the LSP with 280 higher sequence number than the received. This newer version can 281 potentially replace any versions of the replayed LSP which may exist 282 in the network. 284 But in the above process, depending on where in the network the 285 replay is initiated, how quick the nodes in the network react to the 286 replayed LSP and also how different the content in the accepted LSP 287 determines the damage caused by the replayed LSP. 289 2.3.2. Spoofing Attacks 291 IS-IS shares the same key between all neighbors in an area or in a 292 domain to protect the LSP, SNP packets and in broadcast networks even 293 IIH packets. False advertisement by a router is not within scope of 294 the KARP work. However, given the wide sharing of keys as described 295 above, there is a significant risk that an attacker can compromise a 296 key from one device, and use it to falsely participate in the 297 routing, possibly even in a very separate part of the network. 299 If the same underlying topology is shared across multiple instances 300 to transport routing/application information as defined in [I-D.ietf- 301 isis-mi], it is necessary to use different authentication credentials 302 for different instances. In this connection, based on the deployment 303 considerations, if certain topologies in a particular IS-IS instance 304 require more protection from spoofing attacks and less exposure, 305 topology specific authentication credentials can be used for LSPs and 306 SNPs as facilitated in [I-D.ietf-isis-mi]. 308 Currently possession of the key it self is used as authentication 309 check and there is no identity check done separately. Spoofing 310 occurs when an illegitimate device assumes the identity of a 311 legitimate one. An attacker can use spoofing as a means for 312 launching various types of attacks. For example: 314 1. The attacker can send out unrealistic routing information that 315 might cause the disruption of network services such as block 316 holes. 318 2. A rogue system having access to the common key used to protect 319 the LSP, can send an LSP, setting the Remaining Lifetime field to 320 zero, and flooding it thereby initiating a purge. Subsequently, 321 this also can cause the sequence number of all the LSPs to 322 increase quickly to max out the sequence number space, which can 323 cause an IS to shut down for MaxAge + ZeroAgeLifetime period to 324 allow the old LSPs to age out in other ISes of the same flooding 325 domain. 327 2.3.3. DoS Attacks 329 Denial-of-service (DoS) attacks using the authentication mechanism is 330 possible and an attacker can send packets which can overwhelm the 331 security mechanism itself. An example is initiating an overwhelming 332 load of spoofed but integrity protected protocol packets, so that the 333 receiver needs to process the integrity check, only to discard the 334 packet. This can cause significant CPU usage. DoS attacks are not 335 generally preventable with in the routing protocol. As the attackers 336 are often remote, the DoS attacks are more damaging to area-scoped or 337 domain-scoped packet receivers than link-local scoped packet 338 receivers. 340 3. Gap Analysis and Security Requirements 342 This section outlines the differences between the current state of 343 the IS-IS routing protocol and the desired state as specified in KARP 344 Design Guidelines [RFC6518]. The section focuses on where IS-IS 345 protocol fails to meet general requirements as specified in the 346 threats and requirements document. 348 This section also describes security requirements that should be met 349 by IS-IS implementations that are secured by manual as well as auto 350 key management protocols. 352 3.1. Manual Key Management 354 1. With CRYPTO_AUTH specification [RFC5310], IS-IS packets can be 355 protected with HMAC-SHA family of cryptographic algorithms. The 356 specification provides the limited algorithm agility (SHA 357 family). By using Key IDs, it also conceals the algorithm 358 information from the protected control messages. 360 2. Even though both intra and inter session replay attacks are best 361 prevented by deploying key management protocols with frequent key 362 change capability, basic constructs for sequence number should be 363 there in the protocol messages. So, some basic or extended 364 sequence number mechanism should be in place to protect IIH 365 packets and SNP packets. The sequence number should be increased 366 for each protocol packet. This allows mitigation of some of the 367 replay threats as mentioned in Section 2.3.1. 369 3. Any common key mechanism with keys shared across a group of 370 routers is susceptible to spoofing attacks caused by a malicious 371 router. Separate authentication check (apart from the integrity 372 check to verify the digest) with digital signatures as described 373 in [RFC2154], can effectively nullify this attack. But this 374 approach was never deployed and one can only assume due to 375 operational considerations at that time. The alternative 376 approach to thwart this threat would be by using the keys from 377 the group key management protocol. As the group key(s) are 378 generated by authenticating the member ISes in the group first, 379 and then periodically rekeyed, per packet identity or 380 authentication check may not be needed. 382 4. In general DoS attacks may not be preventable with mechanism from 383 routing protocols itself. But some form of Admin controlled 384 lists (ACLs) at the forwarding plane can reduce the damage. 385 There are some other forms the DoS attacks common to any protocol 386 are not in scope as per the section 2.2 in [I-D.ietf-karp- 387 threats-reqs]. 389 As discussed in Section 2.2, though Key ID mechanism in [RFC5310] 390 helps, better key co-ordination mechanism for key roll over is 391 desirable even with manual key management. But, it fell short of 392 specifying exact mechanism other than using key chains. The specific 393 requirements: 395 a. Keys SHOULD be able to change without affecting the established 396 adjacency and even better without any control packet loss. 398 b. Keys SHOULD be able to change without effecting the protocol 399 operations, for example, LSP flooding should not be help for a 400 specific Key ID availability. 402 c. Any proposed mechanism SHOULD also be further incrementally 403 deployable with key management protocols. 405 3.2. Key Management Protocols 407 In broadcast deployments, the keys used for protecting IS-IS 408 protocols messages can, in particular, be group keys. A mechanism, 409 similar to as described in [I-D.weis-gdoi-mac-tek] can be used to 410 distribute group keys to a group of ISes in Level-1 area or Level-2 411 domain, using GDOI as specified in [RFC6407]. There are also similar 412 approaches with IKEv2 based group key management solutions, to 413 routing protocols as described in [I-D.yeung-g-ikev2] and 414 [I-D.hartman-karp-mrkmp]. 416 If a group key is used, the authentication granularity becomes group 417 membership of devices, not peer authentication between devices. 418 Group key management protocol deployed SHOULD be capable of 419 supporting rekeying support. 421 In some deployments, where IS-IS point-to-point (P2P) mode is used 422 for adjacency bring-up, sub network dependent messages (IIHs) can use 423 a different key shared between the two point-to-point peers, while 424 all other messages use a group key. When group keying mechanism is 425 deployed, even the P2P IIHs can be protected with the common group 426 keys. This approach facilitates one key management mechanism instead 427 of both pair-wise keying and group keying protocols to be deployed 428 together. If same circuits are shared across multiple instances, the 429 granularity of the group can become per instance for IIHs and per 430 instance/topology for LSPs and SNPs as specified in the [I-D.ietf- 431 isis-mi]. 433 Effective key change capability with in the routing protocol which 434 allows key roll over without impacting the routing protocol 435 operation, is one of the requirements for deploying any group key 436 mechanism. Once such mechanism is in place with deployment of group 437 key management protocol, IS-IS can be protected from various threats 438 not limited to intra and inter session replay attacks and spoofing 439 attacks. 441 Specific use of crypto tables [I-D.ietf-karp-crypto-key-table] should 442 be defined for IS-IS protocol. 444 4. IANA Considerations 446 This document defines no new namespaces. 448 5. Security Considerations 450 This document is mostly about security considerations of IS-IS 451 protocol, lists potential threats and security requirements for 452 solving those threats. This document does not introduce any new 453 security threats for IS-IS protocol. For more detailed security 454 considerations please refer the Security Considerations section of 455 the KARP Design Guide [RFC6518] document as well as KARP threat 456 document [I-D.ietf-karp-threats-reqs] 458 6. Acknowledgements 460 Authors would like to thank Joel Halpern for encouraging us to come 461 up with this document and giving valuable review comments. Authors 462 would like to acknowledge Naiming Shen for reviewing and providing 463 feedback on this document. 465 7. References 467 7.1. Normative References 469 [RFC1195] Callon, R., "Use of OSI IS-IS for routing in TCP/IP and 470 dual environments", RFC 1195, December 1990. 472 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 473 Requirement Levels", BCP 14, RFC 2119, March 1997. 475 [RFC5304] Li, T. and R. Atkinson, "IS-IS Cryptographic 476 Authentication", RFC 5304, October 2008. 478 [RFC5310] Bhatia, M., Manral, V., Li, T., Atkinson, R., White, R., 479 and M. Fanto, "IS-IS Generic Cryptographic 480 Authentication", RFC 5310, February 2009. 482 7.2. Informative References 484 [I-D.hartman-karp-mrkmp] 485 Hartman, S., Zhang, D., and G. Lebovitz, "Multicast Router 486 Key Management Protocol (MaRK)", 487 draft-hartman-karp-mrkmp-05 (work in progress), 488 September 2012. 490 [I-D.ietf-isis-mi] 491 Previdi, S., Ginsberg, L., Shand, M., Roy, A., and D. 492 Ward, "IS-IS Multi-Instance", draft-ietf-isis-mi-08 (work 493 in progress), October 2012. 495 [I-D.ietf-karp-crypto-key-table] 496 Housley, R., Polk, T., Hartman, S., and D. Zhang, 497 "Database of Long-Lived Symmetric Cryptographic Keys", 498 draft-ietf-karp-crypto-key-table-03 (work in progress), 499 June 2012. 501 [I-D.ietf-karp-threats-reqs] 502 Lebovitz, G. and M. Bhatia, "Keying and Authentication for 503 Routing Protocols (KARP) Overview, Threats, and 504 Requirements", draft-ietf-karp-threats-reqs-06 (work in 505 progress), September 2012. 507 [I-D.weis-gdoi-mac-tek] 508 Weis, B. and S. Rowles, "GDOI Generic Message 509 Authentication Code Policy", draft-weis-gdoi-mac-tek-03 510 (work in progress), September 2011. 512 [I-D.yeung-g-ikev2] 513 Rowles, S., Yeung, A., Tran, P., and Y. Nir, "Group Key 514 Management using IKEv2", draft-yeung-g-ikev2-05 (work in 515 progress), October 2012. 517 [RFC2154] Murphy, S., Badger, M., and B. Wellington, "OSPF with 518 Digital Signatures", RFC 2154, June 1997. 520 [RFC4107] Bellovin, S. and R. Housley, "Guidelines for Cryptographic 521 Key Management", BCP 107, RFC 4107, June 2005. 523 [RFC5309] Shen, N. and A. Zinin, "Point-to-Point Operation over LAN 524 in Link State Routing Protocols", RFC 5309, October 2008. 526 [RFC6039] Manral, V., Bhatia, M., Jaeggli, J., and R. White, "Issues 527 with Existing Cryptographic Protection Methods for Routing 528 Protocols", RFC 6039, October 2010. 530 [RFC6407] Weis, B., Rowles, S., and T. Hardjono, "The Group Domain 531 of Interpretation", RFC 6407, October 2011. 533 [RFC6518] Lebovitz, G. and M. Bhatia, "Keying and Authentication for 534 Routing Protocols (KARP) Design Guidelines", RFC 6518, 535 February 2012. 537 Authors' Addresses 539 Uma Chunduri 540 Ericsson Inc., 541 300 Holger Way, 542 San Jose, California 95134 543 USA 545 Phone: 408 750-5678 546 Email: uma.chunduri@ericsson.com 548 Albert Tian 549 Ericsson Inc., 550 300 Holger Way, 551 San Jose, California 95134 552 USA 554 Phone: 408 750-5210 555 Email: albert.tian@ericsson.com 557 Wenhu Lu 558 Ericsson Inc., 559 300 Holger Way, 560 San Jose, California 95134 561 USA 563 Email: wenhu.lu@ericsson.com