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

[ianfarrer]

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 
 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  wrote:
> 
> 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.
> 
> ___
> Softwires mailing list
> Softwires@ietf.org
> https://www.ietf.org/mailman/listinfo/softwires

___
Softwires mailing list
Softwires@ietf.org
https://www.ietf.org/mailman/listinfo/softwires

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

[Phillip Hallam-Baker]

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.

___
Softwires mailing list
Softwires@ietf.org
https://www.ietf.org/mailman/listinfo/softwires