Re: [netmod] IETF ACL model

Kristian Larsson <kll@dev.terastrm.net> Mon, 27 November 2017 13:18 UTC

Return-Path: <kll@dev.terastrm.net>
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CCB63127A91 for <netmod@ietfa.amsl.com>; Mon, 27 Nov 2017 05:18:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.89
X-Spam-Level:
X-Spam-Status: No, score=-1.89 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_SPF_HELO_PERMERROR=0.01] autolearn=ham autolearn_force=no
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 xG7BSdYADxeB for <netmod@ietfa.amsl.com>; Mon, 27 Nov 2017 05:17:58 -0800 (PST)
Received: from smtp.dev.terastrm.net (smtp.dev.terastrm.net [IPv6:2003:1f0b:ffde::101]) by ietfa.amsl.com (Postfix) with ESMTP id BAFF3126C25 for <netmod@ietf.org>; Mon, 27 Nov 2017 05:17:58 -0800 (PST)
Received: from lingloi.dev.terastrm.net (unknown [IPv6:2003:1b3b:ffde:1::5]) by smtp.dev.terastrm.net (Postfix) with ESMTPSA id 0B3363A029A; Mon, 27 Nov 2017 13:17:55 +0000 (UTC)
References: <98e29a71-f6dd-7b42-7c8c-f704ba5b8826@spritelink.net> <1354F18F-43E6-43D5-BFAA-C26BCF47AC56@juniper.net> <5D85F296-FB9F-4BA6-B395-B8CD80ED6864@gmail.com> <20171122.093904.670536605936490886.mbj@tail-f.com> <e1fe6796-c124-b663-8e9f-e66c23b10eea@cisco.com>
User-agent: mu4e 0.9.18; emacs 25.1.1
From: Kristian Larsson <kll@dev.terastrm.net>
To: Robert Wilton <rwilton@cisco.com>
Cc: Martin Bjorklund <mbj@tail-f.com>, mjethanandani@gmail.com, jhaas@juniper.net, agarwaso@cisco.com, netmod@ietf.org, kll@spritelink.net
In-reply-to: <e1fe6796-c124-b663-8e9f-e66c23b10eea@cisco.com>
Date: Mon, 27 Nov 2017 14:17:55 +0100
Message-ID: <87y3mr3loc.fsf@dev.terastrm.net>
MIME-Version: 1.0
Content-Type: text/plain
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/cxuJbt90jYzooks8k8XUeQpSUAI>
Subject: Re: [netmod] IETF ACL model
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list <netmod.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/netmod/>
List-Post: <mailto:netmod@ietf.org>
List-Help: <mailto:netmod-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 27 Nov 2017 13:18:01 -0000

Robert Wilton <rwilton@cisco.com> 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 :)

   Kristian.