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

"Einar Nilsen-Nygaard (einarnn)" <einarnn@cisco.com> Thu, 14 December 2017 00:02 UTC

Return-Path: <einarnn@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 C1C571243FE for <netmod@ietfa.amsl.com>; Wed, 13 Dec 2017 16:02:41 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.519
X-Spam-Level:
X-Spam-Status: No, score=-14.519 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 rC3ijnTvF2z9 for <netmod@ietfa.amsl.com>; Wed, 13 Dec 2017 16:02:39 -0800 (PST)
Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 714361201F8 for <netmod@ietf.org>; Wed, 13 Dec 2017 16:02:38 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=49010; q=dns/txt; s=iport; t=1513209758; x=1514419358; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=i7SKotB1qmmQWeXlCKWm2P6cr9Mz7dh0DX10RhIFlo4=; b=C+EobeuqDGDTWnks3mOscrDQKBTiKFq/rD0M+/JFdWlNVUolkduOTQmT DfaCxl5QojFfRJo+V+tTes8QmP5zkp81Li3RXHgrI7Gl5F0+Q2DkKWFxW D3pHhh+660Rqiww3nPCgbsbYaMqKY2zyaI0AJ36gl5Onue63QXF04EOVu c=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DIAABxvjFa/5NdJa1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYMPL2Z0JweDe4ohjweKdY4ZghUKGAEKhElPAhqEeT8YAQEBAQE?= =?us-ascii?q?BAQEBayiFJAIEAQEhBEcLEAIBCA4qAQYDAgICHwYLFBECBA4FiURMAxUQqR2Bb?= =?us-ascii?q?TqHOA2DGwEBAQEBAQEBAQEBAQEBAQEBAQEBARgFg2CCC4NogwKCakQBgW03gl8?= =?us-ascii?q?xgjIFkhSQTj0CkCiEfZNojU2FVoMWAhEZAYE6AR85gU5vFToqAYF+P4IUHIFne?= =?us-ascii?q?IkXgRUBAQE?=
X-IronPort-AV: E=Sophos;i="5.45,398,1508803200"; d="scan'208,217";a="321704999"
Received: from rcdn-core-11.cisco.com ([173.37.93.147]) by rcdn-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 14 Dec 2017 00:02:37 +0000
Received: from XCH-RTP-010.cisco.com (xch-rtp-010.cisco.com [64.101.220.150]) by rcdn-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id vBE02aTY014396 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 14 Dec 2017 00:02:37 GMT
Received: from xch-rtp-009.cisco.com (64.101.220.149) by XCH-RTP-010.cisco.com (64.101.220.150) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Wed, 13 Dec 2017 19:02:36 -0500
Received: from xch-rtp-009.cisco.com ([64.101.220.149]) by XCH-RTP-009.cisco.com ([64.101.220.149]) with mapi id 15.00.1320.000; Wed, 13 Dec 2017 19:02:36 -0500
From: "Einar Nilsen-Nygaard (einarnn)" <einarnn@cisco.com>
To: Thomas Nadeau <tnadeau@lucidvision.com>
CC: Mahesh Jethanandani <mjethanandani@gmail.com>, "netmod@ietf.org" <netmod@ietf.org>
Thread-Topic: [netmod] WG Last Call: draft-ietf-netmod-acl-model-14
Thread-Index: AQHTbr9cXtHryOdSBU6fXjbxU9aeHqM3Cy0AgAqwcwCAAFeRgIAABBMAgAABOICAAAMrAIAAB9gAgAAB4ICAAAQdAIAAKpIA
Date: Thu, 14 Dec 2017 00:02:35 +0000
Message-ID: <B4AB3AB0-A5B7-4B3D-94C4-83768ACB723D@cisco.com>
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> <B63D5700-C13B-4D2D-9439-0E4471906374@gmail.com> <a75cf59c-7f5e-0b3b-0ace-ec9be9f67116@cisco.com> <37FA28D8-6799-491C-94CB-04237766E4D3@cisco.com> <2C381B09-15D6-417D-A70D-7C6818306FFC@gmail.com> <42A2F0C4-52FD-4894-8D08-092BB2B0772B@cisco.com> <FEA5251F-990C-4948-91F6-44AE25E016AE@gmail.com> <70C53C47-5C0A-4635-BC98-EBC9AD4130CB@cisco.com> <5CBC1C7B-FB4C-4313-9BE3-BEF618C62DA2@gmail.com> <11BA5D15-8C55-419B-ACBC-3D2202031280@cisco.com> <A5C678AB-4C73-451F-A68F-DB7EF125A8BA@lucidvision.com>
In-Reply-To: <A5C678AB-4C73-451F-A68F-DB7EF125A8BA@lucidvision.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-mailer: Apple Mail (2.3445.4.7)
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.61.210.168]
Content-Type: multipart/alternative; boundary="_000_B4AB3AB0A5B74B3D94C483768ACB723Dciscocom_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/NkF3Mb5_omgECp6QMvai_EQa-Ik>
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: Thu, 14 Dec 2017 00:02:42 -0000

