idnits 2.17.1 draft-ietf-bfd-generic-crypto-auth-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 19, 2012) is 4201 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: 'MD5-attack' is defined on line 498, but no explicit reference was found in the text == Unused Reference: 'RFC1321' is defined on line 503, but no explicit reference was found in the text == Outdated reference: A later version (-10) exists of draft-ietf-karp-crypto-key-table-03 Summary: 0 errors (**), 0 flaws (~~), 4 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 22, 2013 Hewlett-Packard Co. 6 D. Zhang 7 Huawei 8 October 19, 2012 10 BFD Generic Cryptographic Authentication 11 draft-ietf-bfd-generic-crypto-auth-03 13 Abstract 15 This document proposes an extension to Bidirectional Forwarding 16 Detection (BFD) to allow the use of any cryptographic authentication 17 algorithm in addition to the already-documented authentication 18 schemes described in the base specification. This document adds the 19 basic infrastructure that is required for supporting algorithm and 20 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 22, 2013. 45 Copyright Notice 47 Copyright (c) 2012 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 . . . . . . . . . . . . . . . . . . . . . . . . . 3 63 2. BFD Security Association . . . . . . . . . . . . . . . . . . . 4 64 3. Authentication Procedures . . . . . . . . . . . . . . . . . . 5 65 3.1. Authentication Types . . . . . . . . . . . . . . . . . . . 5 66 3.2. Authentication Section Format . . . . . . . . . . . . . . 6 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 . . . . . . . . . . . . . . . . . . . . . . . 11 74 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 75 7.1. Normative References . . . . . . . . . . . . . . . . . . . 11 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 [MD5- 98 attack] and [Dobb96a, Dobb96b], several methods of generating hash 99 collisions for some applications of MD5 are proposed. Similar 100 security vulnerabilities of SHA-1 are introduced in [SHA-1-attack1] 101 and [SHA-1-attack2]. It is therefore desired that BFD must support 102 newer algorithms that have not yet been broken. Additionally, the 103 transition mechanism from one algorithm to the other must be 104 seamless. 106 The other issue with the existing authentication schemes is the 107 vulnerability to replay attacks. In non-meticulous authentication 108 schemes, sequence numbers are only increased occasionally. This 109 behavior can be taken advantage of by an attacker to perform intra- 110 session replay attacks. In meticulous authentication schemes, 111 sequence numbers are required to monotonically increase with each 112 successive packet, which eliminates the possibility of intra-session 113 replay attacks. 115 BFD session timers are often defined with the granularity of 116 microseconds. Although in practice BFD devices send packets at 117 millisecond intervals, they can potentially send packets at a much 118 higher rate. Since the cryptographic sequence number space is only 119 32 bits, when using Meticulous Authentication, a sequence number used 120 in a BFD session can reach its maximum value and roll over within a 121 short period. For instance, if the value of a sequence number is 122 increased by one every millisecond, then it will reach its maximum in 123 less than 8 weeks. This can potentially be exploited to launch 124 inter-session replay attacks. 126 In order to address the issues mentioned above, this document 127 proposes two new authentication types that can be used to secure the 128 BFD packets. The two authentication types are - Cryptographic 129 Authentication (CRYPTO_AUTH) and Meticulous Cryptographic 130 Authentication (MET_ CRYPTO_AUTH). Unlike earlier authentication 131 types that were defined in BFD, the proposed authentication types are 132 not tied to any particular authentication algorithm or construct. 133 These can use different authentication algorithms and constructs like 134 MD5, SHA-1, SHA-2, HMAC-SHA1, HMAC-SHA2, etc. to provide 135 authentication and data integrity protection for BFD control packets. 137 The packet replay mechanism has also been modified to improve its 138 capability in handling inter and intra-session replay attacks. 140 It should be noted that this document attempts to fix the manual key 141 management procedure that currently exists within BFD, as part of the 142 Phase One described in KARP-design-guide 143 [I-D.ietf-karp-design-guide]. Therefore, only the pre-shared keys is 144 considered in this document. However, the solution described in this 145 document is generic and does not preclude the possibility of 146 supporting keys derived from an automated key management protocol. 148 2. BFD Security Association 150 The BFD protocol does not include an in-band mechanism to create or 151 manage BFD Security Associations (BFD SA). A BFD SA contains a set 152 of shared parameters between any two legitimate BFD devices. 154 The parameters associated with a BFD SA are listed as follows: 156 o Authentication Algorithm : This indicates the authentication 157 algorithm to be used with the BFD SA. This information SHOULD never 158 be sent in plaintext over the wire. 160 o Authentication Key : This indicates the cryptographic key 161 associated with this BFD SA. The length of this key is variable and 162 depends upon the authentication algorithm specified by the BFD SA. 163 Operators MUST ensure that this is never sent over the network in 164 clear-text via any protocol. Care should also be taken to ensure 165 that the selected key is unpredictable, avoiding any keys known to be 166 weak for the algorithm in use. [RFC4086] contains helpful 167 information on both key generation techniques and cryptographic 168 randomness. 170 o Authentication Key Identifier (Key ID) : This is a two octet 171 unsigned integer used to uniquely identify the BFD SA. This ID could 172 be manually configured by the network operator (or, in the future, 173 possibly by some key management protocol specified by the IETF). The 174 receiver determines the active SA by looking at this field in the 175 incoming packet. The sender puts this Key ID in the BFD packet based 176 on the active configuration. Using Key IDs makes changing keys while 177 maintaining protocol operation convenient. Normally, an 178 implementation would allow the network operator to configure a set of 179 keys in a key chain, with each key in the chain having fixed 180 lifetime. The actual operation of these mechanisms is outside the 181 scope of this document. 183 A key ID indicates a tuple of an authentication key and an associated 184 authentication algorithm. If a key is expected to be applied with 185 different algorithms, different Key IDs must be used to identify the 186 associations of the key with its authentication algorithms 187 respectively. However, the application of a key for different 188 purposes must be very careful, since it may make an adversary easier 189 to collect more material to compromise the key. 191 o Not Before Time : The time point before which the key should not be 192 used. 194 o Not After Time : The time point after which the key should not be 195 used. 197 3. Authentication Procedures 199 In the proposed authentication extension, an optional authentication 200 section (Generic Authentication Section) and two authentication types 201 (Generic Cryptographic Authentication and Generic Meticulous 202 Cryptographic Authentication) are specified. 204 3.1. Authentication Types 206 The Authentication section is only present in a BFD packet if the 207 Authentication Present (A) bit is set in the packet header. The Auth 208 Type in the Authentication section is set to 6 when Generic 209 Cryptographic Authentication is in use, while it is set to 7 when 210 Generic Meticulous Cryptographic Authentication is in use. 212 Both the authentication types use a monotonically increasing sequence 213 number to protect the BFD session against reply attacks. The only 214 difference between the two types is that the sequence number is 215 occasionally incremented in the Cryptographic Authentication mode, as 216 against the Meticulous Cryptographic Authentication mode, where it is 217 incremented on every packet. 219 As a result of this, in the Cryptographic Authentication scheme, a 220 replay attack is possible till the next sequence number is sent out. 222 3.2. Authentication Section Format 224 A new authentication type, 6 or 7, indicating the generic 225 cryptographic authentication mechanism in use, is inserted in the 226 first octet of Authentication Section of the BFD control packet. 228 For a BFD packet, if the Authentication Present (A) bit is set in the 229 header and the Authentication Type field is 6 (Generic Cryptographic 230 Authentication) or 7 (Generic Meticulous Cryptographic 231 Authentication), the Authentication Section has the following format: 232 0 1 2 3 233 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 234 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 235 | Auth Type | Auth Len | Auth Key ID | 236 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 237 | Sequence Number (High Order 32 Bits) | 238 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 239 | Sequence Number (Low Order 32 Bits) | 240 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 241 | | 242 | Authentication Data (Variable) | 243 | | 244 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 246 o Auth Type: The Authentication Type, which in this case is 6 247 (Cryptographic Authentication) or 7 (Meticulous Cryptographic 248 Authentication). 250 o Auth Len: The length of the Authentication Section. 252 o Auth Key ID: The Key ID of the authentication key used for this 253 packet, enabling multiple keys to be active simultaneously. 255 o Sequence Number: A 64-bit sequence number that is used to prevent 256 replay attacks. For Cryptographic Authentication this value is 257 incremented occasionally. For Meticulous Cryptographic 258 Authentication, this value is incremented for each successive 259 packet transmitted for a session. 261 o Authentication Data: This field carries the digest computed by 262 whatever Cryptographic Authentication algorithm is being used to 263 authenticate the BFD control packet. 265 3.3. Procedures at the Sending Side 267 Before a BFD device sends a BFD packet out, the device needs to 268 select an appropriate BFD SA from its local key database if a keyed 269 digest for the packet is required. If no appropriate SA is 270 available, the BFD packet MUST be discarded. 272 If an appropriate SA is available, the device then derives the key 273 and the associated authentication algorithm from the SA. 275 The device sets the Authentication Present (A) bit in the packet 276 header. 278 The device MUST fill the Auth Type and the Auth Len fields before the 279 authentication data is computed. The Sequence Number field MUST be 280 set to bfd.XmitAuthSeq. 282 The Auth Len field in the Authentication section is set as per the 283 authentication algorithm that is being used. 285 The Key ID field is filled. 287 The computation of the digest is performed. The computing process 288 can be various when different algorithms are adopted and is out of 289 the scope of this document. 291 The generated digest is placed in the Authentication Data field. 293 3.4. Procedure at the Receiving Side 295 When a BFD Control packet is received, the following procedure MUST 296 be followed, in the order specified. 298 If the Authentication Present (A) bit is set in the packet header and 299 the receiver will try to find a appropriate BFD SA in its local key 300 table to process the packet. The BFD SA is identified by the Key ID 301 field in the Authentication Section of the incoming BFD packet. 303 If the Auth Key ID field does not match the ID of any configured 304 authentication key or the associated key is not in its valid period, 305 the received packet MUST be discarded. 307 If bfd.AuthSeqKnown is 1, examine the Sequence Number field. For 308 Cryptographic Authentication, if the Sequence Number lies outside of 309 the range of bfd.RcvAuthSeq to bfd.RcvAuthSeq+(3*Detect Mult) 310 inclusive (when treated as an unsigned 32 bit circular number space), 311 the received packet MUST be discarded. For Meticulous Cryptographic 312 Authentication, if the Sequence Number lies outside of the range of 313 bfd.RcvAuthSeq+1 to bfd.RcvAuthSeq+(3*Detect Mult) inclusive (when 314 treated as an unsigned 32 bit circular number space, the received 315 packet MUST be discarded. 317 The device then prepares for generating a digest of the packet. 319 First of all, the authentication data in the Authentication Value 320 field needs to be saved somewhere else. Then the Authentication 321 Value field is set with a pre-specified value (which may be various 322 in different security algorithms) according the authentication 323 algorithm indicated in the SA. After this, the device starts 324 performing the digest generating operations. The work of defining 325 actual digest generating operations is out of the scope of this 326 document. 328 The calculated data is compared with the received authentication data 329 in the packet and the packet MUST be discarded if the two do not 330 match. In such a case, an error event SHOULD be logged. 332 An implementation MAY have a transition mode where it includes 333 CRYPTO_AUTH or the MET_CRYPTO_AUTH information in the packets but 334 does not verify this information. This is provided as a transition 335 aid for networks in the process of migrating to the new CRYPTO_AUTH 336 and MET_CRYPTO_AUTH based authentication schemes. 338 3.5. Key Selection for BFD Packet Transmission 340 In [I-D.ietf-karp-crypto-key-table], a conceptual key database called 341 "key table" is introduce. A key table is located in the middle of 342 key management protocols and security protocols so that a security 343 protocol can derive long-term keys from the key table but does not 344 have to know the details of key management. This section describes 345 how the proposed security solution selects long-lived keys from key 346 tables [I-D.ietf-karp-crypto-key-table]. 348 Assume that a device R1 tries to send a unicast BFD packet from its 349 interface I1 to the interface R2 of a remote device R2 at time T. 350 Because the key should be shared by the by both R1 and R2 to protect 351 the communication between I1 and I2, R1 needs to provide a protocol 352 ("BFD"), an interface identifier (I1) and a peer identifier (R2) into 353 the key selection function. Any key that satisfies the following 354 conditions may be selected: 356 o The Peer field includes the device ID of R2. 358 o the Protocol field matches "BFD" 360 o The PeerKeyName field is not "unknown". 362 o The Interface field includes I1 or "all". 364 o The Direction field is either "out" or "both". 366 o SendNotBefore <= current time <= SendNotAfter. 368 After a set of keys are provided, a BFD implementation should support 369 selection of keys based on algorithm preference. 371 Upon R2 receives the BFD packet from R1, R2 provides the protocol 372 ("BFD"), the peer identifier (R1), the key identifier derived from 373 the incoming packet (L), and the interface (I2) to the key table. 374 Any key that satisfies the following conditions may be selected: 376 o The Peer field includes the device ID of R1. 378 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 32- 417 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-03 (work in progress), 490 June 2012. 492 [I-D.ietf-karp-design-guide] 493 Lebovitz, G. and M. Bhatia, "Keying and Authentication for 494 Routing Protocols (KARP) Design Guidelines", 495 draft-ietf-karp-design-guide-10 (work in progress), 496 December 2011. 498 [MD5-attack] 499 Wang, X., Feng, D., Lai, X., and H. Yu, "Collisions for 500 Hash Functions MD4, MD5, HAVAL-128 and RIPEMD", 501 August 2004. 503 [RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, 504 April 1992. 506 [RFC4086] Eastlake, D., Schiller, J., and S. Crocker, "Randomness 507 Requirements for Security", BCP 106, RFC 4086, June 2005. 509 [RFC4222] Choudhury, G., "Prioritized Treatment of Specific OSPF 510 Version 2 Packets and Congestion Avoidance", BCP 112, 511 RFC 4222, October 2005. 513 [RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detection 514 (BFD)", RFC 5880, June 2010. 516 [SHA-1-attack1] 517 Wang, X., Yin, Y., and H. Yu, "Finding Collisions in the 518 Full SHA-1", 2005. 520 [SHA-1-attack2] 521 Wang, X., Yao, A., and F. Yao, "New Collision Search for 522 SHA-1", 2005. 524 Authors' Addresses 526 Manav Bhatia 527 Alcatel-Lucent 528 Bangalore 529 India 531 Email: manav.bhatia@alcatel-lucent.com 533 Vishwas Manral 534 Hewlett-Packard Co. 535 19111 Pruneridge Ave. 536 Cupertino, CA 95014 537 USA 539 Email: vishwas.manral@hp.com 541 Dacheng Zhang 542 Huawei 543 Beijing, 544 China 546 Email: zhangdacheng@huawei.com