idnits 2.17.1 draft-lin-sacm-nid-mp-security-baseline-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 : ---------------------------------------------------------------------------- ** There are 14 instances of too long lines in the document, the longest one being 39 characters in excess of 72. ** The abstract seems to contain references ([I-D.ietf-xia-sacm-nid-dp-security-baseline], [I-D.ietf-xia-sacm-nid-app-infr-layers-security-baseline]), 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 == Line 200 has weird spacing: '...-period uin...' == Line 201 has weird spacing: '...ve-time uin...' == Line 205 has weird spacing: '...nterval uint...' == Line 333 has weird spacing: '...ty-name snm...' == Line 336 has weird spacing: '...ty-name snm...' == (11 more instances...) == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (September 7, 2017) is 2421 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: 'I-D.ietf-xia-sacm-nid-dp-security-baseline' is mentioned on line 20, but not defined == Outdated reference: A later version (-21) exists of draft-ietf-netmod-acl-model-11 == Outdated reference: A later version (-32) exists of draft-ietf-netmod-syslog-model-16 Summary: 2 errors (**), 0 flaws (~~), 11 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Security Automation and Continuous Monitoring (SACM) Q. Lin 3 Internet-Draft L. Xia 4 Intended status: Standards Track Huawei 5 Expires: March 11, 2018 September 7, 2017 7 The Data Model of Netork Infrastructure Device Management Plane Security 8 Baseline 9 draft-lin-sacm-nid-mp-security-baseline-00 11 Abstract 13 Network infrastructure devices such as routers, switches are 14 important parts for network security. This document describes 15 security baseline for network infrastructure device management plane, 16 with YANG output, to provide a minimum set of important security 17 management features. The security baselines for control plane, data 18 plane, application layer and infrastructure layer of network 19 infrastructure devices are described in [I-D. ietf-dong-sacm-nid-cp- 20 security-baseline], [I-D.ietf-xia-sacm-nid-dp-security-baseline], [I- 21 D.ietf-xia-sacm-nid-app-infr-layers-security-baseline], respectively. 23 Status of This Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at https://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on March 11, 2018. 40 Copyright Notice 42 Copyright (c) 2017 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (https://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 58 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 3 59 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 60 4. Tree Diagrams . . . . . . . . . . . . . . . . . . . . . . . . 3 61 5. Data Model Structure . . . . . . . . . . . . . . . . . . . . 4 62 5.1. User Interface Security . . . . . . . . . . . . . . . . . 4 63 5.2. Remote Login Security . . . . . . . . . . . . . . . . . . 5 64 5.3. snmp management security . . . . . . . . . . . . . . . . 7 65 5.4. AAA . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 66 5.5. Log Security . . . . . . . . . . . . . . . . . . . . . . 10 67 5.6. File Security . . . . . . . . . . . . . . . . . . . . . . 12 68 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12 69 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 70 8. Security Considerations . . . . . . . . . . . . . . . . . . . 12 71 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 72 9.1. Normative References . . . . . . . . . . . . . . . . . . 12 73 9.2. Informative References . . . . . . . . . . . . . . . . . 13 74 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 76 1. Introduction 78 Securing network infrastructure devices is a challenging and critical 79 task for organizations and operators to preserve the confidentiality, 80 integrity and availability of network and network traffic 81 information. The development and deployment of the security baseline 82 for network infrastructure is needed to provide a solid foundation 83 for the overall network security. 85 To address threats and attacks to network infrastructure devices, 86 different security functions are implemented in application layer, 87 network layer and infrastructure layer. Network layer of network 88 infrastructure devices is typically categorized into three planes of 89 operation, management plane, control plane and data plane. All the 90 planes should be protected and monitored to provide secure network. 92 This document focuses on security baseline for network infrastructure 93 device management plane. Management plane provides configuration and 94 monitoring services of network infrastructure devices. It provides a 95 platform for all the system management traffic. Unauthorized access, 96 using insecure access channels, implementing insecure cryptographic 97 algorithms are common security issues that break management plane 98 security. To enhance security, secure configuration should be 99 implemented to ensure proper configuration and control of network 100 infrastructure devices. A number of security best practices have 101 been proposed, such as disabling unused services and ports, 102 discarding insecure access channels, enforce strong user 103 authentication and authorization, etc. In this document, we propose 104 the most important and universal points of management plane security 105 baseline to provide a minimum set. Thus, future extensibility can be 106 achieved. 108 YANG subscribed notifications via SACM Statements 109 [I-D.ietf-birkholz-sacm-yang-content] defines a method of 110 constructing the YANG data model scheme for the security posture 111 assessment of the network infrastructure device by brokering of YANG 112 push telemetry via SACM statements. In this document, we follow the 113 same way to define the YANG output for network infrastructure device 114 security posture based on the SACM Information Model 115 [I-D.ietf-sacm-information-model]. 117 Besides management plane security baseline, the security baselines 118 for control plane, data plane, application layer and infrastructure 119 layer of network infrastructure devices are described in [I-D.ietf- 120 dong-sacm-nid-cp-security-baseline], [I-D.ietf-xia-sacm-nid-dp- 121 security-baseline], [I-D.ietf-xia-sacm-nid-app-infr-layers-security- 122 baseline], respectively. 124 2. Requirements Language 126 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 127 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 128 document are to be interpreted as described in RFC 2119 [RFC2119]. 130 3. Terminology 132 This document uses the terms defined in YANG - A Data Modeling 133 Language for the Network Configuration Protocol (NETCONF) [RFC6020] . 135 4. Tree Diagrams 137 A simplified graphical representation of the data model is used in 138 this document. The meaning of the symbols in these diagrams is as 139 follows: 141 o Brackets "[" and "]" enclose list keys. 143 o Abbreviations before data node names: "rw" means configuration 144 (read-write) and "ro" state data (read-only). 146 o Symbols after data node names: "?" means an optional node, "!" 147 means a presence container, and "*" denotes a "list" and "leaf- 148 list". 150 o Parentheses enclose choice and case nodes, and case nodes are also 151 marked with a colon (":"). 153 o Ellipsis ("...") stands for contents of subtrees that are not 154 shown. 156 5. Data Model Structure 158 To provide security in management plane of network infrastructure 159 devices, strict access control, secure access channel, implementing 160 secure protocol and cryptographic algorithms, logging system 161 operations and secure file management are needed. 163 The following parts describe several key points of management plane 164 security baseline, such as how to prevent unauthenticated access and 165 SNMP attacks, how to authenticate and authorize user, and how to 166 safely manage device information and files. Both security 167 configuration and runtime state of security controls are included in 168 the following YANG tree diagrams. 170 5.1. User Interface Security 172 User interfaces of network infrastructure devices provide venues for 173 user login and configuration operations. Typically, there are two 174 ways to log in the device, one way is connecting the device directly 175 by console port, another is connecting to the device remotely. Thus, 176 network infrastructure devices support console user interface and 177 virtual type terminal user interface. The security configuration of 178 user interface includes user authentication and authorization. User 179 authentication configuration is to determine which kind of 180 authentication method should be used, such as password only for 181 console login, aaa for remote user login. User authorization 182 configuration is to determine the user with which level of privilege 183 can successfully log into the device. For virtual type terminal user 184 interface, other security controls can be enforced, such as blocking 185 ip addresses after failing authentication, clearing authentication 186 request that has been pending for a certain time when the amount of 187 authentication requests reaches the limit. 189 module:ietf-user-interface-security 190 +--rw user-interface-security 191 +--rw (user-interface-type) 192 +--:(console) 193 | +--rw user-authen-type user-authen-type 194 | +--rw user-level uint8 195 +--:(vty) 196 +--rw user-authen-type user-authen-type 197 +--rw user-level uint8 198 +--rw ip-block? 199 | +--rw ip-failed-times uint8 200 | +--rw ip-failed-period uint8 201 | +--rw ip-reactive-time uint16 202 +--ro ip-block-list*? [blocked-ip] 203 | +--ro blocked-ip inet:ip-address 204 | +--ro blokced-ip-vpn string 205 | +--ro unblocke-interval uint16 206 +--rw request-limit-renew? 207 +--rw pend-time-limit uint8 209 5.2. Remote Login Security 211 There are many access channels such as tlenet, ssh to log in the 212 device through remote connection. For different ways of connection, 213 one common thing is that security configuration need to be enforced. 214 The access requirements of services must be met preferentially based 215 on service requirement analysis. When an access requirement has 216 multiple access channels, the insecure access channels must be 217 discarded and the secure channels must be selected. For example, it 218 is strongly recommended that SSH channel should be used instead of 219 Telnet for remote login, SFTP should be used instead of FTP for file 220 transfer. If insecure access channels have to be used, several 221 security configuration can be enforced to provide basic security 222 control. 224 Access control is an important part in remote login security, 225 different access channels can define different access control 226 policies according to service requirements. Access Control List 227 (ACL) is usually used as a basic element for the forwarding behaviour 228 configuration of network infrastructure devices. In this document, 229 access control list is also used to enforce security policies on 230 network infrastructure devices. Network Access Control List (ACL) 231 YANG Data Model [I-D.ietf-netmod-acl-model] describes the "ietf- 232 access-control-list" module to generally define the commonly used ACL 233 components. The "ietf-remote-login-security" module defined in this 234 section, imports the "ietf-access-control-list" module. The derived 235 type "acl-type" is used. 237 module:ietf-remote-login-security 238 +--rw remote-login-security 239 +--rw (remote-login-channel) 240 +--:(telnet) 241 | +--rw telnet! 242 | +--rw telnet-authen-type user-authen-type 243 | +--rw source-interface? uint16 244 | +--rw {common remote login params} 245 +--:(ftp) 246 | +--rw ftp! 247 | +--rw ftp-authen-type user-authen-type 248 | +--rw ftp-source-interface? 249 | | +--rw ftp-source-ip? inet:ip-address 250 | | +--rw ftp-source-port-type port-type 251 | | +--rw ftp-source-port inet:port-number 252 | +--rw {common remote login params} 253 +--:(ssh) 254 +--rw ssh! 255 +--rw ssh-service-type ssh-service-type 256 +--rw ssh-authen-type ssh-authenn-type 257 +--rw source-interface? uint16 258 +--rw rekey-interval? uint16 259 +--rw authen-retry-times? uint8 260 +--rw ssh-cipher cipher-type 261 +--rw ssh-hmac hmac-type 262 +--rw ssh-key-exchange key-exchange-type 263 +--rw {common remote login params} 265 The "{common remote login params}" are: 267 {common remote login params} 268 +--rw listening-port? inet:port-number 269 +--rw timeout? uint16 270 +--rw acl*? [acl-name acl-type] 271 | +--rw acl-name string 272 | +--rw acl-type acl:acl-type 273 +--rw ip-block? 274 | +--rw ip-failed-times uint8 275 | +--rw ip-failed-period unit8 276 | +--rw ip-reactive-time uint16 277 +--ro ip-block-list? 278 | +--ro blocked-ip inet:ip-address 279 | +--ro blokced-ip-vpn string 280 | +--ro unblocke-interval uint16 281 +--rw login-failed-threshold-alarm? 282 +--rw upper-limit uint8 283 +--rw lower-limit uint8 284 +--rw period uint16 286 5.3. snmp management security 288 Simple Network Management Protocol (SNMP) is a network management 289 standard for monitoring managed network devices. Three SNMP versions 290 are available: SNMPv1, SNMPv2c, and SNMPv3.RFC7407 [RFC7407] (A YANG 291 Data Model for SNMP Configuration) has defined community-based 292 security model for SNMPv1 and SNMPv2c, view-based access control 293 model and user-based security model for SNMPv3. The following module 294 "ietf-snmp-management-security" reuses the security control related 295 submodules defined in RFC7407 for SNMP security configuration. 297 module:ietf-snmp-management-security 298 +--rw snmp-management-security 299 +--rw target* [name] 300 | +--rw name snmp:identifier 301 | +--rw (transport) 302 | | +--:(udp) 303 | | | +--rw udp 304 | | | +--rw ip inet:ip-address 305 | | | +--rw port? inet:port-number 306 | | | +--rw prefix-length? uint8 307 | | +--:(tls) 308 | | | +--rw tls 309 | | | +-- {common (d)tls transport params} 310 | | +--:(dtls) 311 | | | +--rw dtls 312 | | | +-- {common (d)tls transport params} 313 | | +--:(ssh) 314 | | +--rw ssh 315 | | +--rw ip inet:host 316 | | +--rw port? inet:port-number 317 | | +--rw username? string 318 | +--rw tlstm 319 | | +--rw cert-to-name* [id] 320 | | +--rw id uint32 321 | | +--rw fingerprint x509c2n:tls-fingerprint 322 | | +--rw map-type identityref 323 | | +--rw name string 324 | +--rw tag* snmp:identifier 325 | +--rw timeout? uint32 326 | +--rw retries? uint8 327 | +--rw target-params snmp:identifier 328 +--rw target-params* [name] 329 | +--rw name snmp:identifier 330 | +--rw (params)? 331 | +--:(v1) 332 | | +--rw v1 333 | | +--rw security-name snmp:security-name 334 | +--:(v2c) 335 | | +--rw v2c 336 | | +--rw security-name snmp:security-name 337 | +--:(usm) 338 | | +--rw usm 339 | | +--rw user-name snmp:security-name 340 | | +--rw security-level security-level 341 | +--:(tsm) 342 | +--rw tsm 343 | +--rw security-name snmp:security-name 344 | +--rw security-level security-level 345 +--rw community* [index] 346 | +--rw index snmp:identifier 347 | +--rw (name)? 348 | | +--:(text-name) 349 | | | +--rw text-name? string 350 | | +--:(binary-name) 351 | | +--rw binary-name? binary 352 | +--rw security-name snmp:security-name 353 | +--rw engine-id? snmp:engine-id 354 | +--rw context? snmp:context-name 355 | +--rw target-tag? snmp:identifier 356 +--rw vacm 357 | +--rw group* [name] 358 | | +--rw name group-name 359 | | +--rw member* [security-name] 360 | | | +--rw security-name snmp:security-name 361 | | | +--rw security-model* snmp:security-model 362 | | +--rw access* [context security-model security-level] 363 | | +--rw context snmp:context-name 364 | | +--rw context-match? enumeration 365 | | +--rw security-model snmp:security-model-or-any 366 | | +--rw security-level snmp:security-level 367 | | +--rw read-view? view-name 368 | | +--rw write-view? view-name 369 | | +--rw notify-view? view-name 370 | +--rw view* [name] 371 | +--rw name view-name 372 | +--rw include* snmp:wildcard-object-identifier 373 | +--rw exclude* snmp:wildcard-object-identifier 374 +--rw usm 375 | +--rw local 376 | | +--rw user* [name] 377 | | +-- {common user params} 378 | +--rw remote* [engine-id] 379 | +--rw engine-id snmp:engine-id 380 | +--rw user* [name] 381 | +-- {common user params} 382 +--rw tsm 383 +--rw use-prefix? boolean 385 The "{common user params}" are: 387 {common user params} 388 +--rw name snmp:identifier 389 +--rw auth! 390 | +--rw (protocol) 391 | +--:(md5) 392 | | +--rw md5 393 | | +-- rw key yang:hex-string 394 | +--:(sha) 395 | +--rw sha 396 | +-- rw key yang:hex-string 397 +--rw priv! 398 +--rw (protocol) 399 +--:(des) 400 | +--rw des 401 | +-- rw key yang:hex-string 402 +--:(aes) 403 +--rw aes 404 +-- rw key yang:hex-string 406 The "{common (d)tls transport params}" are: 408 {common (d)tls transport params} 409 +--rw ip? inet:host 410 +--rw port? inet:port-number 411 +--rw client-fingerprint? x509c2n:tls-fingerprint 412 +--rw server-fingerprint? x509c2n:tls-fingerprint 413 +--rw server-identity? snmp:admin-string 415 5.4. AAA 417 For user management, AAA provides three types of security services, 418 authentication, authorization and accounting. In AAA user 419 management, RADIUS (Remote Authentication Dial In User Service) or 420 TACACS (Terminal Access Controller Access Control System) can be used 421 for remote authentication and authorization of users. Besides, local 422 authentication can also be used. 424 module:ietf-aaa 425 +--rw aaa 426 +--rw reauthorize! 427 | +--rw user-name string 428 | +--rw user-group-name string 429 +--rw authentication-scheme* [authentication-scheme-name] 430 | +--rw authentication-scheme-name string 431 | +--rw authentication-mode authentication-mode 432 | +--rw authening-fail? 433 | | +--rw authening-fail-action authening-fail-action 434 | | +--rw authening-fail-online-domain? string 435 | +--rw authen-redirect? 436 | | +--rw authen-redirect-domain string 437 | +--rw mac-authentication boolean 438 +--rw authorization-scheme* [authorization-scheme-name] 439 | +--rw authorization-scheme-name string 440 | +--rw authorization-mode authorization-mode 441 | +--rw authorization-cmd-level uint8 442 | +--rw authorization-cmd-no-response 443 | +--rw no-response-action no-response-action 444 | +--rw max-times uint8 445 +--accounting-scheme* [accounting-scheme-name] 446 +--rw accounting-scheme-name string 447 +--rw accounting-mode accounting-mode 448 +--rw accounting-interim-interval 449 +--rw interval uint32 450 +--rw traffic? boolean 451 +--rw hash? boolean 453 5.5. Log Security 455 Logs record information such as user operations on devices and device 456 running status. Stored as log files on devices, logs help network 457 administrators monitor the running status of routers and diagnose 458 network faults. The log records can be outputted to console, or 459 stored locally, or outputted to remote Syslog server. The following 460 defined "ietf-log-security" module reuses the security related 461 submodules of A YANG Data Model for Syslog Configuration 462 [I-D.ietf-netmod-syslog-model], and adds security configurations to 463 provide confidentiality and integrity for locally stored log files. 465 module:ietf-log-security 466 +--rw log-security 467 +--rw (log-mode) 468 +--:(file)? 469 | +--rw user-level-for-read uint8 470 | +--rw log-file-protection-type 471 | +--rw file-encryption? 472 | | +--rw file-encryption-cypher cypher-type 473 | +--rw file-integrity? 474 | +--rw file-integrity-algorithm integrity-algorithm 475 +--:(remote)? 476 ... 477 +--rw (transport) 478 | ... 479 | +--:(tls) 480 | +--rw tls 481 | +--rw server-auth 482 | | +--rw trusted-ca-certs? -> /ks:keystore/trusted-certificates/name 483 | | +--rw trusted-server-certs? -> /ks:keystore/trusted-certificates/name 484 | +--rw client-auth 485 | | +--rw (auth-type)? 486 | | +--:(certificate) 487 | | +--rw certificate? -> /ks:keystore/keys/key/certificates/certificate/name 488 | +--rw hello-params {tls-client-hello-params-config}? 489 | | +--rw tls-versions 490 | | | +--rw tls-version* identityref 491 | | +--rw cipher-suites 492 | | +--rw cipher-suite* identityref 493 | +--rw address? inet:host 494 | +--rw port? inet:port-number 495 +--rw signing-options! {signed-messages}? 496 +--rw cert-signers 497 +--rw cert-signer* [name] 498 | +--rw name string 499 | +--rw certificate? -> /ks:keystore/keys/key/certificates/certificate/name 500 | +--rw hash-algorithm? enumeration 501 +--rw cert-initial-repeat? uint32 502 +--rw cert-resend-delay? uint32 503 +--rw cert-resend-count? uint32 504 +--rw sig-max-delay? uint32 505 +--rw sig-number-resends? uint32 506 +--rw sig-resend-delay? uint32 507 +--rw sig-resend-count? uint32 509 5.6. File Security 511 Patches, packages, configuration files are critical system files for 512 network infrastructure devices. To provide security, only users 513 under certain security levels are allowed to access these files, but 514 cannot delete or modify them. For configuration files, only users 515 with certain configuration rights can modify them. 517 module:ietf-file-security 518 +--rw file-security 519 +--rw user-level-for-read uint8 520 +--rw (file-type) 521 +--:(patch) 522 | +--rw patch-verify-type file-verify-type 523 | +--rw patch-protection-type file-protection-type 524 +--:(package) 525 | +--rw package-verify-type file-verify-type 526 | +--rw package-protection-type file-protection-type 527 +--:(configuration-file) 528 +--rw user-level-for-modify uint8 530 6. Acknowledgements 532 7. IANA Considerations 534 This document requires no IANA actions. 536 8. Security Considerations 538 TBD 540 9. References 542 9.1. Normative References 544 [I-D.ietf-birkholz-sacm-yang-content] 545 Birkholz, H. and N. Cam-Winget, "YANG subscribed 546 notifications via SACM Statements", 2017, 547 . 550 [I-D.ietf-netmod-acl-model] 551 Bogdanovic, D., Jethanandani, M., Huang, L., Agarwal, S., 552 and D. Blair, "Network Access Control List(ACL) YANG Data 553 Model", 2017, . 556 [I-D.ietf-netmod-syslog-model] 557 Wildes, C. and K. Koushik, "A YANG Data Model for Syslog 558 Configuration", 2017, . 561 [I-D.ietf-sacm-information-model] 562 Waltermire, D., Watson, K., Kahn, C., Lorenzin, L., Cokus, 563 M., Haynes, D., and H. Birkholz, "SACM Information Model", 564 2017, . 567 [RFC7407] Bjorklund, M. and J. Schoenwaelder, "A YANG Data Model for 568 SNMP Configuration", RFC 7407, DOI 10.17487/RFC7407, 569 December 2014, . 571 9.2. Informative References 573 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 574 Requirement Levels", BCP 14, RFC 2119, 575 DOI 10.17487/RFC2119, March 1997, 576 . 578 [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for 579 the Network Configuration Protocol (NETCONF)", RFC 6020, 580 DOI 10.17487/RFC6020, October 2010, 581 . 583 Authors' Addresses 585 Qiushi Lin 586 Huawei 587 Huawei Industrial Base 588 Shenzhen, Guangdong 518129 589 China 591 Email: linqiushi@huawei.com 593 Liang Xia 594 Huawei 595 101 Software Avenue, Yuhuatai District 596 Nanjing, Jiangsu 210012 597 China 599 Email: Frank.xialiang@huawei.com