Re: [netmod] IETF ACL model

Robert Wilton <rwilton@cisco.com> Wed, 22 November 2017 14:01 UTC

Return-Path: <rwilton@cisco.com>
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 B376F129401 for <netmod@ietfa.amsl.com>; Wed, 22 Nov 2017 06:01:14 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.5
X-Spam-Level:
X-Spam-Status: No, score=-14.5 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, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 0qdIUXVV3gAF for <netmod@ietfa.amsl.com>; Wed, 22 Nov 2017 06:01:12 -0800 (PST)
Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2855712421A for <netmod@ietf.org>; Wed, 22 Nov 2017 06:01:12 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5572; q=dns/txt; s=iport; t=1511359272; x=1512568872; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=NSbaE2uAtyS281AxwQd7oHHzHh2mwDLae3HEiIS6M0g=; b=lWmnK1g3K2gZINDPl9F6h650YkVa77ansBxeARw362XFmrNDd+N356s4 ZJgO16/zzWqykjON9SD3B9hh2bFvJeM0ohg+7OPww7CAtZLBMXl7G4cVF 3u/w0A5SrnEPkxIashsNQmPOldEM56mS6Dxit2eIoBa4JiTOI50LITjYZ k=;
X-IronPort-AV: E=Sophos;i="5.44,436,1505779200"; d="scan'208";a="419195"
Received: from aer-iport-nat.cisco.com (HELO aer-core-4.cisco.com) ([173.38.203.22]) by aer-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 22 Nov 2017 14:01:10 +0000
Received: from [10.63.23.168] (dhcp-ensft1-uk-vla370-10-63-23-168.cisco.com [10.63.23.168]) by aer-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id vAME19PG025014; Wed, 22 Nov 2017 14:01:10 GMT
To: Martin Bjorklund <mbj@tail-f.com>, mjethanandani@gmail.com
Cc: jhaas@juniper.net, kll@dev.terastrm.net, agarwaso@cisco.com, netmod@ietf.org, kll@spritelink.net
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>
From: Robert Wilton <rwilton@cisco.com>
Message-ID: <e1fe6796-c124-b663-8e9f-e66c23b10eea@cisco.com>
Date: Wed, 22 Nov 2017 14:01:09 +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: <20171122.093904.670536605936490886.mbj@tail-f.com>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Content-Language: en-US
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/BWCtZNgbdh3CUOyDx7zZiBBAudE>
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: Wed, 22 Nov 2017 14:01:15 -0000

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.

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.

Thanks,
Rob


On 22/11/2017 08:39, Martin Bjorklund wrote:
> Mahesh Jethanandani <mjethanandani@gmail.com> wrote:
>> [Taking the discussion to the mailing list]
>>
>> The summary of the discussion happening on a private thread has to
>> do with the ‘any’ container (now leaf) definition in the ACL model
>> for something that matches anything, much like a ‘*’ would do in
>> regex. The discussion has come down to:
>>
>> - leave the definition as is, so users would have to explicitly define it
>>    pro: It is explicit and there would be no confusion about its
>>    presence or absence.
>>    con: It is verbose, in that every access list entry would have to
>>    define it.
>>
>> - remove the any definition, so an absence of the definition implies
>>    match on all.
> It wouldn't be the *absence* that implies match on all, but rather it
> is the explicit setting of the type to 'any-acl' that means match on
> all:
>
>    <acl>
>      <name>my-any-acl</name>
>      <type>any-acl</type>
>    </acl>
>
> Having to also define the leaf "any" as well would just be redundant:
>
>    <acl>
>      <name>my-any-acl</name>
>      <type>any-acl</type>
>      <aces>
>        <ace>
>          <name>my-any-rule</name>
>          <any/>
>        </ace>
>      </aces>
>    </acl>
>
>
> BTW, I support Kristian's suggestion of have just the "name" as the
> key in the "acl" list, and making "type" mandatory.
>
> I also suggest you remove redundant prefixes in the leaf names,
> e.g. as above s/acl-type/type/ s/acl-name/name/ and
> s/rule-name/name/.  This is how we usually name nodes in the IETF YANG
> models.
>
>> The text in the draft would have to be updated to
>>    state this, and YANG parsers would need to watch out for the
>>    non-definition in the match container.
>>
>> Opinion? Preferences?
>>
>> p.s. Current CLI configurations require explicit declaration of ‘any’.
> But do they also have the acl type definition?
>
>
> /martin
>
>
>
>>> On Nov 20, 2017, at 2:20 PM, Jeff Haas <jhaas@juniper.net> wrote:
>>>
>>>> On Nov 20, 2017, at 4:54 PM, Kristian Larsson <kristian@spritelink.net> wrote:
>>>>
>>>>
>>>>
>>>> On 2017-11-20 18:26, Jeff Haas wrote:
>>>>> IMO, the contention here is a consequence of proof by assertion. >
>>>>>> On Nov 17, 2017, at 5:56 AM, Kristian Larsson <kll@dev.terastrm.net <mailto:kll@dev.terastrm.net>> wrote:
>>>>>>
>>>>>>>> Changes I'd like to see to this PR:
>>>>>>>> * remove any-acl completely as it serves no purpose (we achieve
>>>>>>>>   this through a ACE with no match conditions)
>>>>>>> Will let Jeff respond as he articulated this requirement. Agree that most platforms have deny as the default. But what if the ace entry is something like this:
>>>>>>> access-list 11 permit tcp any any
>>>>>>> Would the absence of match rules for IP addresses imply any any?
>>>>>> An absence of any match means it matches on everything. If there are no IP matches at all, then yes, it implies any source or destination address. I don't see why we would need to explicitly have an any-acl container or leaf to point this out. With the same concept applied uniformly you would explicitly call out "any" matches for all types of matches. That would be extremely verbose.
>>>>> Where in the model does it say that the absence of a matches container implies a match all vs. match none?
>>>>> Where in the normative text of the internet-draft does it say that?
>>>>> In the absence of either of the above, an "any" removes ambiguity.
>>>>> FWIW, I'm totally fine with removing the any; however you *MUST* clarify the above.  Preferably both in the matches container and also in the normative text.  For my part, I think it's easier on the parser if you basically require at least one item from the container so you don't have to deal with optional contents.  But I'm not the one writing yang parsers for a living.
>>>> I think it's clear that if no match condition is defined for a particular (header) field then that means any value will match. It is only an extension of this that no match conditions at all means we match any and all packets. I think that is logical.
>>>>
>>>> This can naturally be spelled out in the text :)
>>> You think it's clear, but where is it in the document or model?
>>>
>>> Of such "implied clarity" is many interop bugs made. :-P
>>>
>>> -- Jeff
>>>
>>>> Kind regards,
>>>>   Kristian.
>> Mahesh Jethanandani
>> mjethanandani@gmail.com
>>
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod