Re: [netmod] WG Last Call: draft-ietf-netmod-acl-model-15

Robert Wilton <> Fri, 02 February 2018 09:53 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id B138112FA97 for <>; Fri, 2 Feb 2018 01:53:09 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -14.511
X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id MYRxgQAqSw1X for <>; Fri, 2 Feb 2018 01:53:08 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id B8AE4127873 for <>; Fri, 2 Feb 2018 01:53:07 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; l=3155; q=dns/txt; s=iport; t=1517565187; x=1518774787; h=subject:to:references:from:message-id:date:mime-version: in-reply-to:content-transfer-encoding; bh=Hb9inp3yIAnRGg1zexPAPoqsYeVklBF2dQLL2xmEySQ=; b=T0zzQzrOW33orpN8wQ+aGWTUdeIMh24yoUg59+zdpiQ5IOtXtj7zuGKi BSE58MrGyNICukJqB7qTfgg9NAjKqNsKz+4iDv2vJzhO9iTJ42VZaC5b4 rfKDDWUnvveNuDX6hzSDUKrEwWUuSC+rUUmdUA56XSqMBUyeMSsNCW3oE w=;
X-IronPort-AV: E=Sophos;i="5.46,448,1511827200"; d="scan'208";a="1809756"
Received: from (HELO ([]) by with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 02 Feb 2018 09:53:06 +0000
Received: from [] ( []) by (8.14.5/8.14.5) with ESMTP id w129r5UP012750; Fri, 2 Feb 2018 09:53:05 GMT
To: Eliot Lear <>, Kristian Larsson <>,
References: <> <20180117224916.4xtwnxgsw3snzwvf@elstar.local> <> <> <> <> <> <> <> <>
From: Robert Wilton <>
Message-ID: <>
Date: Fri, 02 Feb 2018 09:53:05 +0000
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.5.2
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Content-Language: en-US
Archived-At: <>
Subject: Re: [netmod] WG Last Call: draft-ietf-netmod-acl-model-15
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 02 Feb 2018 09:53:10 -0000

On 02/02/2018 07:48, Eliot Lear wrote:
> Hi Kristian,
> On 02.02.18 08:44, Kristian Larsson wrote:
>> Mahesh,
>> I've reviewed this model, I think I largely caused the last couple of
>> updates to it late last year. Overall I think it is a good model.
>> Placement of feature-statements could be debated - no clear answers.
>> object groupings is something I would like to see in the model but it
>> was always deferred.
>> On 2018-01-22 16:50, Kent Watsen wrote:
>>> Hi Mahesh,
>>> Thanks, it doesn't get much more concrete then a pull request  ;)
>>> Okay, so from a chair/shepherd perspective, can folks please consider
>>> this update to -15 as the LC solution to removing the open issue
>>> Juergen found in the draft?
>>> As a contributor, I don't think the name of the groupings or their
>>> description statements should allude to something that doesn't exist
>>> yet.  Rather than e.g. "source-or-group", could it be instead
>>> something like "source-type"?
>> +1
>>> Also, the update seems to be for both when specifying networks as
>>> well as when specifying port-ranges, but the original issue (see
>>> below) only mentioned addresses - is the pull-request actually what's
>>> needed and the description of the issue in Section 8 is incomplete?
>>>       8.  Open Issues
>>>          o  The current model does not support the concept of
>>> "containers"
>>>               used to contain multiple addresses per rule entry.
>> Object groupings are useful whenever there are many of something.
>> There are usually more address entries than ports, so perhaps more
>> useful for addresses, but it can still be useful to say "NFS-PORTS"
>> and mean all the ports that NFS use (god knows what they are).
>> Other have mentioned scale ACL and that it can be solved in other
>> ways. To me, this sort of object-groupings is not about optimising
>> things for the hardware but rather making it easy for me to write
>> rules. I think it is paramount for security that ACLs can be easily
>> read and understood. If we do not understand them, then we cannot say
>> they are effective and secure. Object groupings greatly improves the
>> readability of ACLs and thus makes it easier to write secure ACLs.
>> I understand the authors wishes to get the first version out the door
>> but I can't help but wonder if it isn't just easier to add in object
>> groupings now. It's not that damn complicated (they are just lists).
>> If not, I'm happy to work with them on the next version which could
>> include object groupings.
> Please let's aim for the next version.  This document just completed
> what I think is its FIFTH last call, which to me is nothing short of insane.
+1 for publishing the draft now.

If there are further bells and whistles that need to be added then 
ideally they would be covered by an ACL-extensions model that augments 
the base ACL model.  If tweaks are required to the base model to achieve 
it then I think that creating a v2 version of the ACL model is also OK.