Tom,

If we were to introduce this, yes, that (or some similar term) may help clarify. But I think that at the moment we have suggested that we leave this issue out of the initial draft until it is better understood what we should specify.

I think the question at this point is whether explicit ACL to interface binding should be done via interface augmentations or via a list of interface references in the ACL model. Both examples are shown below, but I’ll pull them up for clarity:

 module: ietf-access-control-list
  augment /if:interfaces/if:interface:
    +--rw ingress-acls
    |  +--rw acl-sets
    |     +--rw acl-set* [name]
    |        +--rw name              -> /access-lists/acl/name
    |        +--rw type?             -> /access-lists/acl/type
    |        +--ro ace-statistics* [name] {interface-stats}?
    |           +--ro name               -> /access-lists/acl/aces/ace/name
    |           +--ro matched-packets?   yang:counter64
    |           +--ro matched-octets?    yang:counter64
    +--rw egress-acls
       +--rw acl-sets
          +--rw acl-set* [name]
             +--rw name              -> /access-lists/acl/name
             +--rw type?             -> /access-lists/acl/type
             +--ro ace-statistics* [name] {interface-stats}?
                +--ro name               -> /access-lists/acl/aces/ace/name
                +--ro matched-packets?   yang:counter64
                +--ro matched-octets?    yang:counter64

 module: ietf-access-control-list
    +--rw access-lists
       +--rw attachment-points
          +--rw interface* [interface-id] {interface-attachment}?
             +--rw interface-id    if:interface-ref
             +--rw ingress
             |  +--rw acl-sets
             |     +--rw acl-set* [name]
             |        +--rw name    -> ../../../../../../acl/name
             |        +--rw type?   -> ../../../../../../acl/type
             |        +--ro ace* [name] {interface-stats or interface-acl-aggregate}?
             |           +--ro name               -> ../../../../../../../acl/aces/ace/name
             |           +--ro matched-packets?   yang:counter64
             |           +--ro matched-octets?    yang:counter64
             +--rw egress
                +--rw acl-sets
                   +--rw acl-set* [name]
                      +--rw name    -> ../../../../../../acl/name
                      +--rw type?   -> ../../../../../../acl/type
                      +--ro ace* [name] {interface-stats or interface-acl-aggregate}?
                         +--ro name               -> ../../../../../../../acl/aces/ace/name
                         +--ro matched-packets?   yang:counter64
                         +--ro matched-octets?    yang:counter64

Cheers,

Einar

On 13 Dec 2017, at 21:30, Thomas Nadeau <tnadeau@lucidvision.com<mailto:tnadeau@lucidvision.com>> wrote:


Maybe it would help to say “to all interfaces” instead of “globally”?

—Tom


On Dec 13, 2017, at 4:15 PM, Einar Nilsen-Nygaard (einarnn) <einarnn@cisco.com<mailto:einarnn@cisco.com>> wrote:

I’m not sure we have a clear enough common understanding of “global” as yet to be able to say that we should make the provisioning of an ACL on an interface or “globally” mutually exclusive in the model. I think attaching an ACL to a specific interface in either the ingress or egress direction is well-understood, and with a shared understanding across vendors and operators such that either an interface augmentation or a “external” list , with no mention of global, makes sense.

Cheers,

Einar

On 13 Dec 2017, at 21:08, Mahesh Jethanandani <mjethanandani@gmail.com<mailto:mjethanandani@gmail.com>> wrote:

You can use the same ACL definition to attach to different points in the system, provided they do not overlap. Otherwise, you are just wasting CAM entries. Global and interface attachment points will overlap with each other, because global means ‘any’ interface.

On Dec 13, 2017, at 12:40 PM, Einar Nilsen-Nygaard (einarnn) <einarnn@cisco.com<mailto:einarnn@cisco.com>> wrote:

We need to be able to attach any one ACL to a whole range of different places. Just speaking from the Cisco platform perspective, I may attach an ACL to:


  *   Interfaces
  *   NAT configuration
  *   Class maps for QoS policy
  *   Class maps for FW policy
  *   …etc…

Not sure if we have any global attachment points today, but if we did, I’d want to be able to use the same ACL definition anywhere I need it, not in just one on N places.

Cheers,

Einar

On 13 Dec 2017, at 20:29, Mahesh Jethanandani <mjethanandani@gmail.com<mailto:mjethanandani@gmail.com>> wrote:

