idnits 2.17.1 draft-ietf-bfd-generic-crypto-auth-05.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 15, 2013) is 3846 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: 'RFC1321' is defined on line 502, but no explicit reference was found in the text == Outdated reference: A later version (-10) exists of draft-ietf-karp-crypto-key-table-08 Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group M. Bhatia 3 Internet-Draft Alcatel-Lucent 4 Intended status: Standards Track V. Manral 5 Expires: April 18, 2014 Hewlett-Packard Co. 6 D. Zhang 7 Huawei 8 October 15, 2013 10 BFD Generic Cryptographic Authentication 11 draft-ietf-bfd-generic-crypto-auth-05 13 Abstract 15 This document proposes an extension to Bidirectional Forwarding 16 Detection (BFD) to allow the use of arbitary cryptographic 17 authentication algorithms in addition to the already-documented 18 authentication schemes described in the base specification. This 19 document adds the basic infrastructure that is required for 20 supporting algorithm and key agility for BFD. 22 Requirements Language 24 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 25 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 26 document are to be interpreted as described in RFC 2119 [RFC2119]. 28 Status of This Memo 30 This Internet-Draft is submitted in full conformance with the 31 provisions of BCP 78 and BCP 79. 33 Internet-Drafts are working documents of the Internet Engineering 34 Task Force (IETF). Note that other groups may also distribute 35 working documents as Internet-Drafts. The list of current Internet- 36 Drafts is at http://datatracker.ietf.org/drafts/current/. 38 Internet-Drafts are draft documents valid for a maximum of six months 39 and may be updated, replaced, or obsoleted by other documents at any 40 time. It is inappropriate to use Internet-Drafts as reference 41 material or to cite them other than as "work in progress." 43 This Internet-Draft will expire on April 18, 2014. 45 Copyright Notice 47 Copyright (c) 2013 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents 52 (http://trustee.ietf.org/license-info) in effect on the date of 53 publication of this document. Please review these documents 54 carefully, as they describe your rights and restrictions with respect 55 to this document. Code Components extracted from this document must 56 include Simplified BSD License text as described in Section 4.e of 57 the Trust Legal Provisions and are provided without warranty as 58 described in the Simplified BSD License. 60 Table of Contents 62 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 63 2. BFD Security Association . . . . . . . . . . . . . . . . . . 4 64 3. Authentication Procedures . . . . . . . . . . . . . . . . . . 5 65 3.1. Authentication Types . . . . . . . . . . . . . . . . . . 5 66 3.2. Authentication Section Format . . . . . . . . . . . . . . 5 67 3.3. Procedures at the Sending Side . . . . . . . . . . . . . 6 68 3.4. Procedure at the Receiving Side . . . . . . . . . . . . . 7 69 3.5. Key Selection for BFD Packet Transmission . . . . . . . . 8 70 3.6. Replay Protection using Extended Sequence Numbers . . . . 9 71 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 72 5. Security Considerations . . . . . . . . . . . . . . . . . . . 10 73 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10 74 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 75 7.1. Normative References . . . . . . . . . . . . . . . . . . 10 76 7.2. Informative References . . . . . . . . . . . . . . . . . 11 77 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 79 1. Introduction 81 The base specification of bidirectional Forwarding Detection (BFD) 82 [RFC5880] defines five authentication schemes: Simple Password, Keyed 83 MD5 , Meticulous Keyed MD5, Keyed SHA-1, and Meticulous SHA-1. In 84 Simple Password, passwords are transferred in plaintext. An attacker 85 with physical access to the network can easily eavesdrop on the 86 password and compromise the security of the BFD packet exchanges. In 87 Keyed MD5 and Meticulous Keyed MD5, the BFD devices on the both sides 88 of a BFD session share a secret key which is used to generate a keyed 89 MD5 digest for each packet, and a monotonically increasing sequence 90 number scheme is used to prevent replay attacks. Keyed SHA-1 and 91 Meticulous SHA-1 modes are similar to MD5, and it uses SHA-1 instead 92 of MD5 to generate a digest for each packet. 94 A concern with existing authentication schemes of BFD is that the 95 security strength of the cryptographic algorithms adopted in the 96 schemes is relatively weak. Both the MD5 algorithm and the SHA-1 97 algorithm are known to be vulnerable to collision attacks. In 99 [MD5-attack] and [Dobb96a, Dobb96b], several methods of generating 100 hash collisions for some applications of MD5 are proposed. Similar 101 security vulnerabilities of SHA-1 are introduced in [SHA-1-attack1] 102 and [SHA-1-attack2]. It is therefore desired that BFD must support 103 newer algorithms that have not yet been broken. Additionally, the 104 transition mechanism from one algorithm to the other must be 105 seamless. 107 The other issue with the existing authentication schemes is the 108 vulnerability to replay attacks. In non-meticulous authentication 109 schemes, sequence numbers are only increased occasionally. This 110 behavior can be taken advantage of by an attacker to perform intra- 111 session replay attacks. In meticulous authentication schemes, 112 sequence numbers are required to monotonically increase with each 113 successive packet, which eliminates the possibility of intra-session 114 replay attacks. 116 BFD session timers are often defined with the granularity of 117 microseconds. Although in practice BFD devices send packets at 118 millisecond intervals, they can potentially send packets at a much 119 higher rate. Since the cryptographic sequence number space is only 120 32 bits, when using Meticulous Authentication, a sequence number used 121 in a BFD session can reach its maximum value and roll over within a 122 short period. For instance, if the value of a sequence number is 123 increased by one every millisecond, then it will reach its maximum in 124 less than 8 weeks. This can potentially be exploited to launch 125 inter-session replay attacks. 127 In order to address the issues mentioned above, this document 128 proposes two new authentication types that can be used to secure the 129 BFD packets. The two authentication types are - Cryptographic 130 Authentication (CRYPTO_AUTH) and Meticulous Cryptographic 131 Authentication (MET_ CRYPTO_AUTH). Unlike earlier authentication 132 types that were defined in BFD, the proposed authentication types are 133 not tied to any particular authentication algorithm or construct. 134 These can use different authentication algorithms and constructs like 135 MD5, SHA-1, SHA-2, HMAC-SHA1, HMAC-SHA2, etc. to provide 136 authentication and data integrity protection for BFD control packets. 138 The packet replay mechanism has also been enhanced to improve its 139 capability in handling inter and intra-session replay attacks. 141 It should be noted that this document attempts to fix the security 142 issues raised by the manual key management procedure that currently 143 exists within BFD, as part of the Phase One described in KARP-design- 144 guide [I-D.ietf-karp-design-guide]. Therefore, only the pre-shared 145 keys is considered in this document. However, the solution described 146 in this document is generic and does not preclude the possibility of 147 supporting keys derived from an automated key management protocol. 149 2. BFD Security Association 151 The BFD protocol does not include an in-band mechanism to create or 152 manage BFD Security Associations (BFD SA). A BFD SA contains a set 153 of shared parameters between any two legitimate BFD devices. 155 The parameters associated with a BFD SA are listed as follows: 157 o Authentication Algorithm : This indicates the authentication 158 algorithm to be used with the BFD SA. This information SHOULD never 159 be sent in plaintext over the wire. 161 o Authentication Key : This indicates the cryptographic key 162 associated with this BFD SA. The length of this key is variable and 163 depends upon the authentication algorithm specified by the BFD SA. 164 Operators MUST ensure that this is never sent over the network in 165 clear-text via any protocol. Care should also be taken to ensure 166 that the selected key is unpredictable, avoiding any keys known to be 167 weak for the algorithm in use. [RFC4086] contains helpful 168 information on both key generation techniques and cryptographic 169 randomness. 171 o Authentication Key Identifier (Key ID) : This is a two octet 172 unsigned integer used to uniquely identify the BFD SA. This ID could 173 be manually configured by the network operator (or, in the future, 174 possibly by some key management protocol specified by the IETF). The 175 receiver determines the active SA by looking at this field in the 176 incoming packet. The sender puts this Key ID in the BFD packet based 177 on the active configuration. Using Key IDs makes changing keys while 178 maintaining protocol operation convenient. Normally, an 179 implementation would allow the network operator to configure a set of 180 keys in a key chain, with each key in the chain having fixed 181 lifetime. The actual operation of these mechanisms is outside the 182 scope of this document. 184 A key ID indicates a tuple of an authentication key and an associated 185 authentication algorithm. If a key is expected to be applied with 186 different algorithms, different Key IDs must be used to identify the 187 associations of the key with its authentication algorithms 188 respectively. However, the application of a key for different 189 purposes must be very careful, since it may make an adversary easier 190 to collect more material to compromise the key. 192 o Not Before Time : The time point before which the key should not be 193 used. 195 o Not After Time : The time point after which the key should not be 196 used. 198 3. Authentication Procedures 200 In the proposed authentication extension, an optional authentication 201 section (Generic Authentication Section) and two authentication types 202 (Generic Cryptographic Authentication and Generic Meticulous 203 Cryptographic Authentication) are specified. 205 3.1. Authentication Types 207 The Authentication section is only present in a BFD packet if the 208 Authentication Present (A) bit is set in the packet header. The Auth 209 Type in the Authentication section is set to 6 when Generic 210 Cryptographic Authentication is in use, while it is set to 7 when 211 Generic Meticulous Cryptographic Authentication is in use. 213 Both the authentication types use a monotonically increasing sequence 214 number to protect the BFD session against reply attacks. The only 215 difference between the two types is that the sequence number is 216 occasionally incremented in the Cryptographic Authentication mode, as 217 against the Meticulous Cryptographic Authentication mode, where it is 218 incremented on every packet. 220 As a result of this, in the Cryptographic Authentication scheme, a 221 replay attack is possible till the next sequence number is sent out. 223 3.2. Authentication Section Format 225 A new authentication type, 6 or 7, indicating the generic 226 cryptographic authentication mechanism in use, is inserted in the 227 first octet of Authentication Section of the BFD control packet. 229 For a BFD packet, if the Authentication Present (A) bit is set in the 230 header and the Authentication Type field is 6 (Generic Cryptographic 231 Authentication) or 7 (Generic Meticulous Cryptographic 232 Authentication), the Authentication Section has the following format: 234 0 1 2 3 235 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 236 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 237 | Auth Type | Auth Len | Auth Key ID | 238 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 239 | Sequence Number (High Order 32 Bits) | 240 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 241 | Sequence Number (Low Order 32 Bits) | 242 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 243 | | 244 | Authentication Data (Variable) | 245 | | 246 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 248 o Auth Type: The Authentication Type, which in this case is 6 249 (Cryptographic Authentication) or 7 (Meticulous Cryptographic 250 Authentication). 252 o Auth Len: The length of the Authentication Section. 254 o Auth Key ID: The Key ID of the authentication key used for this 255 packet, enabling multiple keys to be active simultaneously. 257 o Sequence Number: A 64-bit sequence number that is used to prevent 258 replay attacks. For Cryptographic Authentication this value is 259 incremented occasionally. For Meticulous Cryptographic 260 Authentication, this value is incremented for each successive 261 packet transmitted for a session. 263 o Authentication Data: This field carries the digest computed by 264 whatever Cryptographic Authentication algorithm is being used to 265 authenticate the BFD control packet. 267 3.3. Procedures at the Sending Side 269 Before a BFD device sends a BFD packet out, the device needs to 270 select an appropriate BFD SA from its local key database if a keyed 271 digest for the packet is required. If no appropriate SA is 272 available, the BFD packet MUST be discarded. 274 If an appropriate SA is available, the device then derives the key 275 and the associated authentication algorithm from the SA. 277 The device sets the Authentication Present (A) bit in the packet 278 header. 280 The device MUST fill the Auth Type and the Auth Len fields before the 281 authentication data is computed. The Sequence Number field MUST be 282 set to bfd.XmitAuthSeq. 284 The Auth Len field in the Authentication section is set as per the 285 authentication algorithm that is being used. 287 The Key ID field is filled. 289 The computation of the digest is performed. The computing process 290 can be various when different algorithms are adopted and is out of 291 the scope of this document. 293 The generated digest is placed in the Authentication Data field. 295 3.4. Procedure at the Receiving Side 297 When a BFD Control packet is received, the following procedure MUST 298 be followed, in the order specified. 300 If the Authentication Present (A) bit is set in the packet header and 301 the receiver will try to find a appropriate BFD SA in its local key 302 table to process the packet. The BFD SA is identified by the Key ID 303 field in the Authentication Section of the incoming BFD packet. 305 If the Auth Key ID field does not match the ID of any configured 306 authentication key or the associated key is not in its valid period, 307 the received packet MUST be discarded. 309 If bfd.AuthSeqKnown is 1, examine the Sequence Number field. For 310 Cryptographic Authentication, if the Sequence Number lies outside of 311 the range of bfd.RcvAuthSeq to bfd.RcvAuthSeq+(3*Detect Mult) 312 inclusive (when treated as an unsigned 32 bit circular number space), 313 the received packet MUST be discarded. For Meticulous Cryptographic 314 Authentication, if the Sequence Number lies outside of the range of 315 bfd.RcvAuthSeq+1 to bfd.RcvAuthSeq+(3*Detect Mult) inclusive (when 316 treated as an unsigned 32 bit circular number space, the received 317 packet MUST be discarded. 319 The device then prepares for generating a digest of the packet. 320 First of all, the authentication data in the Authentication Value 321 field needs to be saved somewhere else. Then the Authentication 322 Value field is set with a pre-specified value (which may be various 323 in different security algorithms) according the authentication 324 algorithm indicated in the SA. After this, the device starts 325 performing the digest generating operations. The work of defining 326 actual digest generating operations is out of the scope of this 327 document. 329 The calculated data is compared with the received authentication data 330 in the packet and the packet MUST be discarded if the two do not 331 match. In such a case, an error event SHOULD be logged. 333 An implementation MAY have a transition mode where it includes 334 CRYPTO_AUTH or the MET_CRYPTO_AUTH information in the packets but 335 does not verify this information. This is provided as a transition 336 aid for networks in the process of migrating to the new CRYPTO_AUTH 337 and MET_CRYPTO_AUTH based authentication schemes. 339 3.5. Key Selection for BFD Packet Transmission 341 In [I-D.ietf-karp-crypto-key-table], a conceptual key database called 342 "key table" is introduce. A key table is located in the middle of 343 key management protocols and security protocols so that a security 344 protocol can derive long-term keys from the key table but does not 345 have to know the details of key management. This section describes 346 how the proposed security solution selects long-lived keys from key 347 tables [I-D.ietf-karp-crypto-key-table]. 349 Assume that a device R1 tries to send a unicast BFD packet from its 350 interface I1 to the interface R2 of a remote device R2 at time T. 351 Because the key should be shared by the by both R1 and R2 to protect 352 the communication between I1 and I2, R1 needs to provide a protocol 353 ("BFD"), an interface identifier (I1) and a peer identifier (R2) into 354 the key selection function. Any key that satisfies the following 355 conditions may be selected: 357 o The Peer field includes the device ID of R2. 359 o the Protocol field matches "BFD" 361 o The PeerKeyName field is not "unknown". 363 o The Interface field includes I1 or "all". 365 o The Direction field is either "out" or "both". 367 o SendNotBefore <= current time <= SendNotAfter. 369 After a set of keys are provided, a BFD implementation should support 370 selection of keys based on algorithm preference. 372 Upon R2 receives the BFD packet from R1, R2 provides the protocol 373 ("BFD"), the peer identifier (R1), the key identifier derived from 374 the incoming packet (L), and the interface (I2) to the key table. 375 Any key that satisfies the following conditions may be selected: 377 o The Peer field includes the device ID of R1. 379 o the Protocol field matches "BFD" 380 o the LocalKeyName is L 382 o The Interface field includes I2 or "all". 384 o The Direction field is either "out" or "both". 386 o SendNotBefore <= current time <= SendNotAfter. 388 3.6. Replay Protection using Extended Sequence Numbers 390 As described in Section 1, if the BFD packets in a session are 391 transferred with a high frequency, a 32-bit sequence number may reach 392 its maximum and have to roll back before the session finishes. A 393 attacker thus can replay the packets intercepted before the sequence 394 number wrapped without being detected. To address this problem, the 395 length of the sequence number in the proposed authentication section 396 has been extended to 64 bits. After the extension, the sequence 397 number space of a device will not be exhausted within half of a 398 million years even if the device sends out a BFD packet in every 399 micro-second. Therefore, the replay attack risks caused by the 400 limited sequence number space can be largely addressed. However, in 401 Generic Cryptographic Authentication, the sequence number is only 402 required to increase occasionally. Therefore, a replayed packet may 403 be regarded as a legal one until the packet with a larger sequence 404 number is received. This type of intra-session replay attack cannot 405 be addressed only by extending the length of sequence numbers. 407 An anti-replay solution for BFD also needs to consider the scenarios 408 where a BFD device loses its prior sequence number state (e.g., 409 system crash, loss of power). In such cases, a BFD device has to re- 410 initialize its sequence number. Taking this opportunity, an attacker 411 may be able to replay the antique packets intercepted in previous 412 sessions without being detected. 414 To address this problem, in the proposed solution, the most 415 significant 32-bit value of the sequence number is used to contain a 416 boot count, and the remainder 32-bit value is used as an ordinary 417 32-bit monotonically increasing sequence number. In Generic 418 Cryptographic Authentication, the remainder 32-bit value is required 419 to increase occasionally, while in Generic Meticulous Cryptographic 420 Authentication, the lower order 32-bit sequence number MUST be 421 incremented for every BFD packet sent by a BFD device. The BFD 422 implementations are required to retain the boot count in non-volatile 423 storage for the deployment life the BFD device. The boot count 424 increases each time when the BFD device loses its prior sequence 425 number state. The SNMPv3 snmpEngineBoots variable [RFC4222] MAY be 426 used for this purpose. However, maintaining a separate boot count 427 solely for BFD sequence numbers has the advantage of decoupling SNMP 428 re-initialization and BFD re-initialization. Also, in the rare event 429 that the lower order 32- bit sequence number wraps, the boot count 430 can be incremented to preserve the strictly increasing property of 431 the aggregate sequence number. Hence, a separate BFD boot count is 432 RECOMMENDED. 434 4. IANA Considerations 436 This document currently defines a value of 6 to be used to denote 437 Cryptographic Authentication mechanism for authenticating BFD control 438 packets and 7 for Meticulous Cryptographic Authentication. 440 5. Security Considerations 442 The proposed sequence number extension offers most of the benefits of 443 of more complicated mechanisms involving challenges. There are, 444 however, a couple drawbacks to this approach. First, it requires the 445 BFD implementation to be able to save its boot count in non-volatile 446 storage. If the non-volatile storage is ever repaired or upgraded 447 such that the contents are lost or the BFD device is replaced with a 448 model, the keys MUST be changed to prevent replay attacks. Second, 449 if a device is taken out of service completely (either intentionally 450 or due to a persistent failure), the potential exists for re- 451 establishment of a BFD adjacency by replaying the entire BFD session 452 establishment. This scenario is however, extremely unlikely and can 453 be easily avoided. For instance, after recovering from a system 454 failure, a BFD device has to re-establish BFD sessions. At this 455 stage, if the device randomly selects its discriminators to identify 456 new BFD sessions, the possibility of reestablishing a BFD session by 457 replaying the entire BFD session establishment will be eliminated. 458 For the implementations in which discriminators are not randomly 459 selected, this issue can be largely mitigated by integrating the boot 460 count of the remote BFD router in the generation of the 461 authentication data for outgoing BFD packets. Of course, this attack 462 could also be thwarted by changing the relevant manual keys. 464 There is a transition mode suggested where devices can ignore the 465 CRYPTO_AUTH or the MET_CRYPTO_AUTH information carried in the 466 packets. The operator must ensure that this mode is only used when 467 migrating to the new CRYPTO_AUTH/MET_CRYPTO_AUTH based authentication 468 scheme as this leaves the device vulnerable to an attack. 470 6. Acknowledgements 472 7. References 474 7.1. Normative References 476 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 477 Requirement Levels", BCP 14, RFC 2119, March 1997. 479 7.2. Informative References 481 [Dobb96a] Dobbertin, H., "Cryptanalysis of MD5 Compress", May 1996. 483 [Dobb96b] Dobbertin, H., "The Status of MD5 After a Recent Attack", 484 CryptoBytes", 1996. 486 [I-D.ietf-karp-crypto-key-table] 487 Housley, R., Polk, T., Hartman, S., and D. Zhang, 488 "Database of Long-Lived Symmetric Cryptographic Keys", 489 draft-ietf-karp-crypto-key-table-08 (work in progress), 490 July 2013. 492 [I-D.ietf-karp-design-guide] 493 Lebovitz, G. and M. Bhatia, "Keying and Authentication for 494 Routing Protocols (KARP) Design Guidelines", draft-ietf- 495 karp-design-guide-10 (work in progress), December 2011. 497 [MD5-attack] 498 Wang, X., Feng, D., Lai, X., and H. Yu, "Collisions for 499 Hash Functions MD4, MD5, HAVAL-128 and RIPEMD", August 500 2004. 502 [RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, 503 April 1992. 505 [RFC4086] Eastlake, D., Schiller, J., and S. Crocker, "Randomness 506 Requirements for Security", BCP 106, RFC 4086, June 2005. 508 [RFC4222] Choudhury, G., "Prioritized Treatment of Specific OSPF 509 Version 2 Packets and Congestion Avoidance", BCP 112, RFC 510 4222, October 2005. 512 [RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detection 513 (BFD)", RFC 5880, June 2010. 515 [SHA-1-attack1] 516 Wang, X., Yin, Y., and H. Yu, "Finding Collisions in the 517 Full SHA-1", 2005. 519 [SHA-1-attack2] 520 Wang, X., Yao, A., and F. Yao, "New Collision Search for 521 SHA-1", 2005. 523 Authors' Addresses 525 Manav Bhatia 526 Alcatel-Lucent 527 Bangalore 528 India 530 Email: manav.bhatia@alcatel-lucent.com 532 Vishwas Manral 533 Hewlett-Packard Co. 534 19111 Pruneridge Ave. 535 Cupertino, CA 95014 536 USA 538 Email: vishwas.manral@hp.com 540 Dacheng Zhang 541 Huawei 542 Beijing 543 China 545 Email: zhangdacheng@huawei.com