Subject: [Softwires] Secdir last call review of draft-ietf-softwire-yang-14

From: Phillip Hallam-Baker <[email-masked]>
Date: Mon, 07 Jan 2019 08:22:14 -0800

Reviewer: Phillip Hallam-Baker
Review result: Has Nits

The document describes a schema and has appropriately identified the read/write
security concerns arising from it.

One issue that I thing could be usefully spelled out is that the use of
automated tools to decode structures of this type is not merely a programming
convenience. Attempts to parse length delimited objects nested in length
delimited structures using handwritten code is error prone and has led to
introduction of numerous buffer overrun vulnerabilities.

---

From: [email-masked]
Date: Mon, 14 Jan 2019 18:58:23 +0100

Hi Phillip,

Thank you for your review and comment.

We’ve re-written the Security Guidelines section following the guidance here: https://trac.ietf.org/trac/ops/wiki/yang-security-guidelines <https://trac.ietf.org/trac/ops/wiki/yang-security-guidelines> and Section 3.7.1 of RFC8407. The proposed text is below.

However, your comment is not really covered by those guidelines, assuming that it is applicable to YANG processing generally, rather than the modules in this draft specifically.  The focus of the security section is more related to configuration and state nodes which the module exposes and threats associated with them rather than how those nodes are accessed.

In existing YANG documents the closest I’ve found is from RFC6020 (and RFC7950) Sec. Considerations:

"YANG parsers need to be robust with respect to malformed documents.
   Reading malformed documents from unknown or untrusted sources could
   result in an attacker gaining the privileges of the user running the
   YANG parser.  In an extreme situation, the entire machine could be
   compromised."

Do you think that this text addresses your comment? If so, I will include a pointer to it.

Thanks,
Ian

9.  Security Considerations

   The YANG modules defined in this document 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 [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.

   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 (i.e., setting 'enable-hairpinning' to
      'false') 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 messages 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.

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

> On 7. Jan 2019, at 17:22, Phillip Hallam-Baker <[email-masked]> wrote:
> 
> _______________________________________________
> Softwires mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/softwires