Internet DRAFT - draft-dong-sacm-nid-cp-security-baseline
draft-dong-sacm-nid-cp-security-baseline
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,
<https://www.rfc-editor.org/info/rfc2119>.
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]
