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