Network Working Group Y. Dong Internet-Draft L. Xia Intended status: Standards Track Huawei Expires: March 11, 2018 September 07, 2017 The Data Model of Network Infrastructure Device Control Plane Security Baseline draft-dong-sacm-nid-cp-security-baseline-00 Abstract This document is one of the companion documents which describes the control plane security baseline YANG output for network infrastructure devices. The other parts of the whole document series [I-D.ietf- xia-sacm-nid-dp-security-baseline], [I-D.ietf-lin-sacm- nid-mp-security-baseline], [I-D.ietf-xia-sacm-nid-app-infr-layers- security-baseline] cover other parts of the security baseline for network infrastructure device in data plane, management plane, application layer and infrastructure layer respectively. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on March 11, 2018. Copyright Notice Copyright (c) 2017 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect Dong & Xia Expires March 11, 2018 [Page 1] Internet-DraftNetwork Infrastructure Device Control Plane September 2017 to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1.1. Objective . . . . . . . . . . . . . . . . . . . . . . . . 2 1.2. Security Baseline Data Model Design . . . . . . . . . . . 3 1.3. Summary . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 2.1. Key Words . . . . . . . . . . . . . . . . . . . . . . . . 4 2.2. Definition of Terms . . . . . . . . . . . . . . . . . . . 4 3. Tree Diagrams . . . . . . . . . . . . . . . . . . . . . . . . 4 4. Data Model Structure . . . . . . . . . . . . . . . . . . . . 5 4.1. BGP . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 4.2. OSPF . . . . . . . . . . . . . . . . . . . . . . . . . . 6 4.3. IS-IS . . . . . . . . . . . . . . . . . . . . . . . . . . 7 4.4. MPLS . . . . . . . . . . . . . . . . . . . . . . . . . . 9 4.5. Keychain . . . . . . . . . . . . . . . . . . . . . . . . 11 4.6. GTSM . . . . . . . . . . . . . . . . . . . . . . . . . . 13 5. Network Infrastructure Device Security Baseline Yang Module . 14 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 7. Security Considerations . . . . . . . . . . . . . . . . . . . 14 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 9.1. Normative References . . . . . . . . . . . . . . . . . . 15 9.2. Informative References . . . . . . . . . . . . . . . . . 15 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 1. Introduction 1.1. Objective Nowdays network infrastructure devices such as switches, routers, and firewalls are always under the attack of the well-known network security threats which are sammrized in [I-D.ietf-xia-sacm-dp- security-profile]. Hence it is significant to ensure that the devices in a specific network meet the minimal security requirements according to their intended functions. In this case, the concept of security baseline for the network infrastructure device has been proposed in the above mentioned draft [I-D.ietf-xia-sacm-dp-security- profile] as well. The security baseline refers to the basic and compulsory capabilities of identifying the possible threats and vulnerabilities in the device itself, and enfocing the security hardening measurement. And it could be set to benchmark the security posture of an individual network device. Dong & Xia Expires March 11, 2018 [Page 2] Internet-DraftNetwork Infrastructure Device Control Plane September 2017 Basically, the overall security baseline of a particular network infrastructure device can be designed and deployed into three different layers, namely the application layer, the network layer, and the infrastructure layer. Moreover, the network layer security baseline is further classified into data plane, control plane, and management plane. In this document, we focus on the designation of data model for control plane security baseline while the security baseline of other layers and planes are proposed in the companion documents. The control plane security basedline focus on the control signaling security of the network infrastructure device. The aim is to protect the normal information exchange between devices against various attcks (i.e. eavesdropping, tampering, spoofing and flooding attack) and restrict the malicious control signaling, for ensuring the correct network topology and forwading behavior. 1.2. Security Baseline Data Model Design The security baseline of a certain device is dependent on many factors including but not limited to the different device types (i.e., router, switch, firewall) and their corresponding security features supported, and the specific security requirements of network operators. Owning to such a number of variations, it is impossible to design a comprehensive set of baseline for all devices. This document and the companion ones are going to propose the most important and universal points of them. More points can be added in future following the data model scheme specified in this document. [I-D.ietf-birkholz-sacm-yang-content] defines a method of constructing the YANG data model scheme for the security posture assessment of the network infrastructure device by brokering of YANG push telemetry via SACM statements. The basic steps are: o use YANG push mechanism[I-D.ietf-netconf-yang-push]to collect the created streams of notifications (telemetry) [I-D.ietf-netconf-subscribed-notifications]providing SACM content on SACM data plane, and the filter expressions used in the context of YANG subscriptions constitute SACM content that is imperative guidance consumed by SACM components on SACM management plane; o then encapsulate the above YANG push output into a SACM Content Element envelope, which is again encapsulated in a SACM statement envelope; o lastly, publish the SACM statement into a SACM domain via xmpp- grid publisher. Dong & Xia Expires March 11, 2018 [Page 3] Internet-DraftNetwork Infrastructure Device Control Plane September 2017 In this document, we follow the same way as [I-D.ietf-birkholz-sacm- yang-content] to define the YANG output for network infrastructure device security baseline posture based on the SACM information model definition [I-D.ietf-sacm-information-model]. 1.3. Summary The following contents propose part of the security baseline YANG output for network infrastructure device: control plane security baseline. The companion documents [I-D.ietf- xia-sacm-nid-dp- security-baseline], [I-D.ietf-lin-sacm-nid-mp-security-baseline], [I- D.ietf-xia-sacm-nid-app-infr-layers-security-baseline] cover other parts of the security baseline YANG output for network infrastructure device respectively: control plane security baseline, management plane security baseline, application layer and infrastructure layer security baseline. 2. Terminology 2.1. Key Words The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. 2.2. Definition of Terms This document uses the terms defined in [I-D.draft-ietf-sacm- terminology]. 3. Tree Diagrams A simplified graphical representation of the data model is used in this document. The meaning of the symbols in these diagrams is as follows: o Brackets "[" and "]" enclose list keys. o Abbreviations before data node names: "rw" means configuration (read-write) and "ro" state data (read-only). o Symbols after data node names: "?" means an optional node and "*" denotes a "list" and "leaf-list". o Parentheses enclose choice and case nodes, and case nodes are also marked with a colon (":"). Dong & Xia Expires March 11, 2018 [Page 4] Internet-DraftNetwork Infrastructure Device Control Plane September 2017 o Ellipsis ("...") stands for contents of subtrees that are not shown. 4. Data Model Structure A large amount of control protocols such as the typical TCP/IP stack and BGP in the control plane of network infrastructure device provide many operational services (i.e. farwording behavior control). These control protocols could be either the target under attack or the medium to attack the devices. The security baseline of several widely used protocols are specified in this section. 4.1. BGP In a BGP network, TCP is always selected as the transport layer protocol. Thus it always subject to most of the attacks that targeting TCP-based protocols. In order to secure the BGP network, three types of functions, namely the GTSM, the RPKI, and the BGP peer connection authentication, could be configured in network device. This section specifies the authentication and RPKI configurations. The GTSM is summarized in another individual section together with some other protocols that all supports GTSM. Various kinds of authentication techniques are able to be used for securing the TCP connections between BGP neighbors. They only allows the authorized peers to establish neighbor relationship with local device so that the information exchanged between the BGP neighbors via the TCP connection cannot be altered. The Resource Public Key Infrastructure (RPKI) is usually applied in a network equipt with a RPKI server to secure the inter-domain BGP routing. The device is required to establish a connection to the RPKI server and then downloads or updates the Route Origin Authorizations (ROAs), which links certain IP prefixes or prefix range with an autonomous system (AS), from the RPKI server. After that, the received BGP route information is validated against the downloaded/updated ROAs to verify whether the BGP prefixe originates from the expected AS. module: bgp-sec-config +--rw bgp-rpki | +--rw bgp-rpki-session-config* [session-ipv4-addr] | | +--rw session-ipv4-addr ipv4-address | | +--rw port-number unit16 | | +--rw cipher-password? string | | +--rw aging-time? unit32 | | +--rw refresh-time? unit16 | | +--rw rpki-limit? Dong & Xia Expires March 11, 2018 [Page 5] Internet-DraftNetwork Infrastructure Device Control Plane September 2017 | | +--rw limit unit32 | | +--rw (action-type) | | +--:(alert) | | | +--rw enable boolean | | +--:(idle-forever) | | | +--rw enable boolean | | +--:(idle-timeout) | | +--rw timeout unit16 | +--rw origin-as-validate-utilization | +--rw origin-validation-enable boolean | +--rw origin-as-validate boolean | +--rw allow-invalide boolean | +--rw (peer-identification-method) | +--:(group) | | +--rw peer-group* [group-name] | | +--rw group-name string | | +--rw advertise-enable boolean | +--:(ip) | +--rw peer-ip* [ipv4-addr] | +--rw ipv4-addr ipv4-address | +--rw advertise-enable boolean +--rw bgp-authentication* [bgp-as-number] +--rw bgp-as-number unit16 +--rw (peer-identification-method) +--:(group) | +--rw peer-group* [group-name] | +--rw group-name string | +--rw (authentication-method) | +--:(md5) | | +--rw password-type:{plain|cipher} enumeration | | +--rw password-text string | +--:(keychain) | +--rw keychain-name +--:(ip) +--rw peer-ip* [ipv4-addr] +--rw ipv4-addr inet-type:ipv4-address +--rw (authentication-method) +--:(md5) | +--rw password-type:{plain|cipher} enumeration | +--rw password-text string +--:(keychain) +--rw keychain-name string 4.2. OSPF There are a number of ways for spoofing procotol packet to attack OSPF protocol. One possible scenario is that the rogue device inject manipulated routing information to cause a Denial-of-Service attack. Dong & Xia Expires March 11, 2018 [Page 6] Internet-DraftNetwork Infrastructure Device Control Plane September 2017 Authentication has been demonstrated as a powerful tool to identify and drop these spoofing packets to protect OSPF protocol and secure the connection between the OSPF neighbors. A widely range of authentication methods can be deployed in a network device such as MD5, HAMC-MD5, and keychain. As shown in the following tree diagram, the authentication can be deployed in either area or interface basis. module:ospf-sec-config +--rw ospf-authentication +--rw area-authentication* [area-id] | +--rw area-id unit16 | +--rw (authentication-method) | +--:(simple-authen) | | +--rw password-type:{plain|cipher} enumeration | | +--rw password-text string | +--:(md5-hmac-authen) | | +--rw sub-mode: | | | {md5|hmac-md5|hmac-sha256} enumeration | | +--rw password-type enumeration | | +--rw password-text string | +--:(keychain-authen) | +--rw keychain-name string +--rw interface-authentication* [interface-number] +--rw interface-type enumeration +--rw interface-number unit8 +--rw (authentication-method) +--:(simple-authen) | +--rw password-type enumeration | +--rw password-text string +--:(md5-hmac-authen) | +--rw sub-mode enumeration | +--rw password-type enumeration | +--rw password-text string +--:(keychain-authen) +--rw keychain-name string 4.3. IS-IS IS-IS optional checksum function adds the a checksum TLV in SNP and hello packet. The device firstly check the correctness of checksum TVL when it receive the packet. It secure the data in data link layer. IS-IS authentication encapsulate the authentication information in hello packet, LSP packet, and SNP packet. Only the packets passed the verification will be further processed. The IS-IS authentication is mainly used to secure packet in network layer. Dong & Xia Expires March 11, 2018 [Page 7] Internet-DraftNetwork Infrastructure Device Control Plane September 2017 module:isis-sec-config +--rw isis-optional-checksum | +--rw enable boolean +--rw isis-authentication +--rw area-authentication* [process-id] | +--rw process-id unit32 | +--rw (authentication-method) | +--:(simple) | | +--rw authen-password-mode:{op|osi} enumeration | | +--rw password-type:{plain|cipher} enumeration | | +--rw password-text string | +--:(md5) | | +--rw authen-password-mode:{op|osi} enumeration | | +--rw password-type:{plain|cipher} enumeration | | +--rw password-text string | +--:(keychain) | | +--rw keychain-name string | +--:(hmac-sha256) | | +--rw key-id unit16 | | +--rw password-type:{plain|cipher} enumeration | | +--rw password-text string | +--rw snp-packet: | | {authentication-avoid|send-only} enumeration | +--rw all-send-only? boolean +--rw domain-authentication* [process-id] | +--rw process-id unit32 | +--rw (authentication-method) | +--:(simple) | | +--rw authen-password-mode:{op|osi} enumeration | | +--rw password-type:{plain|cipher} enumeration | | +--rw password-text string | +--:(md5) | | +--rw authen-password-mode:{op|osi} enumeration | | +--rw password-type:{plain|cipher} enumeration | | +--rw password-text string | +--:(keychain) | | +--rw keychain-name string | +--:(hmac-sha256) | | +--rw key-id unit16 | | +--rw password-type:{plain|cipher} enumeration | | +--rw password-text string | +--rw snp-packet enumeration | +--rw all-send-only? boolean +--rw interface-authentication* [interface-number] +--rw interface-type enumeration +--rw interface-number pub-type:ifNum +--rw (authentication-method) +--:(simple) Dong & Xia Expires March 11, 2018 [Page 8] Internet-DraftNetwork Infrastructure Device Control Plane September 2017 | +--rw authen-password-mode:{op|osi} enumeration | +--rw password-type:{plain|cipher} enumeration | +--rw password-text string +--:(md5) | +--rw authen-password-mode:{op|osi} enumeration | +--rw password-type:{plain|cipher} enumeration | +--rw password-text string +--:(keychain) | +--rw keychain-name string +--:(hmac-sha256) | +--rw key-id unit16 | +--rw password-type:{plain|cipher} enumeration | +--rw password-text string +--rw authen-level?:{level1|level2} enumeration +--rw send-only? boolean 4.4. MPLS RSVP authentication is suggested to configure in the device in order to improve the network security and protect the local device against the malicious attack. It prevent the establishment of illegal RSVP peer connection in the following situation The peer was unauthorized to establish connection with local device; The attacker establish connection with locol device via spoofing RSVP packet. Furthermore, it introduce a few enhancement to verify the lifetime, handshake and message window size for protection of RSVP against the playback attack and the termination of authentication relationships caused by packet out of order problem. As shown in the tree diagram, the LDP also support MD5 and keychain authentication. module:mpls-sec-config +--rw rsvp-sec-config | +--rw rsvp-authentication | +--rw interface-authentication | | +--rw interface-authen* [interface-number] | | +--rw interface-type enumeration | | +--rw interface-number pub-type:ifNum | | +--rw (authentication-method) | | +--:(md5) | | | +--rw password-type:{plain|cipher} enumeration | | | +--rw password-text string Dong & Xia Expires March 11, 2018 [Page 9] Internet-DraftNetwork Infrastructure Device Control Plane September 2017 | | +--:(keychain) | | | +--rw keychain-name string | | +--rw life-time? yang-type:timestamp | | +--rw handshake-enable? boolean | | +--rw window-size? unit8 | +--rw peer-authentication | +--rw peer-authen* [peer-addr] | +--rw peer-addr inet-type:ip-address | +--rw (authentication-method) | +--:(md5) | | +--rw password-type:{plain|cipher} enumeration | | +--rw password-text string | +--:(keychain) | | +--rw keychain-name string | +--rw challenge-maximum-miss-times? unit8 | +--rw challenge-retrans-interval? unit16 | +--rw life-time? yang-type:timestamp | +--rw handshake-enable? boolean | +--rw window-size? unit8 +--rw ldp-sec-config +--rw ldp-authentication +--rw (authentication-method) +--:(keychain) | +--rw (authen-object) | +--:(peer-single) | | +--rw single-peer-authen* [peer-id] | | +--rw peer-id dotted decimal | | +--rw keychain-name string | +--:(peer-group) | | +--rw group-peer-authen* [ip-prefix-name] | | +--rw ip-prefix-name string | | +--rw keychain-name string | +--:(peer-all) | +--rw keychain-name string | +--rw exclude-peer-id? dotted decimal +--:(md5) +--rw (authen-object) +--:(peer-single) | +--rw single-peer-authen* [peer-lsr-id] | +--rw peer-lsr-id dotted decimal | +--rw password-type:{plain|cipher} enumeration | +--rw password-text string +--:(peer-group) | +--rw group-peer-authen* [ip-prefix-name] | +--rw ip-prefix-name string | +--rw password-type:{plain|cipher} enumeration | +--rw password-text string +--:(peer-all) Dong & Xia Expires March 11, 2018 [Page 10] Internet-DraftNetwork Infrastructure Device Control Plane September 2017 +--rw password-type:{plain|cipher} enumeration +--rw password-text string 4.5. Keychain Authentication is a widely used technique to ensure the packet information are not been changed/altered by attackers. It requires the information sender and receiver to share the authentication information including the key and algorithm. In addition, the key pairs cannot be delivered in the network (symmetric). However, in order to improve the its reliability, the encryption algorithm and the keys have to be renewed dynamically. It is a complicated and time consuming process to change the keys and algorithm for all the used protocols manually. The keychain provide an solution to renew the authentication keys and algorithm periodically in a dynamic fashion. module:keychain-config +--rw keychain-config* [keychain-name] +--rw keychain-name string +--rw keychain-mode: | {absolute|periodic|daily| | weekly|monthly|yearly} enumeration +--rw receive-tolerance? | +--:(finite) | | +--rw tolerance-value unit16 | +--:(infinite) | +--rw infinite-enable boolean +--rw time-mode:{utc|lmt} enumeration +--rw digest-length? boolean +--rw keychain-id* [key-id] +--rw key-id unit8 +--rw keychain-string-type:{plain|cipher} enumeration +--rw keychain-string-text string +--rw keychain-algorithm: | {hmac-md5|hmac-sha-256|hmac-sha1_12| | hmac-sha1_20|md5|sha-1|sha-256} enumeration +--rw default-key-id? unit8 +--rw (send-time-mode) | +--:(absolute) | | +--rw start-time yang-type:timestamp | | +--rw start-date yang-type:date-and-time | | +--rw (count-type) | | +--:(duration) | | | +--rw (finite-or-infinite) | | | +--:(finite) | | | | +--rw duration-value unit32 | | | +--:(infinite) Dong & Xia Expires March 11, 2018 [Page 11] Internet-DraftNetwork Infrastructure Device Control Plane September 2017 | | | +--rw infinite-enable boolean | | +--:(end) | | +--rw end-time yang-type:timestamp | | +--rw end-date yang-type:date-and-time | +--:(periodic-daily) | | +--rw start-time yang-type:timestamp | | +--rw end-time yang-type:timestamp | +--:(periodic-weekly) | | +--rw (count-type) | | +--:(continues) | | | +--rw start-day-name enumeration | | | +--rw end-day-name enumeration | | +--:(discrete) | | +--rw day-name* enumeration | +--:(periodic-montly) | | +--rw (count-type) | | +--:(continues) | | | +--rw start-date yang-type:date-and-time | | | +--rw end-date yang-type:date-and-time | | +--:(discrete) | | +--rw date* yang-type:date-and-time | +--:(periodic-yearly) | +--rw (count-type) | +--:(continues) | | +--rw start-month enumeration | | +--rw end-month enumeration | +--:(discrete) | +--rw month* enumeration +--rw (receive-time-mode) +--:(absolute) | +--rw start-time yang-type:timestamp | +--rw start-date yang-type:date-and-time | +--rw (count-type) | +--:(duration) | | +--rw (finite-or-infinite) | | +--:(finite) | | | +--rw duration-value unit32 | | +--:(infinite) | | +--rw infinite-enable boolean | +--:(end) | +--rw end-time yang-type:timestamp | +--rw end-date yang-type:date-and-time +--:(periodic-daily) | +--rw start-time yang-type:timestamp | +--rw end-time yang-type:timestamp +--:(periodic-weekly) | +--rw (count-type) | +--:(continues) Dong & Xia Expires March 11, 2018 [Page 12] Internet-DraftNetwork Infrastructure Device Control Plane September 2017 | | +--rw start-day-name enumeration | | +--rw end-day-name enumeration | +--:(discrete) | +--rw day-name* enumeration +--:(periodic-montly) | +--rw (count-type) | +--:(continues) | | +--rw start-date yang-type:date-and-time | | +--rw end-date yang-type:date-and-time | +--:(discrete) | +--rw date* yang-type:date-and-type +--:(periodic-yearly) +--rw (count-type) +--:(continues) | +--rw start-month enumeration | +--rw end-month enumeration +--:(discrete) +--rw month* enumeration 4.6. GTSM Attackers send a large amount of forging packets to a target network device. Then the forging packets are delivered to the cpu straigtforward when the destinations are correctly checked. The CPU will be overloaded owning to processing such a number of protocol packets. In order to protect the CPU against the CPU utilization attack, a GTSM (generized TTL security mechanism) function is configured to check the TTL (time to live) in the IP head. The packets will send to cpu for further processing only if the TTL number is whithin a pre-defined range. As shown in the three diagram in the following figure, the GTSM function is configured separately for individual procotols. Each of the protocols, even each list instances in a protocol, has its own pre-defined TTL range. Dong & Xia Expires March 11, 2018 [Page 13] Internet-DraftNetwork Infrastructure Device Control Plane September 2017 module:gtsm +--rw gtsm-config +--rw default-gtsm-action:{drop|pass} +--rw bgp-gtsm* [bgp-as-number] | +--rw bgp-as-number unit32 | +--rw (peer-identification-method) | +--:(group) | | +--rw peer-group* [group-name] | | +--rw group-name string | | +--rw valid-ttl-hops unit16 | +--:(ip) | +--rw peer-ip* [ipv4-addr] | +--rw ipv4-addr inet-type:ipv4-address | +--rw valid-ttl-hops unit8 +--rw ospf-gtsm* [vpn-instance-name] | +--rw vpn-instance-name string | +--rw valid-ttl-hops unit16 +--rw mpls-ldp-gtsm* [peer-ip-addr] | +--rw peer-ip-addr inet-type:ip-address | +--rw valid-ttl-hops unit16 +--rw rip-gtsm* [vpn-instance-name] +--rw vpn-instance-name? string +--rw valid-ttl-hops unit16 5. Network Infrastructure Device Security Baseline Yang Module TBD 6. IANA Considerations This document makes no request of IANA. Note to RFC Editor: this section may be removed on publication as an RFC. 7. Security Considerations TBD. 8. Acknowledgements TBD 9. References Dong & Xia Expires March 11, 2018 [Page 14] Internet-DraftNetwork Infrastructure Device Control Plane September 2017 9.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . 9.2. Informative References [I-D.ietf-netconf-subscribed-notifications] Voit, E., Clemm, A., Prieto, A., Nilsen-Nygaard, E., and A. Tripathy, "Custom Subscription to Event Notifications", draft-ietf-netconf-subscribed-notifications-03 (work in progress), July 2017. [I-D.ietf-netconf-yang-push] Clemm, A., Voit, E., Prieto, A., Tripathy, A., Nilsen- Nygaard, E., Bierman, A., and B. Lengyel, "Subscribing to YANG datastore push updates", draft-ietf-netconf-yang- push-08 (work in progress), August 2017. [I-D.ietf-sacm-information-model] Waltermire, D., Watson, K., Kahn, C., Lorenzin, L., Cokus, M., Haynes, D., and H. Birkholz, "SACM Information Model", draft-ietf-sacm-information-model-10 (work in progress), April 2017. Authors' Addresses Yue Dong Huawei Email: dongyue6@huawei.com Liang Xia Huawei Email: frank.xialiang@huawei.com Dong & Xia Expires March 11, 2018 [Page 15]