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

Kristian Larsson <> Fri, 03 November 2017 08:42 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id B126313FD07 for <>; Fri, 3 Nov 2017 01:42:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id DS1ABC-9q8lJ for <>; Fri, 3 Nov 2017 01:42:34 -0700 (PDT)
Received: from Mail2.SpriteLink.NET (Mail2.SpriteLink.NET []) by (Postfix) with ESMTP id 1350E13FD06 for <>; Fri, 3 Nov 2017 01:42:34 -0700 (PDT)
Received: from localhost (localhost []) by Mail2.SpriteLink.NET (Postfix) with ESMTP id 44D12261846; Fri, 3 Nov 2017 09:42:35 +0100 (CET)
X-Virus-Scanned: amavisd-new at SpriteLink.NET
Received: from Mail2.SpriteLink.NET ([]) by localhost (Mail2.SpriteLink.NET []) (amavisd-new, port 10024) with ESMTP id AR2khmS6boop; Fri, 3 Nov 2017 09:42:33 +0100 (CET)
Received: from localhost (Mission-Control.SpriteLink.NET []) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: kristian@SpriteLink.NET) by Mail2.SpriteLink.NET (Postfix) with ESMTPSA id 0F34E261838; Fri, 3 Nov 2017 09:42:33 +0100 (CET)
Date: Fri, 03 Nov 2017 09:42:31 +0100
From: Kristian Larsson <>
To: Robert Wilton <>
Cc: Martin Bjorklund <>,,
Message-ID: <>
References: <> <> <> <> <> <> <>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <>
User-Agent: Mutt/1.5.23 (2014-03-12)
Archived-At: <>
Subject: Re: [netmod] WG Last Call: draft-ietf-netmod-acl-model-14
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, 03 Nov 2017 08:42:37 -0000

On Thu, Nov 02, 2017 at 05:38:02PM +0000, Robert Wilton wrote:
> On 02/11/2017 16:41, Kristian Larsson wrote:
> >On Thu, Nov 02, 2017 at 12:53:29PM +0000, Robert Wilton wrote:
> >>   feature mixed-ipv4-acl {
> >>     if-feature "match-on-l2-eth-hdr and "match-on-ipv4-hdr";
> >>     description "Layer 2 and Layer 3 IPv4 ACL supported";
> >>   }
> >>   ...
> >Features dependent on features... inception. I didn't even know
> >this was possible with YANG. Learned something today \o/
> This just means that a device cannot say that it supports a "mixed-ipv4-acl"
> ACL unless it supports classifying traffic on Ethernet and classifying
> traffic on IPv4.
> So the 'match type' feature specify what header fields the hardware is
> capable of match on.  E.g. a basic L2 device might say that is only matches
> on the Ethernet header.
> The "ACL types" features specify what combination of header fields can be
> combined into a single ACL.

Ah, right. Sorry, I was thinking that match-on-l2-eth-hdr and
match-on-ipv4-hdr would imply mixed-ipv4-acl. My bad.

> The real benefit for defining "match type" is that the unsupported fields in
> the ACL can then be cleanly left out of the device schema.  E.g. a
> hypothetical new breed of IPv6 only routers that only support matching on
> match-on-ipv6-hdr, and don't want to carry v4 baggage.

Since I work for a network that aspires of being v6 only I quite
like this ;)

> >Are we seeking to have a single style of attachment points? I
> >think that's difficult in reality. Linux has one style, where a
> >single global "ACL" is defined. Most routers use per interface
> >ACL and as seen, they split it up on ethernet vs IP (and v4 vs
> >v6). I doubt one can be said to be better than the other so
> >trying to argue that everyone should converge on one way is
> >pointless. Similarly supporting every different style is also
> >futile as it's completely against the point of standardisation.
> >
> >The pragmatic compromies is likely to support a few ways and any
> >vendor that needs something radically different need to build
> >their own model, do augment, deviate, refine or whatever. Other
> >thoughts?
> For interface attachments I think that the approach in the draft looks OK,
> and reasonably generic, but will need vendor deviations. This is probably
> OK.

I don't agree. Given the length we've gone in trying to convey the
match capabilities of the platform I think we can afford to give
implementors some options when it comes to attachment too! :)

Arguing that one way of doing ACL attachment is better than
another is futile and my personal opinion is that there simply is
no one way that's better than all else. A single global
attachment point like what Linux does is not better or worse from
the per interface ACL style that most router vendors employ. It's
just different. I believe the model should allow vendors and
users to express the most common forms we currently have. Not all
ways, but the two or three most common ways, which probably
covers the vast majority of all platforms.

The current model is an ill fit for platforms that attach filters
globally, like most host firewalls (Linux *tables, OpenBSD pf,
FreeBSD ipfw etc) or the vast majority of firewalls (Juniper SRX,
Cisco ASA, Checkpoint etc). There must be different attachment
options for "per interface" vs "global". 

As for the per-interface style options
 * current draft; a list of ACLs of varying "type", evaluated in
   specified order, per-interface and per direction
 * three separate ACLs for ethernet, ipv4 and ipv6 and
   per-interface and per direction

The only vendor I know of that have a single attachment point on
an interface is Huawei. However, it's not just an attachment
point for ACLs but for what Huawei calls a "traffic-policy" which
mixes in ACLs and QoS in the same place. It is so different from
everything else that deviations or augmentations will no doubt be
required to express what they have. The other large router
vendors; Cisco, Juniper and Nokia, all use separate attachment
points for ipv4, ipv6 and ethernet.

Shouldn't we have a model that supports;
 * virtually all host network stacks
 * virtually all firewalls
 * the vast majority of high end routers

Rather than:
 * no currently existing platform (or is there one I don't know of?)

> Personally, I would put the ACL interface attachment points as an
> augmentation of if:interfaces/interface rather than having a separate top
> level list, but perhaps that is just want I am used to ...

+1 on augmentation of interfaces.


Kristian Larsson                                        KLL-RIPE
+46 704 264511