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

Robert Wilton <rwilton@cisco.com> Fri, 03 November 2017 09:30 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 EB3F113FD30 for <netmod@ietfa.amsl.com>; Fri, 3 Nov 2017 02:30:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.501
X-Spam-Level:
X-Spam-Status: No, score=-14.501 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, 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 tij8I2hzZTLK for <netmod@ietfa.amsl.com>; Fri, 3 Nov 2017 02:30:04 -0700 (PDT)
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 7950313FD2D for <netmod@ietf.org>; Fri, 3 Nov 2017 02:30:03 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5810; q=dns/txt; s=iport; t=1509701403; x=1510911003; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=vO0zUZ/Mz05chjvseXfrrMxIp149Z46W2b+18kCDG6A=; b=Cc1uKEdl0kT9/UCgQQt+c0N7WReqp/PJF6qBXpPs1wJQnx7I4A2/Fo+V +2STxZFs37S87EICbazFQsBR0GXrNtY0ahcEXdB31qdQ2FYstS4paOl3H bKxtO96YZ3B11vqyH9fhywuW9LU0QrFYivJbqguV0yg//TgpoR2rehNps 4=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0COAAACMvxZ/xbLJq1cGQEBAQEBAQEBAQEBBwEBAQEBhQaEJHeJKHSQJJZFghEKhTsChRMYAQEBAQEBAQEBayiFHQEBAQECASMPAQVBEAsYAgImAgJXBg0IAQGKFwioMoInixEBAQEBAQEBAQEBAQEBAQEBASGBD4Ifg1qCEoMBiCaCYgWiDotNiS+LeIc8jimHbYE5HziBbDQhCB0VSYJlglscgWdBjRsBAQE
X-IronPort-AV: E=Sophos;i="5.44,338,1505779200"; d="scan'208";a="40822"
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; 03 Nov 2017 09:30:01 +0000
Received: from [10.63.23.76] (dhcp-ensft1-uk-vla370-10-63-23-76.cisco.com [10.63.23.76]) by aer-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id vA39U1ke026416; Fri, 3 Nov 2017 09:30:01 GMT
To: Kristian Larsson <kristian@spritelink.net>
Cc: Martin Bjorklund <mbj@tail-f.com>, mjethanandani@gmail.com, netmod@ietf.org
References: <20171102074318.GC12688@spritelink.se> <6359CD50-0F0D-4315-A58B-1D4CF0583475@gmail.com> <ac9fc676-80f7-723d-9a85-c99fbb122476@cisco.com> <20171102.132634.1363976895007772742.mbj@tail-f.com> <c90aa6c1-340e-2225-f960-73c1395041c5@cisco.com> <20171102164149.GD12688@spritelink.se> <6d6a1b2a-23f8-8bff-a01e-6d13cc73d92f@cisco.com> <20171103084231.GE12688@spritelink.se>
From: Robert Wilton <rwilton@cisco.com>
Message-ID: <22bb1ad7-070b-68e1-b35a-bce01204b840@cisco.com>
Date: Fri, 03 Nov 2017 09:30:01 +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: <20171103084231.GE12688@spritelink.se>
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/29ljcONZ6nUiCpCa14Dx2-ifDPw>
Subject: Re: [netmod] WG Last Call: draft-ietf-netmod-acl-model-14
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: Fri, 03 Nov 2017 09:30:06 -0000


On 03/11/2017 08:42, Kristian Larsson wrote:
> 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! :)
I  agree that interface vs global are two different styles, and happy if 
the model supports both.

But for interface attachments, if there can be one generic way that can 
apply to all platforms (perhaps with further constraints) then that will 
be easier for clients to code to.

If different vendors do interface attachment in different ways then that 
ends up being more code on the client side.

>
> 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.
OK, would be happy for 2 ways:
  - interfaces
  - global

With each of them generic enough to apply reasonably widely.

>
> 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".
Sure.

>   
>
> 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
I think that the current model accommodates both of these.

For the 3 separate ACLs, the vendor would "deviate" the model with 
additional constraints so that there could only be one ACL of each type 
in the list for an interface.

Given that the model allows mixed ACLs, this approach still seems 
reasonable and quite generic to me.

>
> 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
Yes, if we can.

Thanks,
Rob


>
> 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.
>
>     kll
>