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 <hal...@gmail.com> 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
