idnits 2.17.1 draft-chunduri-tcp-ao-extensions-for-karp-kmp-00.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 == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'SHOULD not' in this paragraph: KMP negotiated authentication algorithm and optionally life time for traffic keys for each session, need to be populated in MKT. When the life time expires, these traffic keys and hence the MKT SHOULD not be used to protect the underlying TCP session any more. Implementations SHOULD pro-actively rekey new traffic keys before the life time expiry of current traffic keys. -- The document date (October 24, 2011) is 4567 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'I-D.ietf-idr-bgp-multisession' is defined on line 466, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-karp-design-guide' is defined on line 471, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-karp-threats-reqs' is defined on line 477, but no explicit reference was found in the text == Unused Reference: 'I-D.touch-tcp-ao-nat' is defined on line 484, but no explicit reference was found in the text == Unused Reference: 'RFC4107' is defined on line 488, but no explicit reference was found in the text == Unused Reference: 'RFC5926' is defined on line 495, but no explicit reference was found in the text == Outdated reference: A later version (-07) exists of draft-ietf-idr-bgp-multisession-06 == Outdated reference: A later version (-10) exists of draft-ietf-karp-design-guide-02 == Outdated reference: A later version (-07) exists of draft-ietf-karp-threats-reqs-03 == Outdated reference: A later version (-05) exists of draft-touch-tcp-ao-nat-02 -- Obsolete informational reference (is this intentional?): RFC 5996 (Obsoleted by RFC 7296) Summary: 0 errors (**), 0 flaws (~~), 12 warnings (==), 2 comments (--). 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: Standards Track Ericsson Inc., 5 Expires: April 26, 2012 October 24, 2011 7 TCP-AO extensions for KARP-KMP 8 draft-chunduri-tcp-ao-extensions-for-karp-kmp-00 10 Abstract 12 This document discusses the possible extensions for TCP 13 Authentication Option (TCP-AO) to better integrate and maximize the 14 benefits, when deployed with Key Management Protocols (KMPs). TCP-AO 15 as defined in RFC5925 can obtain master key from KMP and uses a Key 16 Derivation Function (KDF) to generate traffic keys to protect the TCP 17 sessions. In this mode, not all the benefits from the KMP can be 18 realized. This document introduces an alternative approach for 19 TCP-AO that allows TCP-AO to realize all the operational and security 20 benefits from the deployed KMP. 22 Status of this Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at http://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on April 26, 2012. 39 Copyright Notice 41 Copyright (c) 2011 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (http://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 58 1.2. Acronyms . . . . . . . . . . . . . . . . . . . . . . . . . 3 59 2. Current Approach: Obtaining Master Key from KMPs . . . . . . . 4 60 3. Limitations of the current approach with KMPs . . . . . . . . 4 61 3.1. Operational (non-security) Limitations . . . . . . . . . . 4 62 3.1.1. Parameter Negotiation . . . . . . . . . . . . . . . . 5 63 3.1.2. Re-authentication . . . . . . . . . . . . . . . . . . 5 64 3.2. Security Limitations . . . . . . . . . . . . . . . . . . . 5 65 3.2.1. Limited Randomness . . . . . . . . . . . . . . . . . . 5 66 3.2.2. Exposure and re-use of Master Key . . . . . . . . . . 6 67 4. Obtaining Traffic Keys from KMPs . . . . . . . . . . . . . . . 6 68 5. Changes required to use Traffic Keys from KMP . . . . . . . . 8 69 5.1. Key Trigger . . . . . . . . . . . . . . . . . . . . . . . 9 70 5.2. Authentication Algo and Traffic Keys Life time . . . . . . 9 71 5.3. Impact on application process restart or reboot . . . . . 9 72 6. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 10 73 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 74 8. Security Considerations . . . . . . . . . . . . . . . . . . . 10 75 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10 76 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 77 10.1. Normative References . . . . . . . . . . . . . . . . . . . 11 78 10.2. Informative References . . . . . . . . . . . . . . . . . . 11 79 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12 81 1. Introduction 83 TCP-AO [RFC5925] is a generic mechanism to protect tcp segments for 84 long-lived BGP/LDP sessions, BGP route reflectors and any other 85 client-server TCP applications. 87 Since TCP-AO obtains master key from KMP and uses a specific Key 88 Derivation Function (KDF) to generate traffic keys for TCP sessions, 89 it will not be able to realize all the non-security as well as 90 security benefits from a well rounded KMP. This is due to the common 91 KDF interface as defined in TCP-AO, even with the KMP usage. This 92 document discusses the potential restrictions with TCP-AO in 93 Section 3, when deployed with Key Management Protocols (KMPs) and 94 harmonize the proposed approach in Section 4 to minimize changes to 95 both KMP and application/routing protocols. 97 To be specific this document gives capability to negotiate and apply 98 session specific parameters with TCP-AO, when multiple TCP session 99 between the same endpoints are opened as described in [ietf-idr-bgp- 100 multisession]. 102 Also with the proposed approach, TCP sessions can be protected with 103 stronger and more uniformly random traffic keys with out being 104 limited by the session specific parameter randomness. Recent 105 discussions on NAT traversal is likely to put more restrictions on 106 KDF inputs for traffic key generation. Lastly, this document analyze 107 the consequences of out-of-band master key compromise, generated by 108 KMP and how this leads to session compromise when the same more 109 exposed master key is re-used for traffic key generation for multiple 110 sessions. 112 A simple solution that allows TCP-AO to directly obtain traffic keys, 113 negotiated key life time, authentication algorithm from KMPs in 114 Section 4 is discussed. The proposed solution is intended to 115 minimize the changes required in application protocols, KMPs and 116 allows seamless integration with TCP-AO. In the end, the cost of 117 these extensions is discussed in Section 5. 119 1.1. Requirements Language 121 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 122 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 123 document are to be interpreted as described in RFC 2119 [RFC2119]. 125 1.2. Acronyms 126 AKM - Auto Key Management 128 DIP - Destination IP Address 130 EAP - Extensible Authentication Protocol 132 IKE - Internet Key Exchange 134 ISN - Initial Sequence Number 136 KDF - Key Derivation Function 138 KMP - Key Management Protocol (auto key management) 140 MKM - Manual Key management Protocols 142 MKT - Master Key Tuple 144 MSK - Master Session Key 146 NONCE - Number Once 148 SIP - Source IP Address 150 TCP-AO - TCP Authentication Option 152 2. Current Approach: Obtaining Master Key from KMPs 154 When the number of connections increase, KMPs provide natural way to 155 manage, rekey and distribute the keys to all the concerned systems in 156 the network. Also per KARP WG and [ietf-karp-design-guide] KMPs are 157 the preferred choice for routing protocols. Currently in TCP-AO 158 [RFC5925], both manual and auto key management protocols populate the 159 shared master key and other associated parameters in the MKT. Then 160 using pre-defined KDFs in MKT and session specific parameters, 161 traffic keys are generated to protect the TCP session. 163 3. Limitations of the current approach with KMPs 165 This section discusses the potential limitations to current TCP-AO 166 standard when deployed with key management protocols. 168 3.1. Operational (non-security) Limitations 169 3.1.1. Parameter Negotiation 171 Sec 5.3 TCP-AO [RFC5925] states - "TCP-AO does not provide a 172 mechanism for traffic key negotiation or parameter negotiation (MAC 173 algorithm, length, or use of TCP-AO on a connection), or for 174 coordinating rekeying during a connection. We assume out-of-band 175 mechanisms for MKT establishment, parameter negotiation, and 176 rekeying." But even with out-of-band mechanisms for MKT 177 establishment, if MKT is re-used to protect multiple sessions as 178 possible and specified in [ietf-idr-bgp-multisession], parameter 179 negotiation/configuration (E.g. rekey lifetime) specific to 180 particular session is not possible. 182 3.1.2. Re-authentication 184 For long-lived TCP session per sec 5.3.2 and sec 6 TCP-AO [RFC5925], 185 to change the traffic keys new MKT is required, in other words new 186 shared master key must be negotiated. This approach could be 187 inefficient because master key negotiation is not only 188 computationally expensive and also need more message exchanges to do 189 full re-authentication when there is no concern in the long term 190 credentials of the parties involved. What is needed here is only re- 191 negotiation of the traffic key. 193 The above claim assumes master key defined in TCP-AO is similar to 194 the master shared key in KMP (E.g. authenticated DH shared secret in 195 IKE) which is used to generated traffic keys. But, one can re-define 196 the KMP specification to one of the traffic keys of the KMP as TCP-AO 197 master key and this require changes to the established KMP in 198 question. 200 3.2. Security Limitations 202 3.2.1. Limited Randomness 204 Sec 6 of [touch-tcp-ao-nat], discusses the randomness surrounding KDF 205 inputs for generating traffic keys and in some cases traffic key 206 randomness purely dominated by randomness of ISNs alone. As pointed 207 out, this can be potential issue if multiple traffic keys are derived 208 from the same MKT/master key and freshness of the traffic keys can't 209 be guaranteed. KMPs e.g., [RFC5996] have even further restrictions 210 on the length and quality of the random number to be used for key 211 generations. 213 Section 2.10 of RFC5996 [RFC5996] says "...These nonces are used to 214 add freshness to the key derivation technique used to obtain keys for 215 Child SA, and to ensure creation of strong pseudorandom bits from the 216 Diffie-Hellman key. Nonces used in IKEv2 MUST be randomly chosen, 217 MUST be at least 128 bits in size, and MUST be at least half the key 218 size of the negotiated pseudorandom function (PRF)...". It is not 219 possible to meet the above requirements of KMP, if traffic keys 220 generated as specified in Section 3.2 of TCP-AO [RFC5925]. 222 3.2.2. Exposure and re-use of Master Key 224 Sec 3.1 TCP-AO [RFC5925], specifies MKTs with all parameters 225 including master key are provisioned manually or by external 226 protocols. As per TCP-AO, even with KMP deployment traffic key 227 parameters (Source/destination address, ports and ISNs) are exchanged 228 in plain (un-encrypted) as part of the TCP control traffic. Then 229 using shared master key in MKT, unique traffic keys are derived for 230 all the sessions between the same end points and also for new traffic 231 keys for any restarted session as specified in Sec 5.3.1 TCP-AO 232 [RFC5925], between the endpoints. 234 The problematic part here is keying material to generate the traffic 235 keys are exchanged with no privacy. Any re-use of master key for 236 long-lived sessions give attacker access to all the traffic keys 237 should out-of-band master key compromise happen because of extraction 238 from a router or by a threat as specified in [ietf-karp-threats-reqs] 239 from terminated/turned employee. Therefore with the existing 240 approach, an attacker with compromised master key can easily derive 241 the traffic keys used for protecting all current and future TCP 242 sessions. 244 4. Obtaining Traffic Keys from KMPs 246 This document proposes and analyzes a direct way to obtain the 247 traffic keys and the negotiated life time of these keys, 248 authentication algorithm from KMPs with no additional KDF, when KMP 249 is used. 251 In other words, when TCP-AO is used with KMPs, traffic keys MUST be 252 generated and populated in MKTs by the KMPs and SHALL be used 253 directly to protect TCP sessions without going through additional 254 KDF. Instead of shared master key, MKTs will have KMP negotiated 255 traffic keys on the already established secure channel with the peer. 256 This approach inherently immune to replay attacks as new crypto 257 quality NONCE is used every time new traffic key pair is negotiated. 259 Manual key deployments will continue to have the existing mechanism 260 of having master key in MKT, as suggested in current TCP-AO standard. 262 By letting Key Management Protocols generate the traffic keys, TCP-AO 263 can inherit all the properties of KMP. It is important to note all 264 the perceived advantages can be realized by the proposed approach, 265 only if right KMP with appropriate feature set is chosen. To 266 summarize the benefits: 268 o Granular Parameter Negotiation 269 More granular negotiation of session specific parameters like 270 crypto algorithm to protect the TCP session and life time of 271 the traffic keys for particular session is possible for all the 272 sessions shared by the same MKT/master key with the proposed 273 approach. 275 o Re-keying 276 With the proposed approach, TCP-AO can benefit from more 277 efficient use of rekeying as opposed to re-authentication, 278 support provided by most KMPs with out re-defining master key 279 in all KMPs (as being done currently for IKEv2 based KMP in 280 KARP WG). If any existing protected session traffic key has to 281 be changed, this can be done with out re-doing expensive 282 negotiation of new master key through full authentication. 284 o Stronger traffic keys 285 With the proposed approach, it is possible to generate stronger 286 and uniformly random traffic keys with out being limited by 287 ISNs randomness. This is achieved by generating the NONCE 288 meeting all requirements imposed by deployed KMP, on length of 289 the random numbers and the cryptographic quality of the random 290 numbers. 292 o Secure traffic key material exchange 293 KMPs in general, provide separation from shared master key and 294 other keying materials used for integrity protection and 295 encryption of the KMP message exchanges i.e., all KMP exchanges 296 use the secure and private channel already established with the 297 peer. If traffic keys are generated by KMPs by exchanging 298 NONCE and session specific parameters securely, there is no 299 exposure of mutually authenticated shared master key in MKTs. 300 With this any out-of-band traffic key compromise is severely 301 limited to the current traffic key duration and traffic keys 302 negotiated for all new connections and restarted connections 303 for the same peer will continue to be secure and unaffected. 305 Authors recognize, it is not possible to completely mitigate 306 the threat of terminated/turned employee as specified in [ietf- 307 karp-threats-reqs]. This threat is abbreviated just by using 308 KMP instead of manual keying method. This can even be further 309 reduced by exchanging the traffic key material on secure 310 channel with the proposed approach. It is important to note in 311 this context, some KMPs for e.g., [RFC5996] can include extra 312 DH key exchange in the traffic key computation by completely 313 not relying on the initial master key or to further secure the 314 generation of traffic keys. 316 Right KMP selection for particular deployment of TCP-AO and the type 317 of mutual authentication methods used for getting shared master key 318 by KMP is beyond the scope of this document. 320 5. Changes required to use Traffic Keys from KMP 322 The main cost of this approach is changes needed to the current 323 TCP-AO standard with KMP and keeping manual key management still 324 intact. In summary this can be achieved by introducing the following 325 changes: 327 a. Two new fields KMP_send_key and KMP_receive_key will be added to 328 MKT. They will be populated with KMP generated traffic keys. 329 These new fields are initialized to all zeros when KMP is not in 330 use. Since "Master Key" field is not used at the same time as 331 KMP_send_key and KMP_receive_key, some optimization is possible 332 in implementation. 334 b. A new KDF function, KDF_DIRECT, will be introduced. With this 335 new KDF, there will be no key computation for the following keys 336 as defined in Sec 3.2 of TCP-AO [RFC5925], rather traffic keys 337 will be directly assigned with the KMP supplied keys as: 339 1. Send_SYN_traffic_key = KMP_send_key 341 2. Send_other_traffic_key = KMP_send_key 343 3. Receive_SYN_traffic_key = KMP_receive_key 345 4. Receive_other_traffic_key = KMP_receive_key 347 c. When MKT is created with KDF_DIRECT, application can also 348 provision the configured authentication algorithms and configured 349 key life time in the MKT. 351 d. Sec 3.1 of TCP-AO [RFC5925], clearly mentions that, it does not 352 specify how MKTs are created by users or processes. One way this 353 can be achieved is by triggering the KMP with provisioned 354 parameters in the MKT to get the traffic keys from KMP. This is 355 applicable to brand new connections, restarted connections, as 356 well as parallel connections between the peers. Session specific 357 parameters need to be part of the trigger when new set of traffic 358 keys to protect the session is requested. 360 e. A new field KMP_key_lifetime will be added to MKT. This will be 361 populated with KMP negotiated life time of the traffic key. 363 f. A new field KMP_auth_algo will be added to MKT. This will be 364 populated with KMP negotiated authentication algorithm for 365 protecting the TCP session. 367 g. There is no change in MKT properties and Per-Connection TCP-AO 368 Parameters. However, when KDF_DIRECT is used, we recommend each 369 MKT SHALL correspond to only one TCP connection through the 370 proper use of TCP connection identifier in the MKT. 372 The above is an attempt to summarize the brief list of changes with 373 the approach and this section will be revisited further. 375 5.1. Key Trigger 377 When the first SYN packet on the session is initiated, a trigger to 378 negotiate the session specific parameters with all provisioned 379 authentication algorithms and optionally key lifetime SHOULD be given 380 to KMP. Trigger may also be needed at the time of rekeying any 381 particular session. This approach minimizes the changes at 382 application/routing protocol to the point where these just need to 383 create the MKT in TCP-AO with all configured parameters. 385 5.2. Authentication Algo and Traffic Keys Life time 387 KMP negotiated authentication algorithm and optionally life time for 388 traffic keys for each session, need to be populated in MKT. When the 389 life time expires, these traffic keys and hence the MKT SHOULD not be 390 used to protect the underlying TCP session any more. Implementations 391 SHOULD pro-actively rekey new traffic keys before the life time 392 expiry of current traffic keys. 394 5.3. Impact on application process restart or reboot 396 With the proposed approach, there will be a delay in getting the 397 traffic keys from KMP before sending the first protected TCP SYN 398 packet, when application process is restarted. For most of the KMPs 399 this can be a delay of one round trip and in some cases it could be 400 just little more than a single round trip. 402 In reboot scenario also for e.g., with BGP graceful restart [RFC4724] 403 - even though remote side old connections can be closed much quicker, 404 new traffic keys are required from KMP before initiating the new 405 connection. In contrary, if BGP is deployed with out graceful 406 restart procedure, one may not consider the extra KMP round trip 407 delay for initiating new connection as remote side TCP connection 408 will stay up till BGP/TCP level keep alive mechanisms clear the old 409 connection. 411 6. Conclusion 413 The primary goal of this document is to provide awareness of the 414 restrictions as specified in Section 3 for TCP-AO KMP deployments. 415 Today even with right KMP is deployed with TCP-AO [RFC5925] all the 416 benefits of KMPs are not realizable. Though all KMPs won't have the 417 ability to derive traffic keys securely and independent to shared 418 master key, with right KMP selection and with the proposed approach 419 TCP-AO can inherit all KMP properties to derive traffic keys securely 420 and more efficiently. 422 Also with the proposed approach integration of KMP, as well as 423 application protocols can be achieved with minimal changes at both 424 ends and expedites the adoption of the KMP. 426 7. IANA Considerations 428 This document defines no new namespaces. 430 8. Security Considerations 432 This document analyzes and proposes remedy for KMP generated master 433 key compromise as specified in Section 4. The proposed approach 434 further minimizes the threat from terminated/turned employee as 435 specified in [ietf-karp-threats-reqs] but still it is not possible to 436 completely avoid the same with certain KMPs. This document will not 437 introduce any new security concerns. 439 There could be other KMP specific security issues viz., compromise of 440 pre-shared key used for bootstrapping and authenticating the peer. 441 This could enable an adversary to effect MITM attacks on the link 442 where the compromised key is used. KMPs can mitigate this issue with 443 public key authentication of the peer or authentication with selected 444 EAP methods in conjunction with pre-shared keys. This document in no 445 way can address other security concerns specific to particular KMP in 446 question. 448 9. Acknowledgements 450 The authors would like to thank Joel Halpern for providing valuable 451 comments on the document and Ron Bonica for early discussions at 452 IETF81. 454 10. References 456 10.1. Normative References 458 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 459 Requirement Levels", BCP 14, RFC 2119, March 1997. 461 [RFC5925] Touch, J., Mankin, A., and R. Bonica, "The TCP 462 Authentication Option", RFC 5925, June 2010. 464 10.2. Informative References 466 [I-D.ietf-idr-bgp-multisession] 467 Scudder, J., Appanna, C., and I. Varlashkin, "Multisession 468 BGP", draft-ietf-idr-bgp-multisession-06 (work in 469 progress), March 2011. 471 [I-D.ietf-karp-design-guide] 472 Lebovitz, G. and M. Bhatia, "Keying and Authentication for 473 Routing Protocols (KARP) Design Guidelines", 474 draft-ietf-karp-design-guide-02 (work in progress), 475 March 2011. 477 [I-D.ietf-karp-threats-reqs] 478 Lebovitz, G., Bhatia, M., and R. White, "The Threat 479 Analysis and Requirements for Cryptographic Authentication 480 of Routing Protocols' Transports", 481 draft-ietf-karp-threats-reqs-03 (work in progress), 482 June 2011. 484 [I-D.touch-tcp-ao-nat] 485 Touch, J., "A TCP Authentication Option NAT Extension", 486 draft-touch-tcp-ao-nat-02 (work in progress), March 2011. 488 [RFC4107] Bellovin, S. and R. Housley, "Guidelines for Cryptographic 489 Key Management", BCP 107, RFC 4107, June 2005. 491 [RFC4724] Sangli, S., Chen, E., Fernando, R., Scudder, J., and Y. 492 Rekhter, "Graceful Restart Mechanism for BGP", RFC 4724, 493 January 2007. 495 [RFC5926] Lebovitz, G. and E. Rescorla, "Cryptographic Algorithms 496 for the TCP Authentication Option (TCP-AO)", RFC 5926, 497 June 2010. 499 [RFC5996] Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen, 500 "Internet Key Exchange Protocol Version 2 (IKEv2)", 501 RFC 5996, September 2010. 503 Authors' Addresses 505 Uma Chunduri 506 Ericsson Inc., 507 300 Holger Way, 508 San Jose, California 95134 509 USA 511 Phone: 408 750-5678 512 Email: uma.chunduri@ericsson.com 514 Albert Tian 515 Ericsson Inc., 516 300 Holger Way, 517 San Jose, California 95134 518 USA 520 Phone: 408 750-5210 521 Email: albert.tian@ericsson.com