Alissa Cooper - Discuss

[iffy50]

---

DISCUSS:

The security considerations do not seem to follow the YANG security guidelines
https://trac.ietf.org/trac/ops/wiki/yang-security-guidelines. They do not
list the specific writeable and readable subtrees/nodes and why they are
sensitive. The fact that all the writeable nodes could "negatively affect
network operations" seems trivially true for most writeable YANG module nodes.
In the case of these modules, there seem to be multiple different threats
relevant to different nodes, including exposure of data about individual
users/customers, potential for disruption of the operations of the BR or CE,
etc.

[boucadair]

Added this text:

All data nodes defined in the YANG modules which can be created,
modified, and deleted (i.e., config true, which is the default) are
considered sensitive. Write operations (e.g., edit-config) applied
to these data nodes without proper protection can negatively affect
network operations. An attacker who is able to access the BR can
undertake various attacks, such as:

o Setting the value of 'br-ipv6-addr' on the CE to point to an
illegitimate BR so that it can intercept all the traffic sent by a
CE. Illegitimately intercepting users' traffic is an attack with
severe implications on privacy.

o Setting the MTU to a low value, which may increase the number of
fragments ('softwire-payload-mtu').

o Disabling hairpinning ('enable-hairpinning') to prevent
communications between CEs.

o Setting 'softwire-num-max' to an arbitrary high value, which may
be exploited by a misbehaving user to perform a DoS on the binding
BR by mounting a massive number of softwires.

o Setting 'icmpv4-rate' or 'icmpv6-rate' to a low value, which may
lead to the deactivation of ICMP message handling.

o Accessing to privacy data maintained by the BR (e.g., the binding
table or the algorithm configuration). Such data can be misused
to track the activity of a host.

o Instructing the BR to install entries which in turn will induce a
DDoS attack by means of the notifications generated by the BR.
This DDoS can be softened by defining a notification interval, but
given that this interval parameter can be disabled or set to a low
value by the misbehaving entity, the same problem will be
observed.

[iffy50]

Here's the text that I wrote for this. If Med's version is acceptable, then I'm happy to go with that, but this is here if we need it:

The YANG module specified in this document defines 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 [RFC 8446].

The Network Configuration Access Control Model (NACM) [RFC8341] provides the means to restrict access
for particular NETCONF or RESTCONF users to a preconfigured subset of all available NETCONF or
RESTCONF protocol operations and content.

There are a number of data nodes defined in this 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. These are the subtrees and data nodes
and their sensitivity/vulnerability:

In the "ietf-softwire-ce" module:

/softwire-payload-mtu

/softwire-payload-mtu

Setting either of these nodes to a low value could result in the
need to fragment softwire traffic resultng in execesive
fragmentation processing and potential denial-of-service.

/binding/br-ipv6-addr/

/algo/algo-instances/algo-instance/encapsulation/br-ipv6-addr/

/algo/algo-instances/algo-instance/translation/dmr-ipv6-prefix/

The values of the above nodes could be changed to redirect all of the client's
traffic through an illigitamate BR, allowing the traffic to be
intercepted or otherwise interferred with.

/binding/binding-ipv6info

/algo/algo-instances/algo-instance/

The values of nodes in the above subtrees could be altered to create invalid
encapsulated packets (e.g. with an invalid source IPv4 address), which would
be dropped by the BR.

In the "ietf-softwire-br" module:

/br-instances/binding/binding-instance/softwire-payload-mtu
/br-instances/binding/binding-instance/softwire-path-mru

Setting either of these nodes to a low value could result in the
need to fragment softwire traffic resultng in execesive
fragmentation processing and potential denial-of-service.
***** NB - for some reason, we don't have the values for algo BRs. *****

/br-instances/binding/binding-instance/

/algorithm/algorithm-instance/

The values of the above nodes could be changed to reject or redirect all,
or individual client's traffic, or could be used to redirect traffic
destined to multiple hosts to a single host as a DOS attack.

Security considerations related to lw4o6, MAP-T and MAP-E are discussed in [RFC7596],
[RFC7597], and [RFC7599] respectively.