Subject: [Dots] Filter name clashes

From: "Jon Shallow" <[email-masked]>
Date: Mon, 8 Jan 2018 10:42:35 -0000

Hi there,

I have realised that we have a serious filter name overwrite issue with the
current data channel spec.

Client-A can define "my-filter" by either going directly through
"access-lists/acl", or
"data-channel:client-identifier=ABC/set-name=my-filter/type=xx".

Client-B can also define "my-filter" - using "access-lists/acl" which will
overwrite Client-A's version, and actually so will
"data-channel:client-identifier=DEF/set-name=my-filter/type=xx" even though
client-identifier= will be different from that of Client A.

I have posted an issue to the netmod-acl
https://github.com/netmod-wg/acl-model/issues asking whether access-lists
could be made a grouping or not.  If this was to happen, we could use "uses
access-lists" underneath a client-identifier.

The alternative could be that we build our own higher level
access-lists/ace/acl etc. tree and then cherry pick the actual "matches" and
"actions" that we want for DOTS (which will save a lot of "augments") - for
example l2 matches make no real sense to DOTS.

Regards

Jon

---

From: "Konda, Tirumaleswar Reddy" <[email-masked]>
Date: Mon, 8 Jan 2018 11:17:19 +0000

Hi Jon,

Even if client-A and client-B use the same ACL name "my-filter", the same ACL name is created by two different clients with different client identities, the server will not override the ACL rule created by one client with another client (i.e. one of the reasons for introducing client-unique). The client must create a ACL rule by using "data-channel:client-unique=ABC/set-name=my-filter/type=xx" and not just use "access-lists/acl".

Cheers,
-Tiru

From: Dots [mailto:[email-masked]] On Behalf Of Jon Shallow
Sent: Monday, January 8, 2018 4:13 PM
To: [email-masked]
Subject: [Dots] Filter name clashes

Hi there,

I have realised that we have a serious filter name overwrite issue with the current data channel spec.

Client-A can define "my-filter" by either going directly through "access-lists/acl", or "data-channel:client-identifier=ABC/set-name=my-filter/type=xx".

Client-B can also define "my-filter" - using "access-lists/acl" which will overwrite Client-A's version, and actually so will "data-channel:client-identifier=DEF/set-name=my-filter/type=xx" even though client-identifier= will be different from that of Client A.

I have posted an issue to the netmod-acl https://github.com/netmod-wg/acl-model/issues asking whether access-lists could be made a grouping or not.  If this was to happen, we could use "uses access-lists" underneath a client-identifier.

The alternative could be that we build our own higher level access-lists/ace/acl etc. tree and then cherry pick the actual "matches" and "actions" that we want for DOTS (which will save a lot of "augments") - for example l2 matches make no real sense to DOTS.

Regards

Jon

---

From: "Jon Shallow" <[email-masked]>
Date: Mon, 8 Jan 2018 11:40:53 -0000

Hi Tiru,

Actually no, there is not uniqueness, as I understand it, in the contents of
"my-filter".  As per the current YANG model (-11)

  augment /ietf-acl:access-lists:
    +--rw client-identifier*   binary

  augment /ietf-acl:access-lists:

    +--rw dots-acl-order

       +--rw acl-set* [set-name type]

          +--rw set-name    -> /ietf-acl:access-lists/acl/acl-name

          +--rw type        -> /ietf-acl:access-lists/acl/acl-type

module: ietf-access-control-list

    +--rw access-lists

       +--rw acl* [acl-type acl-name]

       |  +--rw acl-name    string

       |  ...

       +--rw data-channel:client-identifier*   binary

       +--rw data-channel:dots-acl-order

          +--rw data-channel:acl-set* [set-name type]

             +--rw data-channel:set-name    ->
/ietf-acl:access-lists/acl/acl-name

             +--rw data-channel:type        ->
/ietf-acl:access-lists/acl/acl-type

The set-name points to the common acl-name in
"/ietf-acl:access-lists/acl/acl-name" which will also be "my-filter".

We also do need a way to stop a (rogue) client using "access-lists/acl".

Regards

Jon

From: Konda, Tirumaleswar Reddy
[mailto:[email-masked]] 
Sent: 08 January 2018 11:17
To: Jon Shallow; [email-masked]
Subject: RE: [Dots] Filter name clashes

Hi Jon,

Even if client-A and client-B use the same ACL name "my-filter", the same
ACL name is created by two different clients with different client
identities, the server will not override the ACL rule created by one client
with another client (i.e. one of the reasons for introducing client-unique).
The client must create a ACL rule by using
"data-channel:client-unique=ABC/set-name=my-filter/type=xx" and not just use
"access-lists/acl".

Cheers,

-Tiru

Hi there,

Regards

Jon

---

From: "Konda, Tirumaleswar Reddy" <[email-masked]>
Date: Mon, 8 Jan 2018 14:31:34 +0000

From: Dots [mailto:[email-masked]] On Behalf Of Jon Shallow
Sent: Monday, January 8, 2018 5:11 PM
To: Konda, Tirumaleswar Reddy <[email-masked]>; [email-masked]
Subject: Re: [Dots] Filter name clashes

Hi Tiru,

Actually no, there is not uniqueness, as I understand it, in the contents of "my-filter".  As per the current YANG model (-11)

module: ietf-access-control-list
    +--rw access-lists
       +--rw acl* [acl-type acl-name]
       |  +--rw acl-name    string
       |  ...
       +--rw data-channel:client-identifier*   binary
       +--rw data-channel:dots-acl-order
          +--rw data-channel:acl-set* [set-name type]
             +--rw data-channel:set-name    -> /ietf-acl:access-lists/acl/acl-name
             +--rw data-channel:type        -> /ietf-acl:access-lists/acl/acl-type

The set-name points to the common acl-name in "/ietf-acl:access-lists/acl/acl-name" which will also be "my-filter".

[TR] Yes, but the DOTS server can use both "my-filter" and "client-unique" (or the CUID) to uniquely identify the ACL from a DOTS client. For example, an DOTS server implementation can combine the "acl-name" + "CUID" values to create a unique ACL name.

[TR] DOTS server will not allow unauthorized and unauthenticated DOTS client to install filtering rules; its already discussed in the draft.

-Tiru

Regards

Jon
From: Konda, Tirumaleswar Reddy [mailto:[email-masked]]
Sent: 08 January 2018 11:17
To: Jon Shallow; [email-masked]<mailto:[email-masked]>
Subject: RE: [Dots] Filter name clashes

Hi Jon,

Cheers,
-Tiru

From: Dots [mailto:[email-masked]] On Behalf Of Jon Shallow
Sent: Monday, January 8, 2018 4:13 PM
To: [email-masked]<mailto:[email-masked]>
Subject: [Dots] Filter name clashes

Hi there,

Regards

Jon

---

From: <[email-masked]>
Date: Tue, 9 Jan 2018 10:01:12 +0000

Hi all,

Agree with Tiru.

ACLs need to be bound to a DOTS client(-domain).

Cheers,
Med

De : Dots [mailto:[email-masked]] De la part de Konda, Tirumaleswar Reddy
Envoyé : lundi 8 janvier 2018 12:17
À : Jon Shallow; [email-masked]
Objet : Re: [Dots] Filter name clashes

Hi Jon,

Cheers,
-Tiru

Hi there,

Regards

Jon

---

From: "Jon Shallow" <[email-masked]>
Date: Tue, 9 Jan 2018 12:44:15 -0000

Hi there,

Agreed that the ACLS MUST be bound to a DOTS client or DOTS client-domain if
there is aggregation done by client-domain DOTS gateway (aggregation methods
out of scope).

However, my confusion is over the contents of the final acl-name entry.  The
current YANG tree after augments that we have is

module: ietf-dots-data-channel

    +--rw identifier

       +--rw alias* [alias-name]

          +--rw alias-name           string

          +--rw target-prefix*       inet:ip-prefix

          +--rw target-port-range* [lower-port upper-port]

          |  +--rw lower-port    inet:port-number

          |  +--rw upper-port    inet:port-number

          +--rw target-protocol*     uint8

          +--rw target-fqdn*         inet:domain-name

          +--rw target-uri*          inet:uri

    +--rw access-lists

       |  +--rw acl-name    string

       |  +--rw acl-type    acl-type

       |  +--rw aces

       |  ...

So, set-name + CUID is unique, but it points to
“/ietf-acl:access-lists/acl/acl-name” to select a particular acl-name.  So
how, when going through the YANG tree do we make sure that
“cuid=ABC/set-name=my-filter” and “cuid=DEF/set-name=my-filter” – both
pointing to the common “acl-name=my-filter” end up with 2 “my-filters” that
have the same name (my-filter) but different contents in the “access-list”
branch?

Or are we expecting the DOTS server to somehow combine the entry under
“access-lists” to include both the cuid and my-filter in the acl-name?

I agree that we must enforce no access if an agent goes directly to the
“access-list” branch.

Regards

Jon

From: Dots [mailto: [email-masked]] On Behalf Of
[email-masked]
Sent: 09 January 2018 10:01
To: Konda, Tirumaleswar Reddy; Jon Shallow; [email-masked]
Subject: Re: [Dots] Filter name clashes

Hi all, 

Agree with Tiru. 

Cheers,

Med

De : Dots [mailto:[email-masked]] De la part de Konda, Tirumaleswar
Reddy
Envoyé : lundi 8 janvier 2018 12:17
À : Jon Shallow; [email-masked]
Objet : Re: [Dots] Filter name clashes

Hi Jon,

Even if client-A and client-B use the same ACL name “my-filter”, the same
ACL name is created by two different clients with different client
identities, the server will not override the ACL rule created by one client
with another client (i.e. one of the reasons for introducing client-unique).
The client must create a ACL rule by using
“data-channel:client-unique=ABC/set-name=my-filter/type=xx” and not just use
“access-lists/acl”.

Cheers,

-Tiru

Hi there,

Client-A can define “my-filter” by either going directly through
“access-lists/acl”, or
“data-channel:client-identifier=ABC/set-name=my-filter/type=xx”.

Client-B can also define “my-filter” – using “access-lists/acl” which will
overwrite Client-A’s version, and actually so will
“data-channel:client-identifier=DEF/set-name=my-filter/type=xx” even though
client-identifier= will be different from that of Client A.

I have posted an issue to the netmod-acl
https://github.com/netmod-wg/acl-model/issues asking whether access-lists
could be made a grouping or not.  If this was to happen, we could use “uses
access-lists” underneath a client-identifier.

The alternative could be that we build our own higher level
access-lists/ace/acl etc. tree and then cherry pick the actual “matches” and
“actions” that we want for DOTS (which will save a lot of “augments”) – for
example l2 matches make no real sense to DOTS.

Regards

Jon

---

From: <[email-masked]>
Date: Tue, 9 Jan 2018 13:11:31 +0000

Re-,

A first implementation option would be that the server maintains a repository for each DOTS client(-domain). This approach does not require a change to the current YANG module. The server will invoke the appropriate repository as a function of the client's identity. The association between the repository and the client identity is a local glue.

A second approach consists in using one single repository for all DOTS client(-domains). For this one to work, the module has to be augmented to include a reference to the client identity. The client identity can be the unique identifier (cuid, used to be request-nonce) that is injected by a DOTS client itself and/or, eventually, the identity used for authentication purposes.

Cheers,
Med

De : Jon Shallow [mailto:[email-masked]]
Envoyé : mardi 9 janvier 2018 13:44
À : BOUCADAIR Mohamed IMT/OLN; Konda, Tirumaleswar Reddy; [email-masked]
Objet : RE: [Dots] Filter name clashes

Hi there,

Agreed that the ACLS MUST be bound to a DOTS client or DOTS client-domain if there is aggregation done by client-domain DOTS gateway (aggregation methods out of scope).

However, my confusion is over the contents of the final acl-name entry.  The current YANG tree after augments that we have is

So, set-name + CUID is unique, but it points to "/ietf-acl:access-lists/acl/acl-name" to select a particular acl-name.  So how, when going through the YANG tree do we make sure that "cuid=ABC/set-name=my-filter" and "cuid=DEF/set-name=my-filter" - both pointing to the common "acl-name=my-filter" end up with 2 "my-filters" that have the same name (my-filter) but different contents in the "access-list" branch?

Or are we expecting the DOTS server to somehow combine the entry under "access-lists" to include both the cuid and my-filter in the acl-name?

I agree that we must enforce no access if an agent goes directly to the "access-list" branch.

Regards

Jon

From: Dots [mailto: [email-masked]<mailto:[email-masked]>] On Behalf Of [email-masked]<mailto:[email-masked]>
Sent: 09 January 2018 10:01
To: Konda, Tirumaleswar Reddy; Jon Shallow; [email-masked]<mailto:[email-masked]>
Subject: Re: [Dots] Filter name clashes

Hi all,

Agree with Tiru.

Cheers,
Med

De : Dots [mailto:[email-masked]] De la part de Konda, Tirumaleswar Reddy
Envoyé : lundi 8 janvier 2018 12:17
À : Jon Shallow; [email-masked]<mailto:[email-masked]>
Objet : Re: [Dots] Filter name clashes

Hi Jon,

Cheers,
-Tiru

Hi there,

Regards

Jon