IS-IS Working Group S. Litkowski
Internet-Draft Cisco Systems
Intended status: Standards Track D. Yeung
Expires: April 17, 2020 Arrcus, Inc
A. Lindem
Cisco Systems
J. Zhang
Juniper Networks
L. Lhotka
CZ.NIC
October 15, 2019
YANG Data Model for IS-IS Protocoldraft-ietf-isis-yang-isis-cfg-42
Abstract
This document defines a YANG data model that can be used to configure
and manage the IS-IS protocol on network elements.
Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
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 April 17, 2020.
Litkowski, et al. Expires April 17, 2020 [Page 1]

Internet-Draft isis-cfg October 2019
device communicates to the client that it supports the ability to
shutdown a particular IS-IS instance.
The global configuration contains usual IS-IS parameters, such as,
lsp-mtu, lsp-lifetime, lsp-refresh, default-metric, etc.
2.2. Multi-topology Parameters
The model supports multi-topology (MT) IS-IS as defined in [RFC5120].
The "topologies" container is used to enable support of the MT
extensions.
The "name" used in the topology list should refer to an existing
Routing Information Base (RIB) defined for the device [RFC8349].
Some specific parameters can be defined on a per-topology basis, both
at the global level and at the interface level: for example, an
interface metric can be defined per topology.
Multiple address families (such as, IPv4 or IPv6) can also be enabled
within the default topology. This can be achieved using the address-
families container (requiring the "nlpid-control" feature to be
supported).
2.3. Per-Level Parameters
Some parameters allow a per-level configuration. For such
parameters, the parameter is modeled as a container with three
configuration locations:
o a Top-level container: Corresponds to level-1-2, so the
configuration applies to both levels.
o a Level-1 container: Corresponds to level-1 specific parameters.
o a Level-2 container: Corresponds to level-2 specific parameters.
+--rw priority
| +--rw value? uint8
| +--rw level-1
| | +--rw value? uint8
| +--rw level-2
| +--rw value? uint8
Example:
Litkowski, et al. Expires April 17, 2020 [Page 10]

Internet-Draft isis-cfg October 2019
<priority>
<value>250</value>
<level-1>
<value>100</value>
</level-1>
</priority>
An implementation MUST prefer a level-specific parameter over a top-
level parameter. For example, if the priority is 100 for the level-1
and 250 for the top-level configuration, the implementation must use
100 for the level-1 priority and 250 for the level-2 priority.
Some parameters, such as, "overload bit" and "route preference", are
not modeled to support a per-level configuration. If an
implementation supports per-level configuration for such parameter,
this implementation MUST augment the current model by adding both
level-1 and level-2 containers and MUST reuse existing configuration
groupings.
Example of augmentation:
augment "/rt:routing/" +
"rt:control-plane-protocols/rt:control-plane-protocol"+
"/isis:isis/isis:overload" {
when "rt:type = 'isis:isis'" {
description
"This augment IS-IS routing protocol when used";
}
description
"This augments IS-IS overload configuration
with per-level configuration.";
container level-1 {
uses isis:overload-global-cfg;
description
"Level 1 configuration.";
}
container level-2 {
uses isis:overload-global-cfg;
description
"Level 2 configuration.";
}
}
If an implementation does not support per-level configuration for a
parameter modeled with per-level configuration, the implementation
should advertise a deviation to announce the non-support of the
level-1 and level-2 containers.
Litkowski, et al. Expires April 17, 2020 [Page 11]

