"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
