Re: [netmod] IETF ACL model

Robert Wilton <> Mon, 27 November 2017 15:00 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 0D86D128796 for <>; Mon, 27 Nov 2017 07:00:42 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -14.501
X-Spam-Status: No, score=-14.501 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, 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 SUejrfHHipoa for <>; Mon, 27 Nov 2017 07:00:40 -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 280A5124F57 for <>; Mon, 27 Nov 2017 07:00:40 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; l=3470; q=dns/txt; s=iport; t=1511794840; x=1513004440; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=/uQMyKohskeQyv7ZbC1MqUjT1IZvRVh2D0WDGOjPFn4=; b=GFeAXox60VLV2QOzxp1Pek8ci41BFmTr3/CawgCESOF3daS4b/KTQebo vuGQGZwpkfF0NCAsMEimx45wMSK9SG2wKwAc8JoY/5M56eGj1gPBKo+Ua aluzDbfEEX07DlAbYusaFT56SBfLXJQOg3sCWanfV/J8QxjqSGZYDq4Ai s=;
X-IronPort-AV: E=Sophos;i="5.44,465,1505779200"; d="scan'208";a="504084"
Received: from (HELO ([]) by with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 27 Nov 2017 15:00:38 +0000
Received: from [] ( []) by (8.14.5/8.14.5) with ESMTP id vARF0c9V023746; Mon, 27 Nov 2017 15:00:38 GMT
To: Kristian Larsson <>
Cc: Martin Bjorklund <>,,,,,
References: <> <> <> <> <> <>
From: Robert Wilton <>
Message-ID: <>
Date: Mon, 27 Nov 2017 15:00:38 +0000
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0
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] IETF ACL model
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: Mon, 27 Nov 2017 15:00:42 -0000

On 27/11/2017 13:17, Kristian Larsson wrote:
> Robert Wilton <> writes:
>> Thinking about this some more. I'm not sure what it means for the "ACL
>> Type" to be "any-acl". It seems that the "match any packet" should be a
>> type of ACE, e.g. perhaps as the last entry of an ACL, rather than a
>> type of ACL.
> Yes, I agree as so far that any-acl makes no sense as an acl-type. The
> way I understood acl-type, and the way that vendors have told me it will
> be used, is to say "this is an IPv4 ACL" and then on an attachment point
> you can specify that only ACLs of acl-type ipv4-acl can be attached to
> the interface. That makes perfect sense. I do not see how any-acl can
> map into this.
> I agree that any-acl is logically a type of ACE but we don't have an
> ace-type and the exact same information can IMHO already be conveyed
> WITHOUT the any-acl type and thus it has no reason to exist. Nor do we
> need a feature for it.
> >From what I can tell the any-acl container in the ACE should be used to
> explicitly signify a match on "any". Think of IOS style ipv4 acl:
>    permit ip any any
> We have to provide a source and destination so this would be a rather
> explicit mapping of that. However, our structure in this YANG model is
> just completely different than an IOS command so I don't see why we
> should try and mimic IOS in the YANg model.
> Not specifying a destination IP address means we match on any
> destination IP address. The same is true for any other field we can
> match on. Not setting a match implies we don't try to match on that
> field, thus we allow "any" value. I think the logical continuation of
> this is that for an ACE with no matches defined at all, we match any
> packet. I think we can update the text to better explain this.

>> Otherwise if the ACL type is "any-acl" then this only allows two types
>> of ACLs to be defined, neither of which seem to be particularly useful:
>> (1) An ACL that matches all traffic and permits it, i.e. the same as
>> having no ACL at all.
>> (2) An ACL that matches all traffic and drops.
>> So I think perhaps the answer here is to define neither ACL type
>> "any-acl" nor leaf "any". The presumption could be that any ACE that is
>> configured to match no fields implicitly matches all packets (because
>> all non specified fields are treated as wildcards), and then applies the
>> permit/deny rule associated with the ACE. This logic can apply to all
>> ACL types.
> Yes yes yes :)
Another area of the current model that I'm not quite convinced about is 
about the L4 matches (UDP, TCP, ICMP).

Currently the model assumes that if a device can support matching on say 
UDP fields that they can apply to any type of ACL.  However, I think 
that it is plausible that the UCP, TCP and ICMP fields might only apply 
to IP ACLs and not Ethernet ACLs.

Hence, I was wondering if there should be "acl match type" identity 
defined for the "l4" field matches?

This would then cause there to be twice as many ACL types identities and 
features defined, e.g.


So, trading off my ACL type combinations for more expressiveness as to 
what can actually be supported.


>     Kristian.
> .