Annika: 

 

It is good to have both the RFC4949 definition and the link to existing 
reductions of that definition (ietf-netmod-acl-model, SUPA, and I2RS 
filter-based RIB drafts).  However, I need advice from John on how he’d like to 
see that combination work.   

 

Sue 

 

 

From: I2nsf [mailto:[email protected]] On Behalf Of Annika Sparkles
Sent: Tuesday, September 13, 2016 1:51 PM
To: John Strassner
Cc: Rakesh Kumar; DIEGO LOPEZ GARCIA; [email protected]; Linda Dunbar; Xialiang 
(Frank); [email protected]; Susan Hares
Subject: Re: [I2nsf] I2NSF Terminology's definition on "ACL" is different from 
ietf-netmod-acl-model

 

"an ACL is first and foremost a mechanism to select something "

 

nodding.

 

If I'm derailing this discussion away from the larger discussion happening 
around ACL's then I'm fine letting this go, but I would just like to say that I 
really like how you describe network ACL's here.

 

On Tue, Sep 13, 2016 at 11:49 AM, John Strassner <[email protected]> wrote:

Hi Annika,

 

That's a fair description. There is the academic part (including a set of 
conferences from the 90s!) from which a set of more powerful generic access 
control models (e.g., RBAC, ABAC, and others) were developed, and then there is 
the networking usage. However, imho, the key point in the networking usage is 
that an ACL is first and foremost a mechanism to select something - what you do 
with it (forward, drop, etc) depends on what you do AFTER the traffic is 
selected.

 

regards,

John

 

On Tue, Sep 13, 2016 at 9:41 AM, Annika Sparkles <[email protected]> 
wrote:

Through my years of network engineering I started out thinking of ACL as "block 
packets at a port level" and then morphed into "a type match filter to 
accomplish various tasks across multiple planes" as I implemented them more and 
more in different networking applications. (COPP, QoS, BGP, WAN Acceleration, 
PFR and so on and so forth). 

 

On Tue, Sep 13, 2016 at 8:27 AM, <[email protected]> wrote:

The observation that these are examples of permission falls more in line with 
RFC-4949's concept of a mechanism of access control, as compared to the ACL 
Model's traffic filtering definition.  As I've noted, I prefer the RFC-4949 
definition, and see the ACL Model definition as referring to a specific 
implementation of ACL 



On 9/13/2016 at 3:23 AM, "John Strassner" <[email protected]> wrote:

Hi Rakesh,

 

I disagree. The three examples you cited are all examples of a permission to do 
something.

 

regards,

John

 

On Mon, Sep 12, 2016 at 10:00 PM, Rakesh Kumar <[email protected]> wrote:

Hi Linda,

 

As evident (https://en.wikipedia.org/wiki/Access_control_list), the ACL has 
different meaning to different folks (IT, Network). John rightly pointed out 
that originally it meant some kind of permission but networking industry 
adopted this to associate with packet filtering as you pointed out.

 

History aside, the ACL have evolved dramatically over the years for various 
reasons:

·         Vendor want to give admin control over operational state of the 
networking device (override protocols or control plane)

·         SDN controller use ACL to configure operational state instead of 
running control plane

·         Feature (forwarding/Security/QoS/Monitoring) 
innovation/differentiations by vendors 

 

In my opinion, ACL can be lot more than filtering or permission (of course each 
vendor has different capability) but I am not sure what is our (I2NSF) specific 
goal behind this discussion. 

 

Do we just make sure that definition is same across all IETF work no matter how 
outdated? 

Do we want to make sure that it aligns with where the networking industry is?

Do we want to make sure that it aligns with the security work we are doing in 
I2NSF?

 

Thanks & Regards,

Rakesh

 

 

From: I2nsf <[email protected]> on behalf of John Strassner 
<[email protected]>
Date: Monday, September 12, 2016 at 5:31 PM
To: Linda Dunbar <[email protected]>, John Strassner 
<[email protected]>, DIEGO LOPEZ GARCIA <[email protected]>, 
"Xialiang (Frank)" <[email protected]>
Cc: "[email protected]" <[email protected]>, Susan Hares <[email protected]>
Subject: Re: [I2nsf] I2NSF Terminology's definition on "ACL" is different from 
ietf-netmod-acl-model

 

Hi Linda,

 

My vote is NO.

 

With all due respect, RFC4949 predates the acl model by almost 7 years. 
Furthermore, ACLs may or may not **filter** traffic. The roots of ACLs go much 
farther back (at least to 1997 that I can find) and, fundamentally, are 
permissions. A permission is not the same as filtering. Finally, we would then 
have to define ACEs, and not all ACL models have ACEs.

 

regards,

John

 

On Mon, Sep 12, 2016 at 10:06 AM, Linda Dunbar <[email protected]> wrote:

John, et al, 

 

The “ietf-netmod-acl-model” has “ACL” defined as:

An ACL is an ordered set of rules that is used to filter traffic on a

networking device. Each rule is represented by an Access Control

Entry (ACE).

 

The “draft-ietf-i2nsf-terminology-01” has ACL as: 

 

ACL (Acess Control List):  This is a mechanism that implements

      access control for a system resource by enumerating the system

      entities that are permitted to access the resource and stating,

      either implicitly or explicitly, the access modes granted to each

      entity [RFC4949]. A YANG description is defined in

      [I-D.ietf-netmod-acl-model].

 

 

 

Can we make I2NSF’s ACL definition consistent with the 
““ietf-netmod-acl-model”? 

 

Thanks, 

Linda 




-- 

regards,

John




-- 

regards,

John


_______________________________________________
I2nsf mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/i2nsf

 





-- 

regards,

John

 

_______________________________________________
I2nsf mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/i2nsf

Reply via email to