Internet-Draft isis-cfg October 2019
activation of the functionality on a per-interface basis. The
"mpls/ldp/igp-sync" container in the global configuration is
intentionally empty and is not required for feature activation. The
goal of this empty container is to facilitate augmentation with
additional parameters, e.g., timers.
2.7. ISO parameters
As the IS-IS protocol is based on the ISO protocol suite, some ISO
parameters may be required.
This module augments interface configuration model to support
selected ISO configuration parameters.
The clns-mtu can be configured for an interface.
2.8. IP FRR
This YANG module supports LFA (Loop Free Alternates) [RFC5286] and
remote LFA [RFC7490] as IP Fast Re-Route (FRR) techniques. The
"fast-reroute" container may be augmented by other models to support
other IP FRR flavors (MRT as defined in [RFC7812], TI-LFA as defined
in [I-D.ietf-rtgwg-segment-routing-ti-lfa], etc.).
The current version of the model supports activation of LFA and
remote LFA at the interface-level only. The global "lfa" container
is present but kept empty to allow augmentation with vendor-specific
properties, e.g., policies.
Remote LFA is considered as an extension of LFA. Remote LFA cannot
be enabled if LFA is not enabled.
The "candidate-enable" data leaf designates that an interface can be
used as a backup.
2.9. Operational States
Operational state is defined in module in various containers at
various levels:
o system-counters: Provides statistical information about the global
system.
o interface: Provides configuration state information for each
interface.
o adjacencies: Provides state information about current IS-IS
adjacencies.
Litkowski, et al. Expires April 17, 2020 [Page 20]

Internet-Draft isis-cfg October 2019
o spf-log: Provides information about SPF events for an IS-IS
instance. This SHOULD be implemented as a wrapping buffer.
o lsp-log: Provides information about LSP events for an IS-IS
instance (reception of an LSP or modification of a local LSP).
This SHOULD be implemented as a wrapping buffer and the
implementation MAY optionally log LSP refreshes.
o local-rib: Provides the IS-IS internal routing table.
o database: Provides contents of the current Link State Database.
o hostnames: Provides the system-id to hostname mappings [RFC5301].
o fast-reroute: Provides IP FRR state information.
3. RPC Operations
The "ietf-isis" module defines two RPC operations:
o clear-database: Reset the content of a particular IS-IS database
and restart database synchronization with all neighbors.
o clear-adjacency: Restart a particular set of IS-IS adjacencies.
4. Notifications
The "ietf-isis" module defines the following notifications:
database-overload: This notification is sent when the IS-IS Node
overload condition changes.
lsp-too-large: This notification is sent when the system tries to
propagate a PDU that is too large.
if-state-change: This notification is sent when an interface's
state changes.
corrupted-lsp-detected: This notification is sent when the IS-IS
node discovers that an LSP that was previously stored in the Link
State Database, i.e., local memory, has become corrupted.
attempt-to-exceed-max-sequence: This notification is sent when the
system wraps the 32-bit sequence counter of an LSP.
id-len-mismatch: This notification is sent when we receive a PDU
with a different value for the System ID length.
Litkowski, et al. Expires April 17, 2020 [Page 21]

Internet-Draft isis-cfg October 2019
max-area-addresses-mismatch: This notification is sent when we
receive a PDU with a different value for the Maximum Area
Addresses.
own-lsp-purge: This notification is sent when the system receives
a PDU with its own system ID and zero age.
sequence-number-skipped: This notification is sent when the system
receives a PDU with its own system ID and different contents. The
system has to reissue the LSP with a higher sequence number.
authentication-type-failure: This notification is sent when the
system receives a PDU with the wrong authentication type field.
authentication-failure: This notification is sent when the system
receives a PDU with the wrong authentication information.
version-skew: This notification is sent when the system receives a
PDU with a different protocol version number.
area-mismatch: This notification is sent when the system receives
a Hello PDU from an IS that does not share any area address.
rejected-adjacency: This notification is sent when the system
receives a Hello PDU from an IS but does not establish an
adjacency for some reason.
protocols-supported-mismatch: This notification is sent when the
system receives a non-pseudonode LSP that has no matching protocol
supported.
lsp-error-detected: This notification is sent when the system
receives an LSP with a parse error.
adjacency-state-change: This notification is sent when an IS-IS
adjacency moves to Up state or to Down state.
lsp-received: This notification is sent when an LSP is received.
lsp-generation: This notification is sent when an LSP is
regenerated.
5. Interaction with Other YANG Modules
The "isis" container augments the "/rt:routing/rt:control-plane-
protocols/control-plane-protocol" container of the ietf-routing
[RFC8349] module with IS-IS-specific parameters.
Litkowski, et al. Expires April 17, 2020 [Page 22]

Internet-Draft isis-cfg October 2019
Author: Acee Lindem
<mailto:acee@cisco.com>
Author: Jeffrey Zhang
<mailto:zzhang@juniper.net>
Author: Ladislav Lhotka
<mailto:llhotka@nic.cz>";
description
"This YANG module defines the generic configuration and
operational state for the IS-IS protocol common to all
vendor implementations. It is intended that the module
will be extended by vendors to define vendor-specific
IS-IS configuration parameters and policies,
for example, route maps or route policies.
This YANG model conforms to the Network Management
Datastore Architecture (NMDA) as described in RFC 8242.
Copyright (c) 2018 IETF Trust and the persons identified as
authors of the code. All rights reserved.
Redistribution and use in source and binary forms, with or
without modification, is permitted pursuant to, and subject to
the license terms contained in, the Simplified BSD License set
forth in Section 4.c of the IETF Trust's Legal Provisions
Relating to IETF Documents
(https://trustee.ietf.org/license-info).
This version of this YANG module is part of RFC XXXX
(https://www.rfc-editor.org/info/rfcXXXX); see the RFC itself
for full legal notices.
The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL
NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'NOT RECOMMENDED',
'MAY', and 'OPTIONAL' in this document are to be interpreted as
described in BCP 14 (RFC 2119) (RFC 8174) when, and only when,
they appear in all capitals, as shown here.
This version of this YANG module is part of RFC XXXX;
see the RFC itself for full legal notices.";
revision 2019-10-15 {
description
"Initial revision.";
reference "RFC XXXX";
}
/* Identities */
Litkowski, et al. Expires April 17, 2020 [Page 25]

Internet-Draft isis-cfg October 2019
}
identity unidirectional-link-delay-subtlv-flag {
description "Base identity for unidirectional-link-delay
subTLV flags. Flags are defined in RFC8570.";
}
identity unidirectional-link-delay-subtlv-a-flag {
base unidirectional-link-delay-subtlv-flag;
description
"The A bit represents the Anomalous (A) bit.
The A bit is set when the measured value of
this parameter exceeds its configured
maximum threshold.
The A bit is cleared when the measured value
falls below its configured reuse threshold.
If the A bit is clear,
the value represents steady-state link performance.";
}
identity min-max-unidirectional-link-delay-subtlv-flag {
description
"Base identity for min-max-unidirectional-link-delay
subTLV flags. Flags are defined in RFC8570.";
}
identity min-max-unidirectional-link-delay-subtlv-a-flag {
base min-max-unidirectional-link-delay-subtlv-flag;
description
"The A bit represents the Anomalous (A) bit.
The A bit is set when the measured value of
this parameter exceeds its configured
maximum threshold.
The A bit is cleared when the measured value
falls below its configured reuse threshold.
If the A bit is clear,
the value represents steady-state link performance.";
}
identity unidirectional-link-loss-subtlv-flag {
description "Base identity for unidirectional-link-loss
subTLV flags. Flags are defined in RFC8570.";
}
identity unidirectional-link-loss-subtlv-a-flag {
base unidirectional-link-loss-subtlv-flag;
description
"The A bit represents the Anomalous (A) bit.
The A bit is set when the measured value of
this parameter exceeds its configured
maximum threshold.
Litkowski, et al. Expires April 17, 2020 [Page 28]

Internet-Draft isis-cfg October 2019
The A bit is cleared when the measured value
falls below its configured reuse threshold.
If the A bit is clear,
the value represents steady-state link performance.";
}
identity tlv229-flag {
description "Base identity for TLV229 flags. Flags are defined
in RFC5120.";
}
identity tlv229-overload-flag {
base tlv229-flag;
description
"If set, the originator is overloaded,
and must be avoided in path calculation.";
}
identity tlv229-attached-flag {
base tlv229-flag;
description
"If set, the originator is attached to
another area using the referred metric.";
}
identity router-capability-flag {
description "Base identity for router capability flags.
Flags are defined in RFC7981.";
}
identity router-capability-flooding-flag {
base router-capability-flag;
description
"Quote from RFC7981: 'If the S bit is set,
the IS-IS Router CAPABILITY
TLV MUST be flooded across the entire routing
domain. If the S bit is clear, the TLV MUST NOT
be leaked between levels. This bit MUST NOT
be altered during the TLV leaking'.";
}
identity router-capability-down-flag {
base router-capability-flag;
description
"Quote from RFC7981: 'When the IS-IS Router CAPABILITY TLV
is leaked from level-2 to level-1, the D bit MUST be set.
Otherwise, this bit MUST be clear. IS-IS Router
capability TLVs with the D bit set MUST NOT be
leaked from level-1 to level-2 in to prevent
TLV looping'.";
}
identity lsp-flag {
description "Base identity for LSP attributes.
Litkowski, et al. Expires April 17, 2020 [Page 29]

Internet-Draft isis-cfg October 2019
but on a LAN, the usage will be level 1
between neighbors at level 1 or level 2 between
neighbors at level 2.";
}
leaf hold-timer {
type rt-types:timer-value-seconds16;
units seconds;
description
"The holding time in seconds for this
adjacency. This value is based on
received hello PDUs and the elapsed
time since receipt.";
}
leaf neighbor-priority {
type uint8 {
range "0 .. 127";
}
description
"Priority of the neighboring IS for becoming
the DIS.";
}
leaf lastuptime {
type yang:timestamp;
description
"When the adjacency most recently entered
state 'up', measured in hundredths of a
second since the last reinitialization of
the network management subsystem.
The value is 0 if the adjacency has never
been in state 'up'.";
}
leaf state {
type adj-state-type;
description
"This leaf describes the state of the interface.";
}
description
"List of operational adjacencies.";
}
description
"This container lists the adjacencies of
the local node.";
}
description
"Adjacency state";
}
Litkowski, et al. Expires April 17, 2020 [Page 46]

