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

<Steve.Hanna@infineon.com> Wed, 11 July 2018 02:33 UTC

Return-Path: <steve.hanna@infineon.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 F3621130DD9; Tue, 10 Jul 2018 19:33:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.3
X-Spam-Level:
X-Spam-Status: No, score=-4.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=infineon.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 opM0ljcPuoBw; Tue, 10 Jul 2018 19:33:07 -0700 (PDT)
Received: from smtp2.infineon.com (smtp2.infineon.com [IPv6:2a00:18f0:1e00:4::4]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EEE2E12E039; Tue, 10 Jul 2018 19:33:05 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=infineon.com; i=@infineon.com; q=dns/txt; s=IFXMAIL; t=1531276386; x=1562812386; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=HB+/PpFh8tTmlv3INAwiLKxlvmDQ/tlkQJ/XwwrCMCI=; b=WlLHwHCeRAgxUW7l6ov7eyKtMTcKRsdrkfVv0oIttCCzSEaQuU0xV96J 49W7wFkO4pSp8gLCjIOgdW4wBXufGC3Z2JSRj6RH97gdzyyix3o9xtx5O +Drk1ao2EiTIxgUAip6YNL7fyOVZq6/s/gmoDM5gkxkNCtFpu11/YOoBI w=;
X-SBRS: None
X-IronPort-AV: E=McAfee;i="5900,7806,8950"; a="71684845"
X-IronPort-AV: E=Sophos; i="5.51,336,1526335200"; d="scan'208,217"; a="71684845"
Received: from unknown (HELO mucxv003.muc.infineon.com) ([172.23.11.20]) by smtp2.infineon.com with ESMTP/TLS/AES256-GCM-SHA384; 11 Jul 2018 04:33:03 +0200
Received: from MUCSE706.infineon.com (MUCSE706.infineon.com [172.23.7.80]) by mucxv003.muc.infineon.com (Postfix) with ESMTPS; Wed, 11 Jul 2018 04:33:03 +0200 (CEST)
Received: from MUCSE707.infineon.com (172.23.7.81) by MUCSE706.infineon.com (172.23.7.80) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.1.1466.3; Wed, 11 Jul 2018 04:33:03 +0200
Received: from MUCSE707.infineon.com ([172.23.106.27]) by MUCSE707.infineon.com ([172.23.106.27]) with mapi id 15.01.1466.008; Wed, 11 Jul 2018 04:33:03 +0200
From: Steve.Hanna@infineon.com
To: mjethanandani@gmail.com
CC: iesg@ietf.org, secdir@ietf.org, draft-ietf-netmod-acl-model.all@ietf.org
Thread-Topic: Review of draft-ietf-netmod-acl-model-19.txt
Thread-Index: AdQP9Y2jSrah9SdYSKyvzsnOr44HiQItijMAAATugcA=
Date: Wed, 11 Jul 2018 02:33:03 +0000
Message-ID: <d3791f64130a473eb6d3d65694ae817b@infineon.com>
References: <5f33d7efee044a08b51d206b605b945c@infineon.com> <22FA0124-48E4-46D2-B4DA-37DBF840DFC3@gmail.com>
In-Reply-To: <22FA0124-48E4-46D2-B4DA-37DBF840DFC3@gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [172.23.8.247]
Content-Type: multipart/alternative; boundary="_000_d3791f64130a473eb6d3d65694ae817binfineoncom_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/secdir/-bpps6n79PRgNTX39xY477YzTFE>
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:33:09 -0000

Mahesh,

Looks good to me. Those changes will resolve my concerns.

Thanks,

Steve

From: Mahesh Jethanandani <mjethanandani@gmail.com>
Sent: Tuesday, July 10, 2018 10:11 PM
To: Hanna Steve (IFAM CCS SMD AMR) <Steve.Hanna@infineon.com>
Cc: The IESG <iesg@ietf.org>; secdir@ietf.org; draft-ietf-netmod-acl-model.all@ietf.org
Subject: Re: Review of draft-ietf-netmod-acl-model-19.txt

Hi Steve,


On Jun 29, 2018, at 3:12 PM, Steve.Hanna@infineon.com<mailto: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<mailto:mjethanandani@gmail.com>