Re: [netmod] IETF ACL model

Mahesh Jethanandani <> Tue, 21 November 2017 16:25 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id F1C8D129ACD for <>; Tue, 21 Nov 2017 08:25:20 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id BVlGMTrmbwOZ for <>; Tue, 21 Nov 2017 08:25:14 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:400e:c05::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 0048E124D6C for <>; Tue, 21 Nov 2017 08:25:13 -0800 (PST)
Received: by with SMTP id r12so10527253pgu.10 for <>; Tue, 21 Nov 2017 08:25:13 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc:message-id:references :to; bh=1X9tPdG78gc6I85BSb3nlxDnsHbfULJ/Hd8l1g2zyvY=; b=cTNB7cljdoAEaUI/gD0Y5isTofCRdNbql8A5Mxfuj6RBQ70Iyf2Z6Eb1dDC4CLPRqY zPoh7kAK+1JFbzTzx0Lhw8FcJUSYspwiA8ls0a3uUrgZpuqjdeudi8g66XF82osPp53O n2VBU4PjaxsKoKzCMljRuQsGKzU1Q6sujyFtj6s1L1DwhmM0OjJ9Go0Bh5WqNAt3LqJg FTWfsHCd33xJCOzV/K6WCyeVBw64dr9SKSVBhwbPWnOZP8mbxpS+Yu8UZ4AimjkaB4O/ 1UltAOt4QLsb+Kz3eN0NwD3f8hhA3YpoPy/Giio53PGFpqZd97tugGeILyvyISmCw3BN d5Ng==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=1X9tPdG78gc6I85BSb3nlxDnsHbfULJ/Hd8l1g2zyvY=; b=dNaQrOqSLAH34jXVfniQTD6x79ykW3rfhAFrdKFMHbvdHyI/V4LaQRMQvYu75J5Vcx O1X6dwinUjLoIARLMwyN6xqqMf/pJhhCNlslcch0BnajG5V6xpEG6x8FToWEnc+2MD+0 b4CexXCNxoWDFkRoIE6OvmYzTIAzw8RUok0uC7ma6Gon0J8aHA9FlHrz0kdodIYQ3ytp Rdbuz4SDJaPLygFXXT2hskIpyfsm5J42WnMc7D0itCASY/izfg8wMA76/B+I7WRC6hHv wOWl9PFO+n4wK5nX1iPBKwgtnn1HWj8pk+ElwW808V/jP67jIxd2IbO7KTd9YiuJhub+ Ldgg==
X-Gm-Message-State: AJaThX5k8CJNUi1TPLY49sL+xhfWOnkhaM7bKu/8KrYZScVYq92gfYNa E2/dAtbzNxjWrLBs+q6/gckhBaxN
X-Google-Smtp-Source: AGs4zMZtNdRJ/9IUUs7iwh/G8HtCogyyoG5/4aXrT48SQrSmObyZgG4ImhdYTFDgTCY9orALUH1eGg==
X-Received: by with SMTP id n189mr17051264pgn.78.1511281512902; Tue, 21 Nov 2017 08:25:12 -0800 (PST)
Received: from ?IPv6:2600:1700:edb0:8fd0:f892:b5d6:b814:d0d0? ([2600:1700:edb0:8fd0:f892:b5d6:b814:d0d0]) by with ESMTPSA id l14sm22568063pgn.35.2017. (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Tue, 21 Nov 2017 08:25:12 -0800 (PST)
Content-Type: multipart/alternative; boundary="Apple-Mail=_915F6118-5150-45C7-B098-D477FA913B53"
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
From: Mahesh Jethanandani <>
In-Reply-To: <>
Date: Tue, 21 Nov 2017 08:25:10 -0800
Cc: Kristian Larsson <>, Kristian Larsson <>, Kent Watsen <>, "Einar Nilsen-Nygaard (einarnn)" <>, "Sonal Agarwal (agarwaso)" <>, Robert Wilton <>, Kristian Larsson <>, Jeffrey Haas <>
Message-Id: <>
References: <> <> <> <> <> <> <> <> <> <>
To: NetMod WG <>
X-Mailer: Apple Mail (2.3124)
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: Tue, 21 Nov 2017 16:25:21 -0000

[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. 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’.

> On Nov 20, 2017, at 2:20 PM, Jeff Haas <> wrote:
>> On Nov 20, 2017, at 4:54 PM, Kristian Larsson <> 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 < <>> 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