Internet-Draft isis-cfg October 2019
type uint32;
description
"Number of times a manual address
has been dropped from the area.";
}
leaf max-sequence {
type uint32;
description
"Number of times the system has attempted
to exceed the maximum sequence number.";
}
leaf sequence-number-skipped {
type uint32;
description
"Number of times a sequence number skip has
occurred.";
}
leaf id-len-mismatch {
type uint32;
description
"Number of times a PDU is received with a
different value for the ID field length
than that of the receiving system.";
}
leaf partition-changes {
type uint32;
description
"Number of partition changes detected.";
}
leaf lsp-errors {
type uint32;
description
"Number of LSPs with errors we have received.";
}
leaf spf-runs {
type uint32;
description
"Number of times we ran SPF at this level.";
}
description
"List of supported levels.";
}
description
"List counters for the IS-IS protocol instance";
}
description
"Grouping for IS-IS system counters";
}
Litkowski, et al. Expires April 17, 2020 [Page 68]

Internet-Draft isis-cfg October 2019
grouping event-counters {
container event-counters {
config false;
leaf adjacency-changes {
type uint32;
description
"The number of times an adjacency state change has
occurred on this interface.";
}
leaf adjacency-number {
type uint32;
description
"The number of adjacencies on this interface.";
}
leaf init-fails {
type uint32;
description
"The number of times initialization of this
interface has failed. This counts events such
as PPP NCP failures. Failures to form an
adjacency are counted by adjacency-rejects.";
}
leaf adjacency-rejects {
type uint32;
description
"The number of times an adjacency has been
rejected on this interface.";
}
leaf id-len-mismatch {
type uint32;
description
"The number of times an IS-IS PDU with an ID
field length different from that for this
system has been received on this interface.";
}
leaf max-area-addresses-mismatch {
type uint32;
description
"The number of times an IS-IS PDU has been
received on this interface with the
max area address field differing from that of
this system.";
}
leaf authentication-type-fails {
type uint32;
description
"Number of authentication type mismatches.";
}
Litkowski, et al. Expires April 17, 2020 [Page 69]

Internet-Draft isis-cfg October 2019
If the corresponding IS-IS instance doesn't exist,
then the operation will fail with an error-tag of
'data-missing' and an error-app-tag of
'routing-protocol-instance-not-found'.";
}
leaf level {
type level;
description
"IS-IS level of the adjacency to be cleared. If the
IS-IS level is level-1-2, both level 1 and level 2
adjacencies would be cleared.
If the value provided is different from the one
authorized in the enum type, then the operation
SHALL fail with an error-tag of 'data-missing' and
an error-app-tag of 'bad-isis-level'.";
}
leaf interface {
type if:interface-ref;
description
"IS-IS interface name.
If the corresponding IS-IS interface doesn't exist,
then the operation SHALL fail with an error-tag of
'data-missing' and an error-app-tag of
'isis-interface-not-found'.";
}
}
}
rpc clear-database {
description
"This RPC request clears a particular IS-IS database. If
the operation fails for an IS-IS internal reason, then
the error-tag and error-app-tag should be set
indicating the reason for the failure.";
input {
leaf routing-protocol-instance-name {
type leafref {
path "/rt:routing/rt:control-plane-protocols/"
+ "rt:control-plane-protocol/rt:name";
}
mandatory "true";
description
"Name of the IS-IS protocol instance whose IS-IS
database(s) is/are being cleared.
If the corresponding IS-IS instance doesn't exist,
Litkowski, et al. Expires April 17, 2020 [Page 99]

Internet-Draft isis-cfg October 2019
then the operation will fail with an error-tag of
'data-missing' and an error-app-tag of
'routing-protocol-instance-not-found'.";
}
leaf level {
type level;
description
"IS-IS level of the adjacency to be cleared. If the
IS-IS level is level-1-2, both level 1 and level 2
databases would be cleared.
If the value provided is different from the one
authorized in the enum type, then the operation
SHALL fail with an error-tag of 'data-missing' and
an error-app-tag of 'bad-isis-level'.";
}
}
}
/* Notifications */
notification database-overload {
uses notification-instance-hdr;
leaf overload {
type enumeration {
enum off {
description
"Indicates IS-IS instance has left overload state";
}
enum on {
description
"Indicates IS-IS instance has entered overload state";
}
}
description "New overload state of the IS-IS instance";
}
description
"This notification is sent when an IS-IS instance
overload state changes.";
}
notification lsp-too-large {
uses notification-instance-hdr;
uses notification-interface-hdr;
Litkowski, et al. Expires April 17, 2020 [Page 100]

Internet-Draft isis-cfg October 2019
length "0..255";
}
description
"The system may provide a reason to reject the
adjacency. If the reason is not available,
the reason string will not be returned.
The expected format is a single line text.";
}
description
"This notification is sent when the system receives a
Hello PDU from an IS but does not establish an adjacency
for some reason. The notification generation must be
throttled with at least 5 seconds between successive
notifications.";
}
notification protocols-supported-mismatch {
uses notification-instance-hdr;
uses notification-interface-hdr;
leaf raw-pdu {
type binary;
description "Received raw PDU.";
}
leaf-list protocols {
type uint8;
description
"List of protocols supported by the remote system.";
}
description
"This notification is sent when the system receives a
non-pseudonode LSP that has no matching protocols
supported. The notification generation must be throttled
with at least 5 seconds between successive
notifications.";
}
notification lsp-error-detected {
uses notification-instance-hdr;
uses notification-interface-hdr;
leaf lsp-id {
type lsp-id;
description "LSP ID.";
}
leaf raw-pdu {
type binary;
description "Received raw PDU.";
}
Litkowski, et al. Expires April 17, 2020 [Page 105]

Internet-Draft isis-cfg October 2019
leaf error-offset {
type uint32;
description
"If the problem is a malformed TLV, the error-offset
points to the start of the TLV. If the problem is with
the LSP header, the error-offset points to the errant
byte";
}
leaf tlv-type {
type uint8;
description
"If the problem is a malformed TLV, the tlv-type is set
to the type value of the suspicious TLV. Otherwise,
this leaf is not present.";
}
description
"This notification is sent when the system receives an
LSP with a parse error. The notification generation must
be throttled with at least 5 seconds between successive
notifications.";
}
notification adjacency-state-change {
uses notification-instance-hdr;
uses notification-interface-hdr;
leaf neighbor {
type string {
length "1..255";
}
description
"Name of the neighbor.
It corresponds to the hostname associated
with the system-id of the neighbor in the
mapping database (RFC5301).
If the name of the neighbor is
not available, it is not returned.";
}
leaf neighbor-system-id {
type system-id;
description "Neighbor system-id";
}
leaf state {
type adj-state-type;
description "New state of the IS-IS adjacency.";
}
leaf reason {
type string {
Litkowski, et al. Expires April 17, 2020 [Page 106]

Internet-Draft isis-cfg October 2019
length "1..255";
}
description
"If the adjacency is going to DOWN, this leaf provides
a reason for the adjacency going down. The reason is
provided as a text. If the adjacency is going to UP, no
reason is provided. The expected format is a single line
text.";
}
description
"This notification is sent when an IS-IS adjacency
moves to Up state or to Down state.";
}
notification lsp-received {
uses notification-instance-hdr;
uses notification-interface-hdr;
leaf lsp-id {
type lsp-id;
description "LSP ID";
}
leaf sequence {
type uint32;
description "Sequence number of the received LSP.";
}
leaf received-timestamp {
type yang:timestamp;
description "Timestamp when the LSP was received.";
}
leaf neighbor-system-id {
type system-id;
description "Neighbor system-id of LSP sender";
}
description
"This notification is sent when an LSP is received.
The notification generation must be throttled with at
least 5 seconds between successive notifications.";
}
notification lsp-generation {
uses notification-instance-hdr;
leaf lsp-id {
type lsp-id;
description "LSP ID";
}
Litkowski, et al. Expires April 17, 2020 [Page 107]

Internet-Draft isis-cfg October 2019
leaf sequence {
type uint32;
description "Sequence number of the received LSP.";
}
leaf send-timestamp {
type yang:timestamp;
description "Timestamp when our LSP was regenerated.";
}
description
"This notification is sent when an LSP is regenerated.
The notification generation must be throttled with at
least 5 seconds between successive notifications.";
}
}
<CODE ENDS>
7. Security Considerations
The YANG modules specified in this document define a schema for data
that is designed to be accessed via network management protocols such
as NETCONF [RFC6241] or RESTCONF [RFC8040]. The lowest NETCONF layer
is the secure transport layer, and the mandatory-to-implement secure
transport is Secure Shell (SSH) [RFC6242]. The lowest RESTCONF layer
is HTTPS, and the mandatory-to-implement secure transport is TLS
[RFC8446].
The NETCONF Access Control Model (NACM) [RFC8341] provides the means
to restrict access for particular NETCONF or RESTCONF users to a pre-
configured subset of all available NETCONF or RESTCONF protocol
operations and content.
There are a number of data nodes defined in ietf-isis.yang module
that are writable/creatable/deletable (i.e., config true, which is
the default). These data nodes may be considered sensitive or
vulnerable in some network environments. Write operations (e.g.,
edit-config) to these data nodes without proper protection can have a
negative effect on network operations. Writable data node represent
configuration of each instance and interface. These correspond to
the following schema nodes:
/isis
/isis/interfaces/interface[name]
For IS-IS, the ability to modify IS-IS configuration will allow the
entire IS-IS domain to be compromised including forming adjacencies
with unauthorized routers to misroute traffic or mount a massive
Litkowski, et al. Expires April 17, 2020 [Page 108]

Internet-Draft isis-cfg October 2019
Denial-of-Service (DoS) attack. For example, adding IS-IS on any
unprotected interface could allow an IS-IS adjacency to be formed
with an unauthorized and malicious neighbor. Once an adjacency is
formed, traffic could be hijacked. As a simpler example, a Denial-
Of-Service attack could be mounted by changing the cost of an IS-IS
interface to be asymmetric such that a hard routing loop ensues. In
general, unauthorized modification of most IS-IS features will pose
their own set of security risks and the "Security Considerations" in
the respective reference RFCs should be consulted.
Some of the readable data nodes in the ietf-isis.yang module may be
considered sensitive or vulnerable in some network environments. It
is thus important to control read access (e.g., via get, get-config,
or notification) to these data nodes. The exposure of the Link State
Database (LSDB) will expose the detailed topology of the network.
Similarly, the IS-IS local RIB exposes the reachable prefixes in the
IS-IS routing domain. The Link State Database (LSDB) and local RIB
are represented by the following schema nodes:
/isis/database
/isis/local-rib
Exposure of the Link State Database and local RIB include information
beyond the scope of the IS-IS router and this may be undesirable
since exposure may facilitate other attacks. Additionally, the
complete IP network topology and, if deployed, the traffic
engineering topology of the IS-IS domain can be reconstructed from
the Link State Database. Though not as straightforward, the IS-IS
local RIB can also be discover topological information. Network
operators may consider their topologies to be sensitive confidential
data.
For IS-IS authentication, configuration is supported via the
specification of key-chain [RFC8177] or the direct specification of
key and authentication algorithm. Hence, authentication
configuration using the "auth-table-trailer" case in the
"authentication" container inherits the security considerations of
[RFC8177]. This includes the considerations with respect to the
local storage and handling of authentication keys.
Some of the RPC operations in this YANG module may be considered
sensitive or vulnerable in some network environments. It is thus
important to control access to these operations. The IS-IS YANG
module support the "clear-adjacency" and "clear-database" RPCs. If
access to either of these is compromised, they can result in
temporary network outages be employed to mount DoS attacks.
Litkowski, et al. Expires April 17, 2020 [Page 109]

