Subject: [Softwires] Alissa Cooper's Discuss on draft-ietf-softwire-yang-14: (with DISCUSS and COMMENT)

From: Alissa Cooper <[email-masked]>
Date: Tue, 08 Jan 2019 14:03:12 -0800

Alissa Cooper has entered the following ballot position for
draft-ietf-softwire-yang-14: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-softwire-yang/

----------------------------------------------------------------------
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.

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

I think "external party" would make more sense than "abuse party."

---

From: <[email-masked]>
Date: Fri, 11 Jan 2019 08:05:20 +0000

Hi Alissa, 

Please see inline. 

Cheers,
Med

> -----Message d'origine-----
> De : Alissa Cooper [mailto:[email-masked]]
> Envoyé : mardi 8 janvier 2019 23:03
> À : The IESG
> Cc : [email-masked]; Sheng Jiang; softwire-
> [email-masked]; [email-masked]; [email-masked]
> Objet : Alissa Cooper's Discuss on draft-ietf-softwire-yang-14: (with DISCUSS
> and COMMENT)
> 

[Med] This is fair. We can elaborate as follows: 

   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.

[Med] This information is not revealed to every "external" party but only under some regulatory restrictions when an abuse is reported (check Section 13.1 of RFC6269). 

I changed the text to "a party victim of an abuse". Hope this is better.