Hi Alissa, Please see inline.
Cheers, Med > -----Message d'origine----- > De : Alissa Cooper [mailto:[email protected]] > Envoyé : mardi 8 janvier 2019 23:03 > À : The IESG > Cc : [email protected]; Sheng Jiang; softwire- > [email protected]; [email protected]; [email protected] > Objet : Alissa Cooper's Discuss on draft-ietf-softwire-yang-14: (with DISCUSS > and COMMENT) > > 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. > [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. > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > I think "external party" would make more sense than "abuse party." > [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. _______________________________________________ Softwires mailing list [email protected] https://www.ietf.org/mailman/listinfo/softwires
