Re: [netmod] I-D Action: draft-ietf-netmod-acl-model-17.txt

Kristian Larsson <> Thu, 15 March 2018 15:45 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id C45301273E2 for <>; Thu, 15 Mar 2018 08:45:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.911
X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id gOIkqVW-E46F for <>; Thu, 15 Mar 2018 08:45:45 -0700 (PDT)
Received: from Mail2.SpriteLink.NET ( []) by (Postfix) with ESMTP id A233F12711E for <>; Thu, 15 Mar 2018 08:45:45 -0700 (PDT)
Received: from localhost (localhost []) by Mail2.SpriteLink.NET (Postfix) with ESMTP id 7DEF0261A2B for <>; Thu, 15 Mar 2018 16:45:48 +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 YNTIu6RTir2u for <>; Thu, 15 Mar 2018 16:45:46 +0100 (CET)
Received: from mbp.local ( []) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: by Mail2.SpriteLink.NET (Postfix) with ESMTPSA id 330912619F3 for <>; Thu, 15 Mar 2018 16:45:46 +0100 (CET)
References: <> <> <> <>
From: Kristian Larsson <>
Message-ID: <>
Date: Thu, 15 Mar 2018 16:45:41 +0100
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.6.0
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Archived-At: <>
Subject: Re: [netmod] I-D Action: draft-ietf-netmod-acl-model-17.txt
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: Thu, 15 Mar 2018 15:45:48 -0000


... snip snip...
On 2018-03-09 01:40, Mahesh Jethanandani wrote:
> Choice of source port definition using range/operator or referring to a 
> group of source ports, to be added as a future 'case' statement.
>>  - ditto for "or referring to a group of destination ports."
>>  - ditto on both of the above for the "udp" container
>>  - is it possible for both "egress-interface" and "ingress-interface" 
>> leafs to
>>    be specified at the same time?  - if not, should there a 'must' 
>> statement to
>>    prevent that possibility? - or an explanation for what happens if 
>> it occurs?
> Let me discuss this with my co-authors.

It is possible to match both egress-interface and ingress-interface in 
the same ACL. Different devices support different type of attachment 
points for ACLs. Most routers, like an ASR9k or Juniper MX, supports 
attaching ACLs on interfaces in either ingress or egress direction. If 
we apply ACL FOO ingress on interface BAR then it would perhaps be weird 
to use the ingress-interface match in the FOO ACL since 
ingress-interface will always be BAR for every packet evaluated. Using 
egress-interface would make a lot more sense (and we will know the 
egress-interface if the platform performs the route lookup before 
evluating the ACL which is an implementation issue). We could introduce 
a must constraint to avoid a silly situation but I don't think that's a 
real improvement on the model.

Above all, considering the other type of attachment, which we find among 
others on Linux with iptables or nftables, which is a sort of "global" 
attachment point, it makes sense to be able to specify both. nftables 
rules are not written and attached to a particular interface but rather 
end up in a central list of rules and so it makes sense being able to 
write individual rules that match on ingress-interface, egress-interface 
or both (or none). A must constraint would make that impossible, so 
please don't add a must.

Kind regards,