Subject: [I2nsf] I2NSF Terminology's definition on "ACL" is different from ietf-netmod-acl-model

From: Linda Dunbar <[email-masked]>
Date: Mon, 12 Sep 2016 17:06:40 +0000

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

---

From: "Natale, Bob" <[email-masked]>
Date: Mon, 12 Sep 2016 17:27:35 +0000

Hi Linda,

It seems to me that the RFC4949 definition is more general and that ietf-netmod-acl-model defines one compatible specific variation. Some of the specifics of that definition might not apply in all cases.

In fact, I am somewhat surprised that the latter document did not, evidently, reference RFC4949 ... at least for a baseline definition. True, it's a bit dated, but I think that mostly affects concepts and constructs introduced since its publication ... the widespread use of ACLs predates RFC4949 by a lot.

For reference, the fairly recent CNSSI 4009, Committee on National Security Systems (CNSS) Glossary (Apr 6, 2015) also uses a more general definition:
access control list (ACL)

A list of permissions associated with an object. The list specifies who or what is allowed to access the object and what operations are allowed to be performed on the object.

Avanti,
BobN

From: I2nsf [mailto:[email-masked]] On Behalf Of Linda Dunbar
Sent: Monday, September 12, 2016 1:07 PM
To: John Strassner <[email-masked]>; Susan Hares <[email-masked]>; [email-masked]
Subject: [I2nsf] I2NSF Terminology's definition on "ACL" is different from ietf-netmod-acl-model

John, et al,

Thanks,
Linda

---

From: [email-masked]
Date: Mon, 12 Sep 2016 15:35:11 -0400

One of the difficulties in defining an ACL is actually in how an ACL
works.  The RFC 4949 definition describes a 'mechanism' where
ietf-netmod-acl-model describe a functional 'ordered set'.  In other
words, RFC 4949 does not say how a list is processed, where
ietf-netmod-acl-model implies a serial processing, although not how
the list is ordered or how a resulting match is attained.  It seems
like splitting hairs but I would argue that the ietf-netmod-acl-model
definition is a subset of the RFC 4949 one.  So which one we use
determines a scope of outcome.
I think the real implied question here is if the focus of our work is
biased or limited towards YANG models, and by implication NETCONF as a
management protocol?  Adopting the ietf-netmod-acl-model definition
clearly means yes.  I do not believe that RFC 4949 is planned to be
superseded, and I agree with BobN in this case that the RFC 4949
definition is the broader one
Cheers!Ed Lopez
On 9/12/2016 at 1:27 PM, "Bob Natale"  wrote:      

	Hi Linda, 
	It seems to me that the RFC4949 definition is more general and that
ietf-netmod-acl-model defines one compatible specific variation. Some
of the specifics of that definition might not apply in  all cases. 
	In fact, I am somewhat surprised that the latter document did not,
evidently, reference RFC4949 … at least for a baseline definition.
True, it’s a bit dated, but I think that mostly affects concepts 
and constructs introduced since its publication … the widespread use
of ACLs predates RFC4949 by a lot. 
	For reference, the fairly recent CNSSI 4009, _Committee on National
Security Systems (CNSS) Glossary_ (Apr 6, 2015) also uses a more
general definition: 
	access control list (ACL)    

	A list of permissions associated with an object. The list specifies
who or what is allowed to access the object and what operations are
allowed to be performed on the object.   
	Avanti, 

	BobN  
	From: I2nsf [mailto:[email-masked]] On Behalf Of Linda Dunbar
 Sent: Monday, September 12, 2016 1:07 PM
 To: John Strassner ; Susan Hares ; [email-masked]
 Subject: [I2nsf] I2NSF Terminology's definition on "ACL" is different
from ietf-netmod-acl-model   
	John, et al,  
	The “ietf-netmod-acl-model” has “ACL” defined as: 

	Entry (ACE). 
	The “draft-ietf-i2nsf-terminology-01” has ACL as:  
	ACL (Acess Control List):  This is a mechanism that implements 

	      either implicitly or explicitly, the access modes granted to
each 

	      [I-D.ietf-netmod-acl-model]. 
	Can we make I2NSF’s ACL definition consistent with the
““ietf-netmod-acl-model”?  
	Thanks,  

	Linda

---

From: John Strassner <[email-masked]>
Date: Mon, 12 Sep 2016 17:31:51 -0700

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

-- 
regards,
John

---

From: John Strassner <[email-masked]>
Date: Mon, 12 Sep 2016 17:40:41 -0700

Thanks Bob, completely agree.

Fundamentally, "filter" implies "remove" (at least in English). ACLs are
permissions. Removing something (or forwarding, or whatever) is simply an
action dictated by the permission.

regards,
John

On Mon, Sep 12, 2016 at 10:27 AM, Natale, Bob <[email-masked]> wrote:

> ietf-netmod-acl-model defines one compatible specific variation. Some of
> the specifics of that definition might not apply in all cases.
>
>
>
> evidently, reference RFC4949 … at least for a baseline definition. True,
> it’s a bit dated, but I think that mostly affects concepts and constructs
> introduced since its publication … the widespread use of ACLs predates
> RFC4949 by a lot.
>
>
>
> For reference, the fairly recent CNSSI 4009, *Committee on National
> Security Systems (CNSS) Glossary* (Apr 6, 2015) also uses a more general
> definition:
>
> A list of permissions associated with an object. The list specifies who or
> what is allowed to access the object and what operations are allowed to be
> performed on the object.
>
>
>
> Avanti,
>
> BobN
>
>
>
> *From:* I2nsf [mailto:[email-masked]] *On Behalf Of *Linda Dunbar
> *Sent:* Monday, September 12, 2016 1:07 PM
> *To:* John Strassner <[email-masked]>; Susan Hares <[email-masked]>;
> [email-masked]
> *Subject:* [I2nsf] I2NSF Terminology's definition on "ACL" is different

-- 
regards,
John

---

From: Rakesh Kumar <[email-masked]>
Date: Tue, 13 Sep 2016 05:00:59 +0000

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-masked]> on behalf of John Strassner <[email-masked]>
Date: Monday, September 12, 2016 at 5:31 PM
To: Linda Dunbar <[email-masked]>, John Strassner <[email-masked]>, DIEGO LOPEZ GARCIA <[email-masked]>, "Xialiang (Frank)" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, Susan Hares <[email-masked]>
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-masked]<mailto:[email-masked]>> wrote:
John, et al,

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

Thanks,
Linda

--
regards,
John

---

From: John Strassner <[email-masked]>
Date: Tue, 13 Sep 2016 00:23:20 -0700

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-masked]> 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.
>
>
>
> ·         Vendor want to give admin control over operational state of the
> networking device (override protocols or control plane)
>
> 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.
>
>
>
> *From: *I2nsf <[email-masked]> on behalf of John Strassner <
> [email-masked]>
> *Date: *Monday, September 12, 2016 at 5:31 PM
> *To: *Linda Dunbar <[email-masked]>, John Strassner <
> [email-masked]>, DIEGO LOPEZ GARCIA <[email-masked]>,
> "Xialiang (Frank)" <[email-masked]>
> *Cc: *"[email-masked]" <[email-masked]>, Susan Hares <[email-masked]>
> *Subject: *Re: [I2nsf] I2NSF Terminology's definition on "ACL" is
> different from ietf-netmod-acl-model
>
>
>
> Hi Linda,
>
>
>
> My vote is NO.
>
>
>

-- 
regards,
John

---

From: [email-masked]
Date: Tue, 13 Sep 2016 09:27:27 -0400

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"  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  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  on behalf of John Strassner 
 Date: Monday, September 12, 2016 at 5:31 PM
 To: Linda Dunbar , John Strassner , DIEGO LOPEZ GARCIA , "Xialiang
(Frank)" 
 Cc: "[email-masked]" , Susan Hares 
 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  wrote:    

	John, et al,  

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

	 Entry (ACE). 

	       entities that are permitted to access the resource and
stating, 

	Linda      
 --    

	regards,   

	John        
-- 
regards,John

---

From: Annika Sparkles <[email-masked]>
Date: Tue, 13 Sep 2016 11:41:08 -0500

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-masked]> 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-masked]> wrote:
>
> Hi Rakesh,
>
>> ·         Vendor want to give admin control over operational state of
>> the networking device (override protocols or control plane)
>>
>> course each vendor has different capability) but I am not sure what is our
>> (I2NSF) specific goal behind this discussion.
>>
>>
>>
> _______________________________________________
> I2nsf mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/i2nsf
>
>

---

From: John Strassner <[email-masked]>
Date: Tue, 13 Sep 2016 09:49:52 -0700

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

-- 
regards,
John

---

From: Annika Sparkles <[email-masked]>
Date: Tue, 13 Sep 2016 12:51:23 -0500

"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-masked]> wrote:

>>>> ACL has different meaning to different folks (IT, Network). John rightly

---

From: "Diego R. Lopez" <[email-masked]>
Date: Tue, 13 Sep 2016 18:02:29 +0000

Fully agree with John. ACL is essentiallt about permission, though in some languages (including my mother one) "filter" may be associated with the concept of selectively allowing some access...

--
Likely to be brief and not very
elaborate as sent from my mobile
Diego R. Lopez
Telefonica I+D

On 13 Sep 2016, at 02:40, John Strassner <[email-masked]<mailto:[email-masked]>> wrote:

Fundamentally, "filter" implies "remove" (at least in English). ACLs are permissions. Removing something (or forwarding, or whatever) is simply an action dictated by the permission.

regards,
John

On Mon, Sep 12, 2016 at 10:27 AM, Natale, Bob <[email-masked]<mailto:[email-masked]>> wrote:
Hi Linda,

Avanti,
BobN

From: I2nsf [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Linda Dunbar
Sent: Monday, September 12, 2016 1:07 PM
To: John Strassner <[email-masked]<mailto:[email-masked]>>; Susan Hares <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: [I2nsf] I2NSF Terminology's definition on "ACL" is different from ietf-netmod-acl-model

John, et al,

Thanks,
Linda

--
regards,
John
_______________________________________________
I2nsf mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/i2nsf

---

From: "Susan Hares" <[email-masked]>
Date: Tue, 13 Sep 2016 14:16:30 -0400

+1 to Bob’s statement that RFC4949 is the broader definition.  It better fits the expanded work represented by SUPA and I2RS on Filter-based policy that may be ordered by the user. 

Sue 

PS – If you wish additional comments on SUPA and I2RS. John Strassner is best able to comment on SUPA and I will comment on I2RS Filters. 

From: I2nsf [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Monday, September 12, 2016 3:35 PM
To: Bob Natale; Linda Dunbar; John Strassner; Susan Hares
Cc: [email-masked]
Subject: Re: [I2nsf] I2NSF Terminology's definition on "ACL" is different from ietf-netmod-acl-model

One of the difficulties in defining an ACL is actually in how an ACL works.  The RFC 4949 definition describes a 'mechanism' where ietf-netmod-acl-model describe a functional 'ordered set'.  In other words, RFC 4949 does not say how a list is processed, where ietf-netmod-acl-model implies a serial processing, although not how the list is ordered or how a resulting match is attained.  It seems like splitting hairs but I would argue that the ietf-netmod-acl-model definition is a subset of the RFC 4949 one.  So which one we use determines a scope of outcome.

I think the real implied question here is if the focus of our work is biased or limited towards YANG models, and by implication NETCONF as a management protocol?  Adopting the ietf-netmod-acl-model definition clearly means yes.  I do not believe that RFC 4949 is planned to be superseded, and I agree with BobN in this case that the RFC 4949 definition is the broader one

Cheers!

Ed Lopez

On 9/12/2016 at 1:27 PM, "Bob Natale" <[email-masked]> wrote:

Hi Linda,

In fact, I am somewhat surprised that the latter document did not, evidently, reference RFC4949 … at least for a baseline definition. True, it’s a bit dated, but I think that mostly affects concepts and constructs introduced since its publication … the widespread use of ACLs predates RFC4949 by a lot.

Avanti,

BobN

John, et al, 

Entry (ACE).

 

Thanks, 

Linda

---

From: "Susan Hares" <[email-masked]>
Date: Tue, 13 Sep 2016 14:25:17 -0400

Rakesh: 

My understanding is that RFC4949 that Bob quoted is the IETF general definition.   Let me answer your questions. 

   We believe that RFC4949 is not outdated.   We need to provide feedback to the NETMOD that

   draft-ietf-netmod-acl-model does not reference RFC4949, and is providing a change. 

  Does the network industry have a common de-facto definition?  Is it different than RFC4949?  Cisco CLI has one way of doing ACLs, and Juniper’s CLI could be viewed to have a separate one.  Perhaps you can provide additional information why you think RFC4949 is not the way the industry is going? 

IMHO, I2NSF wants to make sure the draft-ietf-netmod-acl-model aligns with I2NSF so that we can utilize the Yang models to minimize code redundancy in the code. 

Cheerily, 

Sue Hares 

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

Hi Linda,

Thanks & Regards,

Rakesh

Hi Linda,

My vote is NO.

regards,

John

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

John, et al, 

Entry (ACE).

 

Thanks, 

Linda 

-- 

regards,

John

---

From: "Susan Hares" <[email-masked]>
Date: Tue, 13 Sep 2016 14:32:52 -0400

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

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.

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-masked]> 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). 

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 

Hi Rakesh,

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

regards,

John

Hi Linda,

Thanks & Regards,

Rakesh

Hi Linda,

My vote is NO.

regards,

John

John, et al, 

Entry (ACE).

 

Thanks, 

Linda 

-- 

regards,

John

-- 

regards,

John

-- 

regards,

John

---

From: John Strassner <[email-masked]>
Date: Tue, 13 Sep 2016 12:29:07 -0700

Hi Sue,

That's a great observation Sue. Let's work together and propose a
combination to the rest of the group.

best regards,
John

On Tue, Sep 13, 2016 at 11:32 AM, Susan Hares <[email-masked]> wrote:

> 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-masked]] *On Behalf Of *Annika
> Sparkles
> *Sent:* Tuesday, September 13, 2016 1:51 PM
> *To:* John Strassner
> *Cc:* Rakesh Kumar; DIEGO LOPEZ GARCIA; [email-masked]; Linda Dunbar;
> Xialiang (Frank); [email-masked]; Susan Hares
> *Subject:* Re: [I2nsf] I2NSF Terminology's definition on "ACL" is

-- 
regards,
John