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

ianfarrer@gmx.com Mon, 14 January 2019 17:58 UTC

Return-Path: <ianfarrer@gmx.com>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 651AC1311ED; Mon, 14 Jan 2019 09:58:31 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.598
X-Spam-Level:
X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CGTs8UcaShPn; Mon, 14 Jan 2019 09:58:28 -0800 (PST)
Received: from mout.gmx.net (mout.gmx.net [212.227.15.19]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 441791311E0; Mon, 14 Jan 2019 09:58:27 -0800 (PST)
Received: from ians-mbp.fritz.box ([84.44.210.90]) by mail.gmx.com (mrgmx002 [212.227.17.184]) with ESMTPSA (Nemesis) id 0LtIZH-1hPXvH3M2l-012qRf; Mon, 14 Jan 2019 18:58:24 +0100
From: ianfarrer@gmx.com
Message-Id: <306015DD-737D-4D27-B75C-6B7930948A7F@gmx.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_38C1EFF0-C7E5-4240-8418-90A2D23DB1D3"
Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\))
Date: Mon, 14 Jan 2019 18:58:23 +0100
In-Reply-To: <154687813459.23265.13403466946569558605@ietfa.amsl.com>
Cc: secdir@ietf.org, softwires@ietf.org, draft-ietf-softwire-yang.all@ietf.org, ietf@ietf.org
To: Phillip Hallam-Baker <hallam@gmail.com>
References: <154687813459.23265.13403466946569558605@ietfa.amsl.com>
X-Mailer: Apple Mail (2.3445.102.3)
X-Provags-ID: V03:K1:eiF4DUe+8yk0fcGRzFRPcMYyatS5ZNAR65RWtbQkIu0RxAaXHH1 Y4iIKyM1wRfL+uwXjSFe9SgrGqNPjRiTQgZcjoBKCOVYvmYYplSE2HVTtCZU1gFKI0XYU1b UOypMqb+3+G8FmDv3QXjpFPP5QWpyOeAeyF5XX3YGKGN2qg92V2ZjrPfF/q9b6uHyX0+hJ9 ynHdW5pLgqUJz6QJN1fxw==
X-UI-Out-Filterresults: notjunk:1;V03:K0:6rg9b1Uu9CQ=:yMvTCbhaeDPmzKOYdrLJfL zhQxRl1i0HDqaNhwkaWO77q4msXWQqxK0UohyKiF/cv88pa+rdYmhfbFqpASMaaKdH/xdwfY0 PJCMcEYz9POH9ZiirADa/QbWvkfq5dzHiczAh3GGJOuDevuVd6MiotfakvqnKkkMHevq9Nq1g UqmwPE0u2g+ZdHdatcTarG99FH9qicJR1Gf1127zZTR7i5CtEHSsirfxLGhraBiadzgwrI/No Yj5F8IwnzdlUsn2J7c3ZD/hAFKlDZgcBv6lETocrzQ+bouh3tZ6zyhkUkW3jhDm1yprdn5yTz EJclHiGNY5jxJegTB81vy6AuzEWDTqD9uoxP3LZFU+JhmBwR6oCi/BRrB/WofsCPelmpegb0q MOH2IdtnI1cJqU3tiQ66l3tO4tuuwB5KWderRHjyqLhgwV4F9TPYMooUCGEr56/+1LwAG0k8x QMtA5HD2qI+iyYqCpNUIZBPvBPKrUfCFtLxVsagfvK+EMFiqjpmxdRPDfNvWC5RRNBaRWZTJz IHkt4Lbc+7BAVZjsJAY5gPftmfmToTC5tXcmtDZuAK4dAeKdTnN/dDwgg/YHOvvuoY1VXbfss 11krekieCMHlxi/NUXe+PyVnRfH8qQtHlo1JccMdPBJ+1/2XO23q5G7UMCO2Ns08vRrwxuhFx /blKiInWrUibg61rXy0YqeznRtlpSs1Er8AVvUWbBblLBEoowTbYCWDfXriNu7lpwBfu1A7yb 0LB8l+XRnK1dVS7oVytSez3bDfguVXLmbYeuMfnSLgIsq8HgPHlC1PpzYyBxVYIBd9/Ofb958 GVy6MeQN5Mu5QPPCSmG5auNxD5K5qL3NuRHboxa0zmRX72zKqeFwN3LjlrHMShwtVwh5CDN2A 22oyKm6heP5iC0YnXksu5XLK9D0motGYHYDR3+KfmNiDnfxJDOAZ5QlpeGTcJk
Archived-At: <https://mailarchive.ietf.org/arch/msg/secdir/YGWLCyTBihFwUztV5S0vU2AwlLg>
Subject: Re: [secdir] [Softwires] Secdir last call review of draft-ietf-softwire-yang-14
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/secdir/>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 14 Jan 2019 17:58:31 -0000

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 <hallam@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