idnits 2.17.1 draft-xu-dhc-cadhcp-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: ---------------------------------------------------------------------------- == The page length should not exceed 58 lines per page, but there was 2 longer pages, the longest (page 12) being 71 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 12 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 13 instances of too long lines in the document, the longest one being 9 characters in excess of 72. ** The abstract seems to contain references ([RFC2485], [RFC3118]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to contain a disclaimer for pre-RFC5378 work, but was first submitted on or after 10 November 2008. The disclaimer is usually necessary only for documents that revise or obsolete older RFCs, and that take significant amounts of text from those RFCs. If you can contact all authors of the source material and they are willing to grant the BCP78 rights to the IETF Trust, you can and should remove the disclaimer. Otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (June 15, 2011) is 4692 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) == Missing Reference: 'RFC5280' is mentioned on line 106, but not defined -- Looks like a reference, but probably isn't: '0' on line 242 == Unused Reference: 'RFC2131' is defined on line 463, but no explicit reference was found in the text ** Obsolete normative reference: RFC 5246 (Obsoleted by RFC 8446) Summary: 3 errors (**), 0 flaws (~~), 6 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 DHC Y. Xu 3 Internet-Draft S. Manning 4 Intended status: Standards Track M. Wong 5 Expires: December 17, 2011 Huawei Technologies 6 June 15, 2011 8 A authentication method based on certificate for DHCP 9 draft-xu-dhc-cadhcp-00.txt 11 Abstract 13 This document defines a technique that can provide both entity 14 authentication and message authentication based on certificates. This 15 protocol combines existing options, such as the delay authentication 16 mechanism in [RFC3118] and the user authentication protocol option 17 defined in [RFC2485]. The goal of this specification is to define 18 methods for certificates to protect the integrity of DHCP messages 19 and close the gaps of the existing delay authentication mechanism. 20 In order to meet these goals, we use the asymmetrical cryptograph 21 protection and some options about authentication that have been 22 defined in other specifications. 24 Status of this Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at http://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on December 11, 2011. 41 Copyright Notice 43 Copyright (c) 2011 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (http://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 This document may contain material from IETF Documents or IETF 57 Contributions published or made publicly available before November 58 10, 2008. The person(s) controlling the copyright in some of this 59 material may not have granted the IETF Trust the right to allow 60 modifications of such material outside the IETF Standards Process. 61 Without obtaining an adequate license from the person(s) controlling 62 the copyright in such materials, this document may not be modified 63 outside the IETF Standards Process, and derivative works of it may 64 not be created outside the IETF Standards Process, except to format 65 it for publication as an RFC or to translate it into languages other 66 than English. 68 Table of Contents 70 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 71 2. Terminology used in this document . . . . . . . . . . . . . . 4 72 3. Certificate Based Authentication . . . . . . . . . . . . . . . 4 73 4. Unicast DHCPOFFER Message . . . . . . . . . . . . . . . . . . 6 74 5. Authentication between DHCP server and the trusted server . . 7 75 6. The Generation of signature . . . . . . . . . . . . . . . . . 8 76 7. Message validation . . . . . . . . . . . . . . . . . . . . . . 8 77 8. Entity authentication . . . . . . . . . . . . . . . . . . . . 8 78 9. Client Considerations . . . . . . . . . . . . . . . . . . . . 8 79 10. Server Considerations . . . . . . . . . . . . . . . . . . . . 9 80 11. Trusted server Considerations . . . . . . . . . . . . . . . . 9 81 12. Application example . . . . . . . . . . . . . . . . . . . . . 10 82 13. Security Considerations . . . . . . . . . . . . . . . . . . . 11 83 14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 84 15. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11 85 16. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 86 16.1. Normative References . . . . . . . . . . . . . . . . . . 11 87 16.2. Informative References . . . . . . . . . . . . . . . . . 12 88 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 12 90 1. Introduction 92 DHCP provides a framework for passing network configuration 93 information to hosts on a TCP/IP network. Most of these parameters 94 are IP addresses. The DHCP server can allocate addresses to clients 95 dynamically. To ensure the security of communication between DHCP 96 client and DHCP server, network administrators may wish to provide 97 authentication for the DHCP clients and DHCP messages. [RFC3118] 98 defines an authentication mechanism for DHCP, the delay authentication 99 protocol. But it is vulnerable to denial of service attacks through 100 flooding with DHCPDISCOVER messages, which are not authenticated by 101 Delay authentication protocol. This attack may overwhelm the DHCP 102 server and exhaust the addresses available for assignment by the DHCP 103 server. Delay authentication is prone to other kinds of attacks and 104 limitations. Further, this delay authentication is based on a pre-shared key. 105 This increases the overload of key distribution and management in 106 the implementation. As defined in [RFC5280], certificates can be used 107 in entity authentication widely. The MTU in Ethernet is usually 1500 108 bytes, while the certificate is usually as large as 1k or 2k bytes, 109 and since DHCPDISCOVER messages and DHCPREQUEST messages are broadcast 110 messages, these cannot be fragmented into several messages. Thus, 111 directly carrying certificates in DHCP messages is impossible. This 112 document defines a new method for Dynamic Host Configuration Protocol 113 authentication based on certificates. The basic design philosophy is 114 performing authentication immediately between DHCP client and DHCP 115 server by combining some authentication options, sending URL 116 information and the Client identity specified in [RFC2485] and [RFC2132] 117 instead of a certificate directly, and leveraging a mechanism where 118 the DHCP server has been authenticated by a centralized trusted 119 server. 121 2. Terminology used in this document 123 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 124 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 125 document are to be interpreted as described in [RFC2119]. 127 3. Certificate Based Authentication 129 The DHCP client is configured with its certificate and the 130 corresponding private key and the trusted server's certificate. The 131 DHCP server is configured with its certificate and the corresponding 132 private key. The trusted server is configured with its certificate 133 and the corresponding private key and certificates of DHCP clients. 134 A DHCP client sends DHCPDISCOVER message that has been protected by 135 its private key to DHCP server, the verification of the message is 136 through the DHCP server and trusted server. If successful, the DHCP 137 server sends the DHCPOFFER message protected with the private key of 138 the DHCP server. And the DHCP client authenticates the DHCP server 139 by the validation of the DHCPOFFER message. 141 Based on the authentication option from [RFC3118], if the protocol 142 field is 2(TBD), the message uses the certificate based 143 authentication mechanism defined in this document. In the 144 certificate based authentication, the client requests authentication 145 in the DHCPDISCOVER message and the server replies with a DHCPOFFER 146 message. Three options are included in the DHCPDISCOVER message, the 147 Authentication Option defined in this document, the Client-identifier 148 Option defined in [RFC2132] and the User Authentication Protocol 149 Option defined in [RFC2485]. The DHCPDISCOVER message is signed 150 with the private key of the DHCP client. For the Authentication 151 Option, unlike the delayed authentication mechanism, the signature 152 generated with the DHCP client private key is added in the 153 Authentication Information. The Client-identifier Option (Option 61) 154 is used to carry the DHCP client identifier. If the DHCP client is 155 configured with a certificate, the sequence number of certificate can 156 be used as the DHCP client identifier. The User Authentication 157 Protocol Option is used to carry the URL of the trusted server, such 158 as, a certificate server. The URL of the trusted server can be 159 configured out of band. 161 The format of the authentication request in a DHCPDISCOVER or a 162 DHCPINFORM message for certificate authentication is: 164 0 1 2 3 165 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 166 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 167 | Code | Length |0 0 0 0 0 0 1 0| Algorithm | 168 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 169 | RDM | Replay Detection (64 bits) | 170 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 171 | Replay cont | Signature (128bytes/256bytes/512 bytes) .... 172 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 174 Figure 1. The format of the authentication request(DHCPDISCOVER/ 175 DHCPINFORM) 177 The code for the authentication option is 90, and the length field 178 contains the length of protocol, RDM, algorithm, Replay Detection 179 field, and Signature. The protocol is defined to 2(00000010). The 180 signature field is used for message validation. The other field is 181 defined as [RFC3118] . 183 When the DHCP server receives the DHCPDISCOVER message, it can obtain 184 the DHCP client's certificate by the URL and the client identity. 185 At first, the DHCP server searches the trusted server with the URL 186 information, and forwards the client identity information to the 187 trusted server to obtain the DHCP client certificate. If the DHCP 188 server is authenticated by a trusted server, the DHCP server 189 downloads the DHCP client certificate from the trusted server. The 190 certificate may be protected with the secure tunnel, such as, SSL/ 191 TLS, which is established between the DHCP server and the trusted 192 server. Through the authentication between DHCP server and the 193 trusted server, only the legitimate DHCP server or the authenticated 194 DHCP server can obtain the certificate of the DHCP client from the 195 trusted server. 197 After the trusted server receives the client identity information, it 198 checks the validity of the client identity. If it is legitimate, the 199 trusted server will send the certificate to the DHCP server via the 200 SSL/TLS tunnel. Upon receiving the DHCP client certificate, the DHCP 201 server checks that the subject field of certificate matches with the 202 client identity. The DHCP server validates the signature of the 203 DHCPDISCOVER in Authentication Option. If the validation is 204 successful, it proves that the DHCP client is in possession of the 205 private key corresponding to the certificate. At this time, the DHCP 206 client has been authenticated with the certificate based 207 authentication mechanism. 209 4. Unicast DHCPOFFER Message 211 When DHCPOFFER is unicast, it can be fragmented and maybe used to 212 carry a certificate. The DHCP server will use its private key to 213 sign the DHCPOFFER message, which contains the configured 214 information, such as Vendor Specific Information option, the 215 Authentication option, and may contain other options. The 216 certificate of the DHCP server is included in the Authentication 217 Option. The format of the option is shown in Figure 2. If the 218 length exceeds the MTU, it can be fragmented with several messages 219 with same sequence number specified as in [RFC3396] . When the DHCP 220 client receive whole the DHCPOFFER message, it obtains the DHCP 221 server's certificate to check whether the certificate is valid, and 222 validates the signature of the DHCPOFFER message. 224 The following DHCPREQUEST message and the DHCPACK message can be 225 validated by the same authentication mechanism. The DHCP client 226 protects the sending message with the signature generated by its 227 private key. The DHCP server validates the signature with the public 228 key of the DHCP client. 230 The format of the authentication information in a DHCPOFFER, DHCPACK 231 message for certificate authentication is shown as follow, 233 0 1 2 3 234 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 235 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 236 | Code | Length |0 0 0 0 0 0 1 0| Algorithm | 237 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 238 | RDM | Replay Detection (64 bits) | 239 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 240 | Replay cont | Flags|U|RSD| Fragment Offset | 241 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 242 | Certificate [0] Signature (128bytes/256bytes/512 bytes) .... 243 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 245 Figure 2. The format of the authentication information(DHCPOFFER/ 246 DHCPACK) 248 We can use the new defined format of the option. Then we can use the 249 following format in DHCPOFFER, DHCPACK message. And when the option 250 exceeds 255 bytes, the method that specified in [RFC3396] will be 251 used. 253 0 1 2 3 254 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 255 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 256 | Code | Length |0 0 0 0 0 0 1 0| Algorithm | 257 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 258 | RDM | Replay Detection (64 bits) | 259 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 260 | Replay cont |Certificate ... 261 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 262 | Signature (128bytes/256bytes/512 bytes) ... 263 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 265 Figure 3. The format of the new authentication option 267 5. Authentication between DHCP server and the trusted server 269 The authentication mechanism between DHCP server and the trusted 270 server may be any existing authentication method, such as, the SSL/ 271 TLS defined in [RFC4246] and [RFC5246]. After the authentication 272 between the trusted server and the DHCP server, the SSL/TLS tunnel is 273 established between DHCP server and the trusted server. 275 6. The Generation of signature 277 The signature of the message is generated through the private key and 278 DHCP content, such as, DHCP message or some information like entity 279 identity. For the DHCPDISCOVER and the DHCPREQUEST message, the 280 signature is generated with the private key of the DHCP client. For 281 the DHCPOFFER and the DHCPACK message, the signature is generated 282 with the private key of the DHCP server and the DHCP contents. 284 7. Message validation 286 To validate the incoming DHCP messages, the receiver will check the 287 signature with the corresponding public key. For the DHCPDISCOVER 288 and the DHCPREQUEST message, the DHCP server first checks whether the 289 value in replay detection field is acceptable according to the replay 290 detection method specified by the RDM field. Next the server 291 validates the signature with the public key in the client's 292 certificate. For the DHCPOFFER and the DHCPACK message, the client 293 checks the replay detection field, if it is correct, the client 294 validates the DHCP server's certificate and checks the validity of 295 the signature of the DHCP message to guarantee that this DHCP server 296 has been authenticated. 298 8. Entity authentication 300 The DHCP server authenticates the DHCP client by the validation of 301 the DHCPDISCOVER message signature. This validation is carried out 302 by the DHCP server with the certificate of the DHCP client acquired 303 from the trusted server. The DHCP client authenticates the DHCP 304 server by validating the DHCP server's certificate and the signature 305 of the DHCPOFFER message. 307 9. Client Considerations 309 This section describes the behavior of a DHCP client using the 310 certificate based authentication. 312 1. The client MUST include the authentication request option using 313 certificates where the protocol field is equal to 2 in its DHCPDISCOVER 314 message along with the client identifier option and the User 315 Authentication Protocol Option. The DHCPDISCOVER message MUST sign 316 the message with the client's private key. 318 2. The client MUST perform the validation of the DHCP server's 319 certificate and the signature of the DHCPOFFER message. 320 3. The client replies with a DHCPREQUEST message that MUST include 321 authentication option protected by the same private key used in 322 DHCPDISCOVER message. 323 4. If the client validates the DHCPOFFER it accepted, the client 324 MUST validate the DHCPACK message from the server. 326 10. DHCP Server Considerations 328 This section describes the behavior of a DHCP server in response to 329 client message using certificate based authentication. 331 1. Each server MUST be authenticated by a trusted server and can 332 maintain the secure link with this trusted server. 333 2. Each server MUST validate the incoming message with the public key 334 of the DHCP client by obtaining the certificate of the DHCP client 335 from the trusted server. 336 3. Each server MUST protect the sending message by the private key of 337 the DHCP server. If the replay detection check or the message signature 338 validation fails, the server MUST discard the incoming message. 340 11. Trusted server Considerations 342 The trusted server is only a general name for a certificate server. 343 Any valid authentication mechanism may be used between DHCP server 344 and trusted server. The trusted server can regarded as high level 345 sever that can authenticate DHCP servers. 347 This section describes the behavior of the trusted server using 348 certificate based authentication. 350 1. The trusted server MAY authenticate the DHCP server prior to the 351 connection between the DHCP client and DHCP server. 352 2. The trusted server MUST distribute the certificate of the DHCP client 353 to a legitimate DHCP server that has been authenticated. 354 3. Client certificates may be cached or obtained in real time, but caching 355 has performance gain at the expense of memory usage. As the client list 356 grows, the DHCP server will use more memory to store the client's 357 certificates, which will increase the overhead of certificate 358 management. This is similar to the argument of not using PSK-based 359 scheme. 361 12. Application example 363 +-------------+ +------------+ +---------------+ 364 | | | | | | 365 | client | |DHCP server | |Trusted Server | 366 | | | | | | 367 +-------------+ +------------+ +---------------+ 368 | | Security Tunnel | 369 | |<----------------->| 370 | DHCP Discover | | 371 |-------------------------->| | 372 | | Security Tunnel | 373 | |<----------------->| 374 | |download certificat|e 375 | |<----------------->| 376 | | | 377 | +----------------------+ | 378 | | Obtain public key of | | 379 | | DHCP client,validate | | 380 | | the messsage | | 381 | +----------------------+ | 382 | DHCP OFFER | | 383 |<------------------------->| | 384 | | | 385 +---------------------+ | | 386 |Validate the message | | | 387 +---------------------+ | | 388 | DHCP Request | | 389 |-------------------------->| | 390 | DHCP ACK | | 391 |<------------------------->| | 393 Figure 4. DHCP Example Procedure 395 Security tunnel will be established between DHCP server and Trust 396 server before or after DHCP server receive DHCP DISCOVER message. 397 With the DHCP client ID and the address information of trusted 398 server, DHCP server obtain the corresponding public key of the DHCP 399 client to validate the DHCP DISCOVER message. If successful, the 400 DHCP server will send DHCPOFFER to DHCP client specified according to 401 unicast case or broadcast case. And the client validates the DHCP 402 OFFER corresponding to the two different cases. The authentication 403 of following messages can be used the similar mechanism. 405 13. Security Considerations 407 1. On Signature: Signature calculation can be based on either sender's 408 private key or receiver's public key, but with sender's private key, 409 it has the effect of origin authentication. 411 2. On Authentication: The two entity authentication is considered 412 only bi-lateral authentication and not mutual authentication. Each 413 authentication is verified independently without both client and 414 server contributing to the authentication. When DHCPOFFER is 415 unicast, it can be fragmented and maybe used to carry a certificate. 416 In this case, DHCP client may be able to receive the DHCP server's 417 certificate. Furthermore, the DHCPOFFER may then be signed by 418 server's private key, which also provides the benefit of origin 419 authentication. 421 3. Implementations MUST support the following attribute algorithm 422 values 424 a) Integrity Algorithm 425 i. MD5 426 ii. SHA1 Algorithm Type Value 427 RESERVED 0 428 HASH_MD5 1 429 HASH_SHA1 2 430 HASH_SHA256 3 431 HASH_SHA384 4 432 HASH_SHA512 5 433 Standards Action 6-127 434 Private Use 128-255 435 Unassigned 256-32767 437 b) signature algorithm 438 i. RSA Algorithm Type Value 439 RESERVED 0 440 RSA 1 441 Standards Action 2-127 442 Private Use 128-255 443 Unassigned 256-32767 445 14. IANA Considerations 447 There may be IANA consideration for taking additional value for this 448 option. The values of the protocol field needed to be assigned from 449 the numbering space. 451 15. Acknowledgments 453 Thanks to Eric Chen, Xiangsong Cui and Rock Xie who contributed actively 454 to this document. 456 16. References 458 16.1. Normative References 460 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 461 Requirement Levels", BCP 14, RFC 2119, March 1997. 463 [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", 464 RFC 2131, March 1997. 466 [RFC2132] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor 467 Extensions", RFC 2132, March 1997. 469 [RFC2485] Drach, S., "DHCP Option for The Open Group's User 470 Authentication Protocol", RFC 2485, January 1999. 472 [RFC3118] Droms, R. and W. Arbaugh, "Authentication for DHCP 473 Messages", RFC 3118, June 2001. 475 [RFC3396] Lemon, T. and S. Cheshire, "Encoding Long Options in the 476 Dynamic Host Configuration Protocol (DHCPv4)", RFC 3396, 477 November 2002. 479 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 480 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 482 16.2. Informative References 484 [RFC4246] Dolan, M., "International Standard Audiovisual Number 485 (ISAN) URN Definition", RFC 4246, February 2006. 487 Author's Address 489 Yixian Xu 490 Huawei Technologies 491 Huawei Building, Xinxi Road No.3 492 Haidian District, Beijing 100085 493 P. R. China 495 Phone: +86-10-82836300 496 Email: xuyixian@huawei.com 498 Serge Manning 499 Huawei Technologies 501 Phone: 001-9725435324 502 Email: serge.manning@huawei.com 504 Marcus Wong 505 Huawei Technologies 507 Phone: 001-908-5413505 508 Email: mwong@huawei.com