My understanding is that you would attach an ACL either to an interface or globally. Not both.

On Dec 13, 2017, at 12:25 PM, Einar Nilsen-Nygaard (einarnn) <einarnn@cisco.com<mailto:einarnn@cisco.com>> wrote:

I’m happy to have a way to attach an ACL globally, but that’s orthogonal to attaching to an interface, isn’t it? Attaching ACLs directly to an interface doesn’t preclude global attachment in any way as far as I can see…or have I missed something? I’m not sure I understand why choices are an issue. The current proposal has this container:

module: ietf-access-control-list
    +--rw access-lists
       +--rw attachment-points
          +--rw interface* [interface-id] {interface-attachment}?
             +--rw interface-id    if:interface-ref
             +--rw ingress
             |  +--rw acl-sets
             |     +--rw acl-set* [name]
             |        +--rw name    -> ../../../../../../acl/name
             |        +--rw type?   -> ../../../../../../acl/type
             |        +--ro ace* [name] {interface-stats or interface-acl-aggregate}?
             |           +--ro name               -> ../../../../../../../acl/aces/ace/name
             |           +--ro matched-packets?   yang:counter64
             |           +--ro matched-octets?    yang:counter64
             +--rw egress
                +--rw acl-sets
                   +--rw acl-set* [name]
                      +--rw name    -> ../../../../../../acl/name
                      +--rw type?   -> ../../../../../../acl/type
                      +--ro ace* [name] {interface-stats or interface-acl-aggregate}?
                         +--ro name               -> ../../../../../../../acl/aces/ace/name
                         +--ro matched-packets?   yang:counter64
                         +--ro matched-octets?    yang:counter64

If we added some form of global attachment points, that might be a peer with the list of interface attachments, right? Because we’d need to support “global” and multiple “interface” attachments. It’s not an “or”, it’s an “and”. Or have I missed something?

Cheers,

Einar

On 13 Dec 2017, at 20:10, Mahesh Jethanandani <mjethanandani@gmail.com<mailto:mjethanandani@gmail.com>> wrote:

We want to support “global” attachment point down the line, and that “global” attachment point will be one of the choices (the other being the interface), what would this augment look like. Note, as far as I know, you cannot augment inside a choice node.

On Dec 13, 2017, at 6:57 AM, Einar Nilsen-Nygaard (einarnn) <einarnn@cisco.com<mailto:einarnn@cisco.com>> wrote:

Perhaps like this, as an augmentation to the interface:

  augment /if:interfaces/if:interface:
    +--rw ingress-acls
    |  +--rw acl-sets
    |     +--rw acl-set* [name]
    |        +--rw name              -> /access-lists/acl/name
    |        +--rw type?             -> /access-lists/acl/type
    |        +--ro ace-statistics* [name] {interface-stats}?
    |           +--ro name               -> /access-lists/acl/aces/ace/name
    |           +--ro matched-packets?   yang:counter64
    |           +--ro matched-octets?    yang:counter64
    +--rw egress-acls
       +--rw acl-sets
          +--rw acl-set* [name]
             +--rw name              -> /access-lists/acl/name
             +--rw type?             -> /access-lists/acl/type
             +--ro ace-statistics* [name] {interface-stats}?
                +--ro name               -> /access-lists/acl/aces/ace/name
                +--ro matched-packets?   yang:counter64
                +--ro matched-octets?    yang:counter64

Could also put an “aces” container above both these & rename “ingress-acls" to “ingress”, etc. to give a single root for the augmentation if preferred.

Cheers,

Einar


On 6 Dec 2017, at 19:43, Eliot Lear <lear@cisco.com<mailto:lear@cisco.com>> wrote:



On 12/6/17 7:23 PM, Mahesh Jethanandani wrote:
How does one move the interface attachment point, currently an
'interface-ref', to an augmentation of the if:interfaces/interface,
inside of the ‘acl’  container? Down the line we might need to have an
container for "attachment points" to accommodate the possibility of
attaching an ACL either to an interface or “globally”.


Keeping in mind that one use is that an ACL doesn't attach to an
interface at all.

_______________________________________________
netmod mailing list
netmod@ietf.org<mailto:netmod@ietf.org>
https://www.ietf.org/mailman/listinfo/netmod


Mahesh Jethanandani
mjethanandani@gmail.com<mailto:mjethanandani@gmail.com>



Mahesh Jethanandani
mjethanandani@gmail.com<mailto:mjethanandani@gmail.com>



Mahesh Jethanandani
mjethanandani@gmail.com<mailto:mjethanandani@gmail.com>


_______________________________________________
netmod mailing list
netmod@ietf.org<mailto:netmod@ietf.org>
https://www.ietf.org/mailman/listinfo/netmod