Re: [secdir] Review of draft-ietf-netmod-acl-model-19.txt

Mahesh Jethanandani <mjethanandani@gmail.com> Wed, 11 July 2018 02:11 UTC

Return-Path: <mjethanandani@gmail.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 4E1C0130DD6; Tue, 10 Jul 2018 19:11:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 HecG8wGJdQ1o; Tue, 10 Jul 2018 19:11:31 -0700 (PDT)
Received: from mail-pl0-x242.google.com (mail-pl0-x242.google.com [IPv6:2607:f8b0:400e:c01::242]) (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 5410712E039; Tue, 10 Jul 2018 19:11:31 -0700 (PDT)
Received: by mail-pl0-x242.google.com with SMTP id a17-v6so2598008plm.12; Tue, 10 Jul 2018 19:11:31 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=U7jMd0VEur2N8ccCfvW3PqmeV3tmHl1og1tbuB/8vK8=; b=t+RWotPVE3f31RfaS9cZOkagnq1ofqWBXwb6GJ+XjMAwOcr+FLtkg8S2CywgqnC3+3 TADY6qYhL0RRzXvvUcWkC7vRCKe/wpW1SZblzM8t+9jg93P3ej6Yy1txpRTcgf3xuocS ZybXbWc6cEbGdr24uixmHMmJyV54iZNYgZbCDIiqRxH76TLJ7ic9Lkyjp0X06S7YB5uh bsKOn4AVjsUW4eenoRHrZMcG8Mt2rn2K8JP2dDp5Pd3h9pB4Xh7z3L7lk9Q8IHdGh9pt D1oGxe0Wl793vUn9SUii/ObWQG/xWy+YgKJACnDkvUxOuC/B3Wogld0b/koDcEbmxC91 nUcg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=U7jMd0VEur2N8ccCfvW3PqmeV3tmHl1og1tbuB/8vK8=; b=j5Hvud692e5BzvZ8Cwy1qPjhaJPydtr3QmWvgw5n6Z4W5DNo+L9WRUPazyw6u+C6ez MlzqI0ZsUUIszvJbdm0gFfcc3ZqSsDd9vDmrKcKhpcDIRyLi33HBZCyWBLj9GSAxdsZ8 YQJrtHcbFh1RZJPwxiugZ1SpNktY9m5ioWfoJ3xbbt7bA/LQafffqJ3Xd5QeAM2oyFYn VG4c6CKof2skSpoIx9LlPF53/XEAr7psvMA5CBcagLdiMSkrZw5si4d8PmYk9/sL7YIo mVNp5S92x8dw3k6T+v7UTx6PaKPT5aYIwjvTZYm/W1W3X1Af+5z0LyY2MFJZZGwlqLF4 ybMQ==
X-Gm-Message-State: APt69E02DJqXbmTVIjBauOog+xITF5w0vg/rKDYWHglFo7LnGAEGjESb jkwAYE/aYVkb259ifCIKan8=
X-Google-Smtp-Source: AAOMgpcgKotx6Ng7Xi8uGYni/tIWXXRTTNhH/9G3GGx131yDKJZcTmBh9Ffye++8KXdCY3JAVcHpzw==
X-Received: by 2002:a17:902:1007:: with SMTP id b7-v6mr26618730pla.277.1531275090900; Tue, 10 Jul 2018 19:11:30 -0700 (PDT)
Received: from ?IPv6:2601:647:4700:1280:816f:61c5:5a86:f7b1? ([2601:647:4700:1280:816f:61c5:5a86:f7b1]) by smtp.gmail.com with ESMTPSA id k16-v6sm4602062pfb.93.2018.07.10.19.11.29 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 10 Jul 2018 19:11:29 -0700 (PDT)
From: Mahesh Jethanandani <mjethanandani@gmail.com>
Message-Id: <22FA0124-48E4-46D2-B4DA-37DBF840DFC3@gmail.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_28A91719-5742-4315-91AD-A7FBE84C27FB"
Mime-Version: 1.0 (Mac OS X Mail 11.4 \(3445.8.2\))
Date: Tue, 10 Jul 2018 19:11:28 -0700
In-Reply-To: <5f33d7efee044a08b51d206b605b945c@infineon.com>
Cc: The IESG <iesg@ietf.org>, secdir@ietf.org, draft-ietf-netmod-acl-model.all@ietf.org
To: Steve.Hanna@infineon.com
References: <5f33d7efee044a08b51d206b605b945c@infineon.com>
X-Mailer: Apple Mail (2.3445.8.2)
Archived-At: <https://mailarchive.ietf.org/arch/msg/secdir/bfdt_tO4ri2uT0L7s6Oj-s6b-eU>
Subject: Re: [secdir] Review of draft-ietf-netmod-acl-model-19.txt
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.27
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: Wed, 11 Jul 2018 02:11:34 -0000

Hi Steve,

> On Jun 29, 2018, at 3:12 PM, Steve.Hanna@infineon.com wrote:
> 
> I have reviewed this document as part of the security directorate's
> ongoing effort to review all IETF documents being processed by the
> IESG. These comments were written primarily for the benefit of the
> security area directors. Document editors and WG chairs should treat
> these comments just like any other last call comments.
> 
> The summary of the review is Ready with issues.
> 
> This document defines a YANG data model for ACL. When the term
> "ACL" is used in this document it means the sort of ACL that
> you might see in firewall rules (e.g., "drop IPv4 traffic with
> destination port 21").
> 
> *Overall Clarity and Quality*
> 
> The document is fairly clear and well written. However, there
> is a confusing typo that is listed in the Minor Errors section
> of this review.
> 
> *Security Analysis*
> 
> The Security Considerations section is brief but decent.
> However, the last two sentences are unclear and maybe wrong:
> 
>   Unauthorized write access to this list can allow intruders
>   to access and control the system. Unauthorized read access
>   to this list can allow intruders to spoof packets with
>   authorized addresses thereby compromising the system.
> 
> Which "system" is referred to here? Whatever the answer to
> that question, I believe that the main impact of unauthorized
> write access to the ACL is that the attacker can modify the
> ACL to permit traffic that should not be permitted or deny
> traffic that should be permitted. The former may result in
> denial of service or compromise of systems on the network.
> The latter may result in denial of service. The main impact
> of unauthorized read access to the ACL is that the attacker
> can determine what ACL rules are in effect and may be able
> to use this information to better craft an attack.

Ok. How about this?

OLD:
      /acls/acl/aces: This list specifies all the configured access
      control entries on the device.  Unauthorized write access to this
      list can allow intruders to access and control the system.
      Unauthorized read access to this list can allow intruders to spoof
      packets with authorized addresses thereby compromising the system.


NEW:
              /acls/acl/aces: This list specifies all the configured access
      control entries on the device.  Unauthorized write access to this
      list can allow intruders to modify the entries so as to permit traffic
      that should not be permitted, or deny traffic that should be permitted.
      The former may result in a DoS attack, or compromise the device.
      The latter may result in a DoS attack. The impact of an unauthorized 
      read access to the list will allow the attacker to determine which rules
      are in effect, to better craft an attack.


> 
> *Minor Errors*
> 
> Section 3 refers to "action criteria". Every other part of
> the specification refers only to "action" or "actions".
> My review of the specification indicates that this text
> in section 3 should say "actions" not "action criteria”.

There are three instances of “action criteria” in the document. But you point is well taken, they can all be changed to “action” or “actions”.

Cheers.

> 

Mahesh Jethanandani
mjethanandani@gmail.com