Internet-Draft isis-cfg October 2019
The actual authentication key data (whether locally specified or part
of a key-chain) is sensitive and needs to be kept secret from
unauthorized parties; compromise of the key data would allow an
attacker to forge IS-IS traffic that would be accepted as authentic,
potentially compromising the entirety IS-IS domain.
The model describes several notifications, implementations must rate-
limit the generation of these notifications to avoid creating
significant notification load. Otherwise, this notification load may
have some side effects on the system stability and may be exploited
as an attack vector.
8. Contributors
The authors would like to thank Kiran Agrahara Sreenivasa, Dean
Bogdanovic, Yingzhen Qu, Yi Yang, Jeff Tanstura for their major
contributions to the draft.
9. Acknowledgements
The authors would like to thank Tom Petch, Alvaro Retana, Stewart
Bryant, Barry Leiba, Benjamin Kaduk and Adam Roach, and Roman Danyliw
for their review and comments.
10. IANA Considerations
The IANA is requested to assign two new URIs from the IETF XML
registry [RFC3688]. Authors are suggesting the following URI:
URI: urn:ietf:params:xml:ns:yang:ietf-isis
Registrant Contact: The IESG
XML: N/A, the requested URI is an XML namespace
This document also requests one new YANG module name in the YANG
Module Names registry [RFC6020] with the following suggestion:
name: ietf-isis
namespace: urn:ietf:params:xml:ns:yang:ietf-isis
prefix: isis
reference: RFC XXXX
11. References11.1. Normative ReferencesLitkowski, et al. Expires April 17, 2020 [Page 110]