Subject: [Dots] client-identifier: Recurisve signaling & Aggregation

From: <[email-masked]>
Date: Fri, 15 Dec 2017 14:19:44 +0000

Hi all,

To avoid potential conflicts and also in order to help the server select the appropriate policy to enforce, signal/data channel protocol drafts specify a parameter called "client-identifier". The design allows this parameter to carry multiple values.

Putting aside the extensibility argument of the data model, the signal/data channel protocol drafts are silent about the exact use of multiple values.

The potential deployment cases for multiple values are (without making any assumption whether these cases are good/bad deployment choices):

(1)Multiple gateways may be on path. For example, draft-ietf-dots-architecture discusses recursive signaling and also cases where multiple DOTS gateways are involved.

(2)Requests from multiple clients may be aggregated by the same server-side into one single request forwarded to the upstream server. For example, filtering rules received from multiple clients of the same domain may be aggregated in one single request.

The current approach has the merit to not make any assumption on the gateway behavior (e.g., (2)), but it leads to a confusion. For example, a DOTS server does not know whether multiple client-ids supplied in a messages refer to multiple DOTS clients or to a DOTS client and a set of on-path gateways. The protocol documents need to be updated to avoid such confusion. Two options are listed below:

Option 1 (Avoid making any assumption on gateways/proper semantic distinction between clients and on-path gateways)

-    Restrict the usage of 'client-identifier' to carry identifiers of clients, not gateways.

-    On-path gateways may include a new parameter called 'gateway-identifier' to ease contexts retrieval and avoid potential collisions.

An example is provided below:

C=====G1====G1====S

G1 will update the request with 'client-identifier' pointing to C
G2 will update the request with 'gateway-identifier' pointing to G1

Option 2 (Describe what a gateway cannot do)

-    Update the architecture document to indicate that requests are not aggregated by a dots gateway.

-    'client-identifier' includes multiple values only and only if multiple gateways are on-path. The order of the values is important because the first one will be the one pointing to the source DOTS clients.

An example is provided below:

C=====G1====G1====S

G1 will update the request with 'client-identifier' pointing to C
G2 will update the request with 'client-identifier' pointing to G1 (in addition to C)

We are seeking for feedback from the WG on which direction to take.

Thoughts?

Cheers,
Med

---

From: "Jon Shallow" <[email-masked]>
Date: Sat, 16 Dec 2017 20:28:25 -0000

Hi Med and all,

I think that 'gateway-identifier' is likely to cause more confusion and will
not actually help to try and solve what I perceive is the underlying issue
that has triggered this discussion - "How do we handle 'client-identifiers'
when a DOTS gateway does aggregation?".  I am leaning towards your Option 2.
Some of my reasoning is below.

Background to client-identifiers.

In the general case (e.g. no DOTS gateway aggregation of filters / aliases
etc.), every time a request or update (both signal and data) passes upstream
through a DOTS gateway, an additional 'client-identifier' is added to the
request / update.  The final DOTS server can then uniquely identify the
request / update as coming from a specific Client and exactly match, say, an
(possibly non unique alias-name) alias definition sent over the data channel
with a (possibly non unique mitigation-id) mitigation request using the same
alias-name sent over the signal channel.

Client Identification Usage Example

DOTS client (C1aj) ------------------------------------- (S1j) DOTS gateway
J (C2j) ----------\   

DOTS client (C1bj) ----------------------------------------/
|

|

DOTS client (C1ax) ----- (S1x) DOTS gateway X (C2x) ---- (S2k) DOTS gateway
K (C3k) -------- (S3)    

DOTS client (C1bx) --------/                               |

                                                           |

DOTS client (C1ay) ----- (S1y) DOTS gateway Y (C2y) -------/

DOTS client (C1by) --------/

Where CI is 'client-identifier' - a unique hash of the client identification
:-

C1ax does a PUT [alias-name=Server1],

C2x does a PUT [alias-name=Server1&client-identifer=CI(C1ax)],

C3k does a PUT [alias-name=Server1&client-identifer=CI(C1ax),CI(C2x)]

and then S3 uniquely stores this alias-name as
[alias-name=Server1&client-identifer=CI(C1ax),CI(C2x),CI(C3k)]

so that if any of the DOTS clients do a PUT [alias-name=Server1] (with same
alias name) S3 can differentiate them all based on the different CI().

Then when C1ax requests a mitigation with alias-name=Server1, by the time
the request gets to S3, S3 can match the alias-name definition in the
mitigate request with that of
[alias-name=Server1&client-identifer=CI(C1ax),CI(C2x),CI(C3k)].

If C1aj also requests a mitigation with alias-name=Server1, S3 will see the
alias-name as [alias-name=Server1&client-identifer=CI(C1aj),CI(C2j)] and
match accordingly.

As responses come back from S3 to the originating client, the appropriate
CI(cxxx) gets stripped off so the originating client sees no
'client-identifier' fields at all.

This general solution is simple with only one disadvantage - there is a
limit of 20 - 24 client-identifiers (20 - 24 DOTS gateways) that will fit
into a single UDP packet due to MTU restrictions.  However in practice there
are unlikely to be this number of DOTS gateways.  The count varies based on
how much other information needs to be put into the packet.

DOTS Gateway Session aggregation

There is no reason as to why multiple DOTS clients' signal and data requests
cannot be multiplexed into a single session on the DOTS gateway to DOTS
server connection - especially as different client-identifiers separate out
the different requests / responses.

This session aggregation is not the same as signal / data aggregation

NOTE: ietf-dots-architecture Figure 7, 8, 9 and 10 should really read (which
may be where some of the confusion comes in)

Figure 7: Client-Side Gateway with session Aggregation

Figure 8: Client-Side Gateway without session Aggregation

Figure 9: Server-Side Gateway with session Aggregation

Figure 10: Server-Side Gateway without session Aggregation

DOTS Gateway signal / data aggregation challenges

Individual clients in general will generate their unique mitigation requests
- but may have common information (e.g. same protocol, ports, alias-name).
If the mitigation requests are not unique then we have potential conflicts -
not part of this discussion.

Aggregating (unique) mitigation requests on a DOTS gateway could be a
programmatic challenge, unless it is the simple aggregation of all the
different target-prefixes - aggregating different port requirements for
different target-prefixes gets more interesting...  This adds in a lot of
potential complexity with potential for boundary condition error issues.

Aggregation of Filters is at first sight relatively simple - but there then
may be ordering challenges / conflicts - e.g. one filter has an IP that is a
white-list, and another has the same IP as a black-list - both valid in the
respective client environment.  Ordering of conflicting filter information
is important  and I am not sure that a DOTS gateway will do this properly
unless it either has some hints or complex rules to work with - just adding
in complexity where more things can potentially go wrong.

Use of gateway-identifier and client-identifier combination can be used to
partially resolve some of the challenges (e.g. list of client-identifiers
that are allowed to use this aggregated filter rule), but again we are
limited to 20 - 24 *-identifiers in total due to packet MTU.  Even if we for
example say that there is a maximum of 4 DOTS gateways allowed, we then
limit the number of clients that can be aggregated to 16 - 20.  Do we really
want to restrict the number of supported DOTS clients per DOTS gateway if
aggregation is supported?

Regards

Jon

From: Dots [mailto: [email-masked]] On Behalf Of
[email-masked]
Sent: 15 December 2017 14:20
To: [email-masked]
Subject: [Dots] client-identifier: Recurisve signaling & Aggregation

Hi all, 

To avoid potential conflicts and also in order to help the server select the
appropriate policy to enforce, signal/data channel protocol drafts specify a
parameter called "client-identifier". The design allows this parameter to
carry multiple values. 

Putting aside the extensibility argument of the data model, the signal/data
channel protocol drafts are silent about the exact use of multiple values. 

The potential deployment cases for multiple values are (without making any
assumption whether these cases are good/bad deployment choices):

(1)Multiple gateways may be on path. For example,
draft-ietf-dots-architecture discusses recursive signaling and also cases
where multiple DOTS gateways are involved. 

(2)Requests from multiple clients may be aggregated by the same server-side
into one single request forwarded to the upstream server. For example,
filtering rules received from multiple clients of the same domain may be
aggregated in one single request.   

The current approach has the merit to not make any assumption on the gateway
behavior (e.g., (2)), but it leads to a confusion. For example, a DOTS
server does not know whether multiple client-ids supplied in a messages
refer to multiple DOTS clients or to a DOTS client and a set of on-path
gateways. The protocol documents need to be updated to avoid such confusion.
Two options are listed below: 

Option 1 (Avoid making any assumption on gateways/proper semantic
distinction between clients and on-path gateways)

-    Restrict the usage of 'client-identifier' to carry identifiers of
clients, not gateways. 

-    On-path gateways may include a new parameter called
'gateway-identifier' to ease contexts retrieval and avoid potential
collisions.

C=====G1====G2====S

-    Update the architecture document to indicate that requests are not
aggregated by a dots gateway.

-    'client-identifier' includes multiple values only and only if multiple
gateways are on-path. The order of the values is important because the first
one will be the one pointing to the source DOTS clients. 

C=====G1====G2====S

G2 will update the request with 'client-identifier' pointing to G1 (in
addition to C)

Thoughts?

Cheers,

Med

---

From: Chiheb Chebbi <[email-masked]>
Date: Sun, 17 Dec 2017 18:17:12 +0100

Hi all,
I hope you are doing well.I am a security enthusiast from Tunisia.I am new
here, I started reading the drafts and what are you doing is great.I am
wondering if there are some implementations of DOTS (use cases, code
snippets, maybe some clients and servers prototypes etc...) Or is it too
early for a technical implementation? Thank you so much!

Kind regards,
Chiheb

On Dec 15, 2017 3:19 PM, <[email-masked]> wrote:

> Hi all,
>
>
>
> To avoid potential conflicts and also in order to help the server select
> the appropriate policy to enforce, signal/data channel protocol drafts
> specify a parameter called “client-identifier”. The design allows this
> parameter to carry multiple values.
>
>
>
> Putting aside the extensibility argument of the data model, the
> signal/data channel protocol drafts are silent about the exact use of
> multiple values.
>
>
>
> (2)Requests from multiple clients may be aggregated by the same
> server-side into one single request forwarded to the upstream server. For
> example, filtering rules received from multiple clients of the same domain
> may be aggregated in one single request.
>
>
>
> The current approach has the merit to not make any assumption on the
> gateway behavior (e.g., (2)), but it leads to a confusion. For example, a
> DOTS server does not know whether multiple client-ids supplied in a
> messages refer to multiple DOTS clients or to a DOTS client and a set of
> on-path gateways. The protocol documents need to be updated to avoid such
> confusion. Two options are listed below:
>
>
>
> -    Restrict the usage of ‘client-identifier’ to carry identifiers of
> clients, not gateways.
>
> ‘gateway-identifier’ to ease contexts retrieval and avoid potential
> collisions.
>
>
>
> G1 will update the request with ‘client-identifier’ pointing to C
>
> G2 will update the request with ‘gateway-identifier’ pointing to G1
>
>
>
> -    ‘client-identifier’ includes multiple values only and only if
> multiple gateways are on-path. The order of the values is important because
> the first one will be the one pointing to the source DOTS clients.
>
>
>
> G1 will update the request with ‘client-identifier’ pointing to C
>
> G2 will update the request with ‘client-identifier’ pointing to G1 (in
> addition to C)
>
>
>
> _______________________________________________
> Dots mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dots
>
>

---

From: Roman Danyliw <[email-masked]>
Date: Sun, 17 Dec 2017 23:16:05 +0000

Hello Chiheb!

There are a few implementations of DOTS. The following page provides pointers to them and to a public test server:

https://trac.ietf.org/trac/dots

To read more about use cases see:

https://datatracker.ietf.org/doc/draft-ietf-dots-use-cases/

If you have any feedback on what you find, please let us know.

Roman

On Dec 17, 2017, at 12:17, Chiheb Chebbi <[email-masked]<mailto:[email-masked]>> wrote:

Hi all,
I hope you are doing well.I am a security enthusiast from Tunisia.I am new here, I started reading the drafts and what are you doing is great.I am wondering if there are some implementations of DOTS (use cases, code snippets, maybe some clients and servers prototypes etc...) Or is it too early for a technical implementation? Thank you so much!

Kind regards,
Chiheb

On Dec 15, 2017 3:19 PM, <[email-masked]<mailto:[email-masked]>> wrote:
Hi all,

To avoid potential conflicts and also in order to help the server select the appropriate policy to enforce, signal/data channel protocol drafts specify a parameter called “client-identifier”. The design allows this parameter to carry multiple values.

-    Restrict the usage of ‘client-identifier’ to carry identifiers of clients, not gateways.

-    On-path gateways may include a new parameter called ‘gateway-identifier’ to ease contexts retrieval and avoid potential collisions.

C=====G1====G1====S

-    ‘client-identifier’ includes multiple values only and only if multiple gateways are on-path. The order of the values is important because the first one will be the one pointing to the source DOTS clients.

C=====G1====G1====S

G1 will update the request with ‘client-identifier’ pointing to C
G2 will update the request with ‘client-identifier’ pointing to G1 (in addition to C)

Thoughts?

Cheers,
Med

_______________________________________________
Dots mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/dots

_______________________________________________
Dots mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/dots

---

From: kaname nishizuka <[email-masked]>
Date: Mon, 18 Dec 2017 10:30:47 +0900

Hi,

> The final DOTS server can then  uniquely identify the request / update as coming from a specific Client and exactly match, say, an (possibly non unique alias-name) alias definition sent over the data channel with a (possibly non unique mitigation-id) mitigation request using the same alias-name sent over the signal channel.

In order to accomplish this, we need to exclude any chance of seeing non unique client-identifier from a view point of the final DOTS server.

in the latest draft:
The client-identifier attribute SHOULD NOT be
       generated and included by the DOTS client.

I propose making it "MUST NOT":
The client-identifier attribute MUST NOT be
       generated and included by the DOTS client.

or adding the text like this:

The client-identifier attribute SHOULD NOT be generated and included by the DOTS client. If a client-identifier was generated by the DOTS client, the DOTS gateway MUST update the value with zero probability of the same value among different DOTS clients.

thanks,
Kaname

On 2017/12/17 5:28, Jon Shallow wrote:
>
> Hi Med and all,
>
> I think that ‘gateway-identifier’ is likely to cause more confusion and will not actually help to try and solve what I perceive is the underlying issue that has triggered this discussion - “How do we handle ‘client-identifiers’ when a DOTS gateway does aggregation?”.  I am leaning towards your Option 2. Some of my reasoning is below.
>
> *Background to client-identifiers.*
>
> In the general case (e.g. no DOTS gateway aggregation of filters / aliases etc.), every time a request or update (both signal and data) passes upstream through a DOTS gateway, an additional ‘client-identifier’ is added to the request / update.  The final DOTS server can then uniquely identify the request / update as coming from a specific Client and exactly match, say, an (possibly non unique alias-name) alias definition sent over the data channel with a (possibly non unique mitigation-id) mitigation request using the same alias-name sent over the signal channel.
>
> DOTS client (C1aj) ------------------------------------- (S1j) DOTS gateway J (C2j) ----------\
>
> DOTS client (C1bj) ----------------------------------------/                |
>
>                                                           |
>
> DOTS client (C1ax) ----- (S1x) DOTS gateway X (C2x) ---- (S2k) DOTS gateway K (C3k) -------- (S3)
>
> Where CI is ‘client-identifier’ – a unique hash of the client identification :-
>
> and then S3 uniquely stores this alias-name as [alias-name=Server1&client-identifer=CI(C1ax),CI(C2x),CI(C3k)]
>
> so that if any of the DOTS clients do a PUT [alias-name=Server1] (with same alias name) S3 can differentiate them all based on the different CI().
>
> Then when C1ax requests a mitigation with alias-name=Server1, by the time the request gets to S3, S3 can match the alias-name definition in the mitigate request with that of [alias-name=Server1&client-identifer=CI(C1ax),CI(C2x),CI(C3k)].
>
> If C1aj also requests a mitigation with alias-name=Server1, S3 will see the alias-name as [alias-name=Server1&client-identifer=CI(C1aj),CI(C2j)] and match accordingly.
>
> As responses come back from S3 to the originating client, the appropriate CI(cxxx) gets stripped off so the originating client sees no ‘client-identifier’ fields at all.
>
> This general solution is simple with only one disadvantage – there is a limit of 20 - 24 client-identifiers (20 – 24 DOTS gateways) that will fit into a single UDP packet due to MTU restrictions.  However in practice there are unlikely to be this number of DOTS gateways.  The count varies based on how much other information needs to be put into the packet.
>
> *DOTS Gateway Session aggregation*
>
> There is no reason as to why multiple DOTS clients’ signal and data requests cannot be multiplexed into a single session on the DOTS gateway to DOTS server connection – especially as different client-identifiers separate out the different requests / responses.
>
> NOTE: ietf-dots-architecture Figure 7, 8, 9 and 10 should really read (which may be where some of the confusion comes in)
>
> *DOTS Gateway signal / data aggregation challenges*
>
> Individual clients in general will generate their unique mitigation requests – but may have common information (e.g. same protocol, ports, alias-name).  If the mitigation requests are not unique then we have potential conflicts – not part of this discussion.
>
> Aggregating (unique) mitigation requests on a DOTS gateway could be a programmatic challenge, unless it is the simple aggregation of all the different target-prefixes – aggregating different port requirements for different target-prefixes gets more interesting…..  This adds in a lot of potential complexity with potential for boundary condition error issues.
>
> Aggregation of Filters is at first sight relatively simple - but there then may be ordering challenges / conflicts – e.g. one filter has an IP that is a white-list, and another has the same IP as a black-list – both valid in the respective client environment.  Ordering of conflicting filter information is important  and I am not sure that a DOTS gateway will do this properly unless it either has some hints or complex rules to work with – just adding in complexity where more things can potentially go wrong.
>
> Use of gateway-identifier and client-identifier combination can be used to partially resolve some of the challenges (e.g. list of client-identifiers that are allowed to use this aggregated filter rule), but again we are limited to 20 – 24 *-identifiers in total due to packet MTU.  Even if we for example say that there is a maximum of 4 DOTS gateways allowed, we then limit the number of clients that can be aggregated to 16 – 20.  Do we really want to restrict the number of supported DOTS clients per DOTS gateway if aggregation is supported?
>
> Regards
>
> Jon
>
> *From:*Dots [mailto: [email-masked]] *On Behalf Of [email-masked]
> *Sent:* 15 December 2017 14:20
> *To:* [email-masked]
> *Subject:* [Dots] client-identifier: Recurisve signaling & Aggregation
>
> Hi all,
>
> -Restrict the usage of ‘client-identifier’ to carry identifiers of clients, not gateways.
>
> -On-path gateways may include a new parameter called ‘gateway-identifier’ to ease contexts retrieval and avoid potential collisions.
>
> -Update the architecture document to indicate that requests are not aggregated by a dots gateway.
>
> -‘client-identifier’ includes multiple values only and only if multiple gateways are on-path. The order of the values is important because the first one will be the one pointing to the source DOTS clients.
>
> __

---

From: <[email-masked]>
Date: Mon, 18 Dec 2017 06:59:22 +0000

Hi Jon,

Thank you for sharing your thoughts.

Please see comments inline.

Cheers,
Med

De : Jon Shallow [mailto:[email-masked]]
Envoyé : samedi 16 décembre 2017 21:28
À : BOUCADAIR Mohamed IMT/OLN; [email-masked]
Objet : RE: [Dots] client-identifier: Recurisve signaling & Aggregation

Hi Med and all,

I think that 'gateway-identifier' is likely to cause more confusion and will not actually help to try and solve what I perceive is the underlying issue that has triggered this discussion - "How do we handle 'client-identifiers' when a DOTS gateway does aggregation?"
[Med] There are also some complications even when no aggregation is in use. See below.

.  I am leaning towards your Option 2.  Some of my reasoning is below.

In the general case (e.g. no DOTS gateway aggregation of filters / aliases etc.), every time a request or update (both signal and data) passes upstream through a DOTS gateway, an additional 'client-identifier' is added to the request / update.  The final DOTS server can then uniquely identify the request / update as coming from a specific Client and exactly match, say, an (possibly non unique alias-name) alias definition sent over the data channel with a (possibly non unique mitigation-id) mitigation request using the same alias-name sent over the signal channel.

Where CI is 'client-identifier' - a unique hash of the client identification :-

[Med] This assumes that the DOTS forwarding path will always be the same (that is, the same set of gateways will be solicited for requests coming from a given DOTS client).

I do see some implications of this design in a multi-homing scenario with the same mitigation provider: the same request from a multi-homed DOTS client will be presented to the server as being distinct requests...while this is not. It may be the same request that is forked among existent network attachments or a request that is sent over a first link, but a subsequent one over another link.

Separating both client-id from gateway-id does not suffer from this issue (even when no aggregation).

As responses come back from S3 to the originating client, the appropriate CI(cxxx) gets stripped off so the originating client sees no 'client-identifier' fields at all.

This general solution is simple with only one disadvantage - there is a limit of 20 - 24 client-identifiers (20 - 24 DOTS gateways) that will fit into a single UDP packet due to MTU restrictions.  However in practice there are unlikely to be this number of DOTS gateways.  The count varies based on how much other information needs to be put into the packet.

There is no reason as to why multiple DOTS clients' signal and data requests cannot be multiplexed into a single session on the DOTS gateway to DOTS server connection - especially as different client-identifiers separate out the different requests / responses.

[Med] Agree.

Individual clients in general will generate their unique mitigation requests - but may have common information (e.g. same protocol, ports, alias-name).  If the mitigation requests are not unique then we have potential conflicts - not part of this discussion.

Aggregating (unique) mitigation requests on a DOTS gateway could be a programmatic challenge, unless it is the simple aggregation of all the different target-prefixes - aggregating different port requirements for different target-prefixes gets more interesting.....  This adds in a lot of potential complexity with potential for boundary condition error issues.

Aggregation of Filters is at first sight relatively simple - but there then may be ordering challenges / conflicts - e.g. one filter has an IP that is a white-list, and another has the same IP as a black-list - both valid in the respective client environment.  Ordering of conflicting filter information is important  and I am not sure that a DOTS gateway will do this properly unless it either has some hints or complex rules to work with - just adding in complexity where more things can potentially go wrong.

Use of gateway-identifier and client-identifier combination can be used to partially resolve some of the challenges (e.g. list of client-identifiers that are allowed to use this aggregated filter rule), but again we are limited to 20 - 24 *-identifiers in total due to packet MTU.  Even if we for example say that there is a maximum of 4 DOTS gateways allowed, we then limit the number of clients that can be aggregated to 16 - 20.  Do we really want to restrict the number of supported DOTS clients per DOTS gateway if aggregation is supported?

[Med] I guess you meant "restrict the number of aggregated clients per DOTS gateway", not the "number of DOTS clients serviced by a DOTS gateway". I would say this is deployment-specific. A deployment that enables signal/data channel aggregation is aware of this limitation.

Regards

Jon

From: Dots [mailto: [email-masked]<mailto:[email-masked]>] On Behalf Of [email-masked]<mailto:[email-masked]>
Sent: 15 December 2017 14:20
To: [email-masked]<mailto:[email-masked]>
Subject: [Dots] client-identifier: Recurisve signaling & Aggregation

Hi all,

C=====G1====G2====S

C=====G1====G2====S

Thoughts?

Cheers,
Med

---

From: <[email-masked]>
Date: Mon, 18 Dec 2017 07:12:23 +0000

Hi Kaname,

« s/SHOULD NOT/MUST NOT » works for me.

The issue discussed in this thread is still open, though.

Cheers,
Med

De : kaname nishizuka [mailto:[email-masked]]
Envoyé : lundi 18 décembre 2017 02:31
À : Jon Shallow; BOUCADAIR Mohamed IMT/OLN; [email-masked]
Objet : Re: [Dots] client-identifier: Recurisve signaling & Aggregation

Hi,

in the latest draft:

thanks,
Kaname

I think that 'gateway-identifier' is likely to cause more confusion and will not actually help to try and solve what I perceive is the underlying issue that has triggered this discussion - "How do we handle 'client-identifiers' when a DOTS gateway does aggregation?".  I am leaning towards your Option 2.  Some of my reasoning is below.

Regards

Jon

Hi all,

(1)       Multiple gateways may be on path. For example, draft-ietf-dots-architecture discusses recursive signaling and also cases where multiple DOTS gateways are involved.

(2)       Requests from multiple clients may be aggregated by the same server-side into one single request forwarded to the upstream server. For example, filtering rules received from multiple clients of the same domain may be aggregated in one single request.

C=====G1====G2====S

C=====G1====G2====S

Thoughts?

Cheers,
Med

Dots mailing list

---

From: "Jon Shallow" <[email-masked]>
Date: Mon, 18 Dec 2017 10:39:52 -0000

Hi Med / Kaname,

“I propose making it "MUST NOT":
The client-identifier attribute MUST NOT be
      generated and included by the DOTS client.”

We do need to handle the case of a broken client (how does the DOTS server
know it is a DOTS gateway client or a real DOTS client?) who does not obey
the MUST.

“The client-identifier attribute SHOULD NOT be generated and included by the
DOTS client. If a client-identifier was generated by the DOTS client, the
DOTS gateway MUST update the value with zero probability of the same value
among different DOTS clients.”

Is the safer option for me.

Otherwise, see [Jon] inline (8 times).

Regards

Jon

From: Dots [mailto: [email-masked]] On Behalf Of
[email-masked]
Sent: 18 December 2017 06:59
To: Jon Shallow; [email-masked]
Subject: Re: [Dots] client-identifier: Recurisve signaling & Aggregation

Hi Jon, 

Cheers,

Med

Hi Med and all,

I think that ‘gateway-identifier’ is likely to cause more confusion and will
not actually help to try and solve what I perceive is the underlying issue
that has triggered this discussion - “How do we handle ‘client-identifiers’
when a DOTS gateway does aggregation?”

[Med] There are also some complications even when no aggregation is in use.
See below. 

through a DOTS gateway, an additional ‘client-identifier’ is added to the

|

                                                           |

 

Where CI is ‘client-identifier’ – a unique hash of the client identification
:-

[Med] This assumes that the DOTS forwarding path will always be the same
(that is, the same set of gateways will be solicited for requests coming
from a given DOTS client).

[Jon] The current text states “If the 'client-identifier' value is already
present in the

   mitigation request received from the DOTS client, the DOTS gateway

   MAY compute the 'client-identifier' value, as discussed above, and

   add the computed 'client-identifier' value to the end of the 'client-

   identifier' list.”

[Jon]  The MAY is not a MUST for the simple reason that if the original DOTS
client client-identifier is computed correctly, it should be unique all the
way through the different DOTS gateways (so no additional client-identifiers
need to get added) so that S3 just sees
[alias-name=Server1&client-identifer=CI(C1ax)].  The DOTS gateways in the
path can then change over time with no issues.

[Jon] All that is required then is that a DOTS gateway makes sure that any
Client-Identifiers are unique for all its clients (including clients behind
gateways) and so does not need to add in additional client-identifiers (but
still adds in the first one if the first DOTS gateway).

[Jon] NOTE: A DOTS gateway can elect to not add in any client-identifier –
even if it is the first in the chain if it wants to hide the client
information, but this will potentially cause information differentiation
issues at the DOTS server and I would not recommend it as
client-identifiers, if created properly, obfuscate the actual client
information.

[Med]I do see some implications of this design in a multi-homing scenario
with the same mitigation provider: the same request from a multi-homed DOTS
client will be presented to the server as being distinct requests…while this
is not. It may be the same request that is forked among existent network
attachments or a request that is sent over a first link, but a subsequent
one over another link.

[Jon] Perhaps I am missing something here, but I would be expecting a
multi-homed device to be using the same PKI certificate (or equivalent) in
which case the client-identifier (which is not IP based) would be the same
over the different network interfaces.  

[Jon] If however, the different network interfaces are connected to
different DOTS provider domains, then there will be multiple PKI certs, and
hence different client-identifiers propagating up to the DOTS servers – but
as these are different provider domains will they ever join up into a common
domain?  If they do, then this is where you could be getting conflicting
requests – subject of another discussion.

[Med] Separating both client-id from gateway-id does not suffer from this
issue (even when no aggregation).    

[Jon] Yes – the assumption being that all the client-identifiers are unique
– In which case I argue again that additional information – e.g.
gateway-identifiers are irrelevant (and also are useless when there are
multiple paths through the DOTS gateways as you refer to above).

As responses come back from S3 to the originating client, the appropriate
CI(cxxx) gets stripped off so the originating client sees no
‘client-identifier’ fields at all.

This general solution is simple with only one disadvantage – there is a
limit of 20 - 24 client-identifiers (20 – 24 DOTS gateways) that will fit
into a single UDP packet due to MTU restrictions.  However in practice there
are unlikely to be this number of DOTS gateways.  The count varies based on
how much other information needs to be put into the packet.

There is no reason as to why multiple DOTS clients’ signal and data requests
cannot be multiplexed into a single session on the DOTS gateway to DOTS
server connection – especially as different client-identifiers separate out
the different requests / responses.

[Med] Agree. 

Individual clients in general will generate their unique mitigation requests
– but may have common information (e.g. same protocol, ports, alias-name).
If the mitigation requests are not unique then we have potential conflicts –
not part of this discussion.

Aggregating (unique) mitigation requests on a DOTS gateway could be a
programmatic challenge, unless it is the simple aggregation of all the
different target-prefixes – aggregating different port requirements for
different target-prefixes gets more interesting…..  This adds in a lot of
potential complexity with potential for boundary condition error issues.

Aggregation of Filters is at first sight relatively simple - but there then
may be ordering challenges / conflicts – e.g. one filter has an IP that is a
white-list, and another has the same IP as a black-list – both valid in the
respective client environment.  Ordering of conflicting filter information
is important  and I am not sure that a DOTS gateway will do this properly
unless it either has some hints or complex rules to work with – just adding
in complexity where more things can potentially go wrong.

Use of gateway-identifier and client-identifier combination can be used to
partially resolve some of the challenges (e.g. list of client-identifiers
that are allowed to use this aggregated filter rule), but again we are
limited to 20 – 24 *-identifiers in total due to packet MTU.  Even if we for
example say that there is a maximum of 4 DOTS gateways allowed, we then
limit the number of clients that can be aggregated to 16 – 20.  Do we really
want to restrict the number of supported DOTS clients per DOTS gateway if
aggregation is supported?

[Med] I guess you meant “restrict the number of aggregated clients per DOTS
gateway”, not the “number of DOTS clients serviced by a DOTS gateway”. I
would say this is deployment-specific. A deployment that enables signal/data
channel aggregation is aware of this limitation. 

[Jon] Yes, that is better phrasing.  I still struggle with how do you
actually do the aggregation (merging of data/signal) at any gateway other
than in a couple of simple cases out of the many different scenarios.

Regards

Jon

Hi all, 

To avoid potential conflicts and also in order to help the server select the
appropriate policy to enforce, signal/data channel protocol drafts specify a
parameter called “client-identifier”. The design allows this parameter to
carry multiple values. 

C=====G1====G2====S

-    ‘client-identifier’ includes multiple values only and only if multiple
gateways are on-path. The order of the values is important because the first
one will be the one pointing to the source DOTS clients. 

C=====G1====G2====S

Thoughts?

Cheers,

Med

---

From: <[email-masked]>
Date: Mon, 18 Dec 2017 12:27:44 +0000

Re-,

Please see inline.

Cheers,
Med

De : Jon Shallow [mailto:[email-masked]]
Envoyé : lundi 18 décembre 2017 11:40
À : BOUCADAIR Mohamed IMT/OLN; [email-masked]; kaname nishizuka
Objet : RE: [Dots] client-identifier: Recurisve signaling & Aggregation

Hi Med / Kaname,

"I propose making it "MUST NOT":
The client-identifier attribute MUST NOT be
      generated and included by the DOTS client."
We do need to handle the case of a broken client (how does the DOTS server know it is a DOTS gateway client or a real DOTS client?) who does not obey the MUST.
[Med] ...but broken clients may communicate directly with servers without any gateway on the path.

"The client-identifier attribute SHOULD NOT be generated and included by the DOTS client. If a client-identifier was generated by the DOTS client, the DOTS gateway MUST update the value with zero probability of the same value among different DOTS clients."

[Med] Actually,

·         (R1) we do need MUST so that as a general rule clients do not insert a client-id parameter in their requests.

·         And (R2) DOTS servers MUST ignore client-ids that are supplied by the origin DOTS clients.

In deployments without gateways, client-ids supplied by broken DOTS clients will be ignored by the server as per R2.
In deployments with gateways, the first server-side gateway will follow R2 and strip any value supplied by the client.

If we add text to cover (R2), I don't think we need a sentence about updating the content because client-id is a value that is ***assigned*** exclusively by a dots gateway:

      The 'client-identifier' value MUST be assigned by the DOTS gateway
                                    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
      in a manner that ensures that there is zero probability that the
      same value will be assigned to a different DOTS client.

Regards

Jon

From: Dots [mailto: [email-masked]<mailto:[email-masked]>] On Behalf Of [email-masked]<mailto:[email-masked]>
Sent: 18 December 2017 06:59
To: Jon Shallow; [email-masked]<mailto:[email-masked]>
Subject: Re: [Dots] client-identifier: Recurisve signaling & Aggregation

Hi Jon,

Cheers,
Med

De : Jon Shallow [mailto:[email-masked]]
Envoyé : samedi 16 décembre 2017 21:28
À : BOUCADAIR Mohamed IMT/OLN; [email-masked]<mailto:[email-masked]>
Objet : RE: [Dots] client-identifier: Recurisve signaling & Aggregation

Hi Med and all,

[Jon] The current text states "If the 'client-identifier' value is already present in the
   mitigation request received from the DOTS client, the DOTS gateway
   MAY compute the 'client-identifier' value, as discussed above, and
   add the computed 'client-identifier' value to the end of the 'client-
   identifier' list."

[Jon]  The MAY is not a MUST for the simple reason that if the original DOTS client client-identifier is computed correctly, it should be unique all the way through the different DOTS gateways (so no additional client-identifiers need to get added) so that S3 just sees [alias-name=Server1&client-identifer=CI(C1ax)].  The DOTS gateways in the path can then change over time with no issues.

[Jon] All that is required then is that a DOTS gateway makes sure that any Client-Identifiers are unique for all its clients (including clients behind gateways) and so does not need to add in additional client-identifiers (but still adds in the first one if the first DOTS gateway).
[Med] Agree for the first server-side gateway.

[Jon] NOTE: A DOTS gateway can elect to not add in any client-identifier - even if it is the first in the chain if it wants to hide the client information, but this will potentially cause information differentiation issues at the DOTS server and I would not recommend it as client-identifiers, if created properly, obfuscate the actual client information.

[Med]I do see some implications of this design in a multi-homing scenario with the same mitigation provider: the same request from a multi-homed DOTS client will be presented to the server as being distinct requests...while this is not. It may be the same request that is forked among existent network attachments or a request that is sent over a first link, but a subsequent one over another link.

[Jon] Perhaps I am missing something here, but I would be expecting a multi-homed device to be using the same PKI certificate (or equivalent) in which case the client-identifier (which is not IP based) would be the same over the different network interfaces.
[Med] I'm referring to this "[alias-name=Server1&client-identifer=CI(C1ax),CI(C2x),CI(C3k)]".

[Jon] If however, the different network interfaces are connected to different DOTS provider domains, then there will be multiple PKI certs, and hence different client-identifiers propagating up to the DOTS servers - but as these are different provider domains will they ever join up into a common domain?  If they do, then this is where you could be getting conflicting requests - subject of another discussion.
[Med] Sure, these are deployment-specific. My concern is to avoid design choices that make hidden assumptions.

[Med] Separating both client-id from gateway-id does not suffer from this issue (even when no aggregation).

[Jon] Yes - the assumption being that all the client-identifiers are unique - In which case I argue again that additional information - e.g. gateway-identifiers are irrelevant (and also are useless when there are multiple paths through the DOTS gateways as you refer to above).
[Med] If we agree that one (unique) client-id is supplied, then I'm fine.

[Med] Agree.

[Jon] Yes, that is better phrasing.
[Med] OK.

  I still struggle with how do you actually do the aggregation (merging of data/signal) at any gateway other than in a couple of simple cases out of the many different scenarios.
[Med] Please note that I used "good/bad deployment choices" in the initial message. Merging the requests will induce some complexity at the gateway, sure. From a protocol standpoint, I'm trying to be neutral on this. My main concern is to avoid making choices in the protocol that will have deployment implications.

Regards

Jon

Hi all,

C=====G1====G2====S

C=====G1====G2====S

Thoughts?

Cheers,
Med

---

From: <[email-masked]>
Date: Mon, 18 Dec 2017 13:04:15 +0000

Jon,

Please see below two proposed changes to hopefully conclude on the issues discussed in this thread:

1st change:

OLD:
   client-identifier:  The client identifier MAY be conveyed by the DOTS
      gateway to propagate the DOTS client identity from the gateway's
      client-side to the gateway's server-side, and from the gateway's
      server-side to the DOTS server.  This allows the DOTS server to
      accept mitigation requests with scopes which the DOTS client is
     authorized to manage.

      The 'client-identifier' value MUST be assigned by the DOTS gateway
      in a manner that ensures that there is zero probability that the
      same value will be assigned to a different DOTS client.  The DOTS
      gateway MUST conceal potentially sensitive DOTS client identity
      information.  The client-identifier attribute SHOULD NOT be
      generated and included by the DOTS client.

      This is an optional attribute.

NEW:
   client-identifier:  The client identifier MAY be conveyed by a
      server-side DOTS gateway to propagate the DOTS client identity
      from the gateway's client-side to the gateway's server-side, and
      from the gateway's server-side to the DOTS server. 'client-
      identifier' MAY be used by the final DOTS server for policy
      enforcement purposes.

      The 'client-identifier' value MUST be assigned by the server-side
      DOTS gateway in a manner that ensures that there is zero
      probability that the same value will be assigned to a different
      DOTS client.  The server-side DOTS gateway MUST conceal
      potentially sensitive DOTS client identity information.

      If aggregating DOTS mitigation requests received from multiple
      DOTS clients is enabled, the server-side DOTS gateway has to include
      a list of 'client-identifier' values; each value is pointing to a
      DOTS client.  It is out of scope of this document to specify how
      aggregation is implemented by a DOTS gateway.

      The client-identifier attribute MUST NOT be generated and included
      by DOTS clients.

      DOTS servers MUST ignore client-identifier attributes that are
      directly supplied by source DOTS clients.  This implies that first
      server-side DOTS gateways MUST strip client-identifier attributes
      supplied by DOTS clients.

      This is an optional attribute.

2nd change: Delete this text because client-identifier is uniquely assigned by the first server-side gateway; there is no need to prepend identifiers computed by other gateways.

OLD:
   If the 'client-identifier' value is already present in the
   mitigation request received from the DOTS client, the DOTS gateway
   MAY compute the 'client-identifier' value, as discussed above, and
   add the computed 'client-identifier' value to the end of the 'client-
   identifier' list.

Comments and modifications are more welcome.

Cheers,
Med

De : Dots [mailto:[email-masked]] De la part de [email-masked]
Envoyé : lundi 18 décembre 2017 13:28
À : Jon Shallow; [email-masked]; kaname nishizuka
Objet : Re: [Dots] client-identifier: Recurisve signaling & Aggregation

Re-,

Please see inline.

Cheers,
Med

De : Jon Shallow [mailto:[email-masked]]
Envoyé : lundi 18 décembre 2017 11:40
À : BOUCADAIR Mohamed IMT/OLN; [email-masked]<mailto:[email-masked]>; kaname nishizuka
Objet : RE: [Dots] client-identifier: Recurisve signaling & Aggregation

Hi Med / Kaname,

[Med] Actually,

Regards

Jon

Hi Jon,

Cheers,
Med

Hi Med and all,

[Med] Agree.

Regards

Jon

Hi all,

C=====G1====G2====S

C=====G1====G2====S

Thoughts?

Cheers,
Med

---

From: "Jon Shallow" <[email-masked]>
Date: Mon, 18 Dec 2017 13:53:55 -0000

Hi Med,

Going in the right direction, but see comments inline [Jon1].

As a side comment, I always have to think twice what “DOTS gateway
server-side” actually means.  It actually means the DOTS client component
logic of a DOTS gateway.  There is no definition of terms in the signal
channel draft, but the definition could perhaps be added to the dots
requirements draft.  Others may also get confused about this.  Perhaps “DOTS
gateway server-facing-side” is clearer, even though much longer to type!

Regards

Jon

From: Dots [mailto: [email-masked]] On Behalf Of
[email-masked]
Sent: 18 December 2017 13:04
To: Jon Shallow; [email-masked]; kaname nishizuka
Subject: Re: [Dots] client-identifier: Recurisve signaling & Aggregation

Jon, 

Please see below two proposed changes to hopefully conclude on the issues
discussed in this thread:

1st change: 

OLD:

     authorized to manage.

NEW:

      enforcement purposes.

[Jon1]  Actually, as the client and server components of a DOTs gateway are
separate (the server-facing component has no real knowledge of what is
happening on the client-facing side), it needs to be the client-facing-side
of the DOTS gateway that assigns the (unique) client-identifier which is
then passed over to the server-facing-side for onward transmission.

[Jon1] I prefer “a list of 'client-identifier' values; each value is
pointing to a unique

      DOTS client that is in the aggregated list.  It is out of….”

      by DOTS clients.

[Jon1] How do we differentiate between an actual DOTS client and the client
component of a DOTS gateway (i.e. server-facing-side) as seen by a DOTS
server?  There is nothing that I have spotted for this in the DOTS signal
protocol.

[Jon1] I do agree that true DOTS clients MUST NOT generate
‘client-identifiers’. If only the DOTS gateway server component
(client-facing-side) is allowed to generate the client-identifier (for
possible onward forwarding), this gets around this issue as it is only the
DOTS server component who is allowed to do the generation.

[Jon1] In my implementation the DOTS server (gateway or not) always
generates a client-identifier (will be changed if there already is a unique
identifier following this discussion) which is associated with a
mitigation-id etc. so that the DOTS server can differentiate between the
same mitigation-id from different clients.

2nd change: Delete this text because client-identifier is uniquely assigned
by the first server-side gateway; there is no need to prepend identifiers
computed by other gateways. 

OLD:

   identifier' list.

[Jon1] OK 

Cheers,

Med

De : Dots [mailto:[email-masked]] De la part de

Re-,

Please see inline.

Cheers,

Med

Hi Med / Kaname,

[Med] …but broken clients may communicate directly with servers without any
gateway on the path. 

[Med] Actually, 

·         (R1) we do need MUST so that as a general rule clients do not
insert a client-id parameter in their requests. 

·         And (R2) DOTS servers MUST ignore client-ids that are supplied by
the origin DOTS clients. 

In deployments without gateways, client-ids supplied by broken DOTS clients
will be ignored by the server as per R2. 

In deployments with gateways, the first server-side gateway will follow R2
and strip any value supplied by the client. 

If we add text to cover (R2), I don’t think we need a sentence about
updating the content because client-id is a value that is ***assigned***
exclusively by a dots gateway:

Regards

Jon

Hi Jon, 

Cheers,

Med

Hi Med and all,

|

                                                           |

 

   identifier' list.”

[Med] I’m referring to this
“[alias-name=Server1&client-identifer=CI(C1ax),CI(C2x),CI(C3k)]”.

[Med] Sure, these are deployment-specific. My concern is to avoid design
choices that make hidden assumptions.  

[Med] If we agree that one (unique) client-id is supplied, then I’m fine. 

[Med] Agree. 

[Med] OK. 

  I still struggle with how do you actually do the aggregation (merging of
data/signal) at any gateway other than in a couple of simple cases out of
the many different scenarios.

[Med] Please note that I used “good/bad deployment choices” in the initial
message. Merging the requests will induce some complexity at the gateway,
sure. From a protocol standpoint, I’m trying to be neutral on this. My main
concern is to avoid making choices in the protocol that will have deployment
implications.

Regards

Jon

Hi all, 

C=====G1====G2====S

C=====G1====G2====S

Thoughts?

Cheers,

Med

---

From: <[email-masked]>
Date: Mon, 18 Dec 2017 14:27:07 +0000

Re-,

Please see inline.

Cheers,
Med

De : Jon Shallow [mailto:[email-masked]]
Envoyé : lundi 18 décembre 2017 14:54
À : BOUCADAIR Mohamed IMT/OLN; [email-masked]; kaname nishizuka
Objet : RE: [Dots] client-identifier: Recurisve signaling & Aggregation

Hi Med,

As a side comment, I always have to think twice what "DOTS gateway server-side" actually means.  It actually means the DOTS client component logic of a DOTS gateway.  There is no definition of terms in the signal channel draft, but the definition could perhaps be added to the dots requirements draft.  Others may also get confused about this.  Perhaps "DOTS gateway server-facing-side" is clearer, even though much longer to type!

[Med] We do have the following definition in the requirements I-D:

      Client-side DOTS gateways
      are DOTS gateways that are in the DOTS client's domain, while
      server-side DOTS gateways denote DOTS gateways that are in the
      DOTS server's domain.

Regards

Jon

From: Dots [mailto: [email-masked]<mailto:[email-masked]>] On Behalf Of [email-masked]<mailto:[email-masked]>
Sent: 18 December 2017 13:04
To: Jon Shallow; [email-masked]<mailto:[email-masked]>; kaname nishizuka
Subject: Re: [Dots] client-identifier: Recurisve signaling & Aggregation

Jon,

1st change:

OLD:

NEW:

      The 'client-identifier' value MUST be assigned by the server-side
[Jon1]  Actually, as the client and server components of a DOTs gateway are separate (the server-facing component has no real knowledge of what is happening on the client-facing side), it needs to be the client-facing-side of the DOTS gateway that assigns the (unique) client-identifier which is then passed over to the server-facing-side for onward transmission.

[Med] You are right if we zoom on the internal implementation of a DOTS gateway. This part of the text focuses on the external behavior of the DOTS gateway. The text does not need to zoom in given that the second sentence above says;

"to propagate the DOTS client identity from the gateway's
      client-side to the gateway's server-side, and from the gateway's
      server-side to the DOTS server. "

      If aggregating DOTS mitigation requests received from multiple
      DOTS clients is enabled, the server-side DOTS gateway has to include
      a list of 'client-identifier' values; each value is pointing to a
      DOTS client.  It is out of scope of this document to specify how
[Jon1] I prefer "a list of 'client-identifier' values; each value is pointing to a unique
      DOTS client that is in the aggregated list.  It is out of...."

[Med] Deal.

[Jon1] How do we differentiate between an actual DOTS client and the client component of a DOTS gateway (i.e. server-facing-side) as seen by a DOTS server?  There is nothing that I have spotted for this in the DOTS signal protocol.

[Med] I confirm, there is no such text in the draft. A deployment would consist in explicitly configuring a list of gateways (ACLs) on the server; the server will trust client-id if and only if it is coming from a server-side gateways in that list.

[Jon1] I do agree that true DOTS clients MUST NOT generate 'client-identifiers'. If only the DOTS gateway server component (client-facing-side) is allowed to generate the client-identifier (for possible onward forwarding), this gets around this issue as it is only the DOTS server component who is allowed to do the generation.

[Jon1] In my implementation the DOTS server (gateway or not) always generates a client-identifier (will be changed if there already is a unique identifier following this discussion) which is associated with a mitigation-id etc. so that the DOTS server can differentiate between the same mitigation-id from different clients.
[Med] Ok, thanks.

OLD:

Cheers,
Med

De : Dots [mailto:[email-masked]] De la part de [email-masked]<mailto:[email-masked]>
Envoyé : lundi 18 décembre 2017 13:28
À : Jon Shallow; [email-masked]<mailto:[email-masked]>; kaname nishizuka
Objet : Re: [Dots] client-identifier: Recurisve signaling & Aggregation

Re-,

Please see inline.

Cheers,
Med

Hi Med / Kaname,

[Med] Actually,

Regards

Jon

Hi Jon,

Cheers,
Med

Hi Med and all,

[Med] Agree.

Regards

Jon

Hi all,

C=====G1====G2====S

C=====G1====G2====S

Thoughts?

Cheers,
Med

---

From: "Jon Shallow" <[email-masked]>
Date: Mon, 18 Dec 2017 14:50:39 -0000

Hi Med,

See inline [Jon2].

Regards

Jon

Sent: 18 December 2017 14:27

Re-,

Please see inline.

Cheers,

Med

Hi Med,

      DOTS server's domain.

[Jon2] Yes – actually, this adds to the confusion in my mind.  For a
singular DOTS gateway, it could have a client-facing-side that is in the
DOTS client domain, and a server-facing side that is in a different DOTS
server domain.  The quoted text implies it is one or the other, but not
both.

[Jon2] Also, being picky, does “Client-side DOTS gateway” (type of DOTS
gateway) actually mean the same as “DOTS gateway client-side” (component
within a DOTS gateway)?

Regards

Jon

Jon, 

1st change: 

OLD:

     authorized to manage.

NEW:

      enforcement purposes.

[Med] You are right if we zoom on the internal implementation of a DOTS
gateway. This part of the text focuses on the external behavior of the DOTS
gateway. The text does not need to zoom in given that the second sentence
above says; 

[Jon2] In terms of helping the implementers, the use of only DOTS server
being allowed to generate a ‘client-identifier’ as discussed later.  If
“server-side” was removed as in :-

“client-identifier:  The client identifier MAY be conveyed by a

      DOTS gateway to propagate the DOTS client identity …”

Removes a lot of confusion in my mind.

“to propagate the DOTS client identity from the gateway's

      server-side to the DOTS server. ”

[Med] Deal.  

      by DOTS clients.

[Med] I confirm, there is no such text in the draft. A deployment would
consist in explicitly configuring a list of gateways (ACLs) on the server;
the server will trust client-id if and only if it is coming from a
server-side gateways in that list.

[Jon2] Then do we need to instruct the implementers of the signal channel
that this is what should be done?

[Med] Ok, thanks.

OLD:

   identifier' list.

[Jon1] OK 

Cheers,

Med

Re-,

Please see inline.

Cheers,

Med

Hi Med / Kaname,

[Med] Actually, 

Regards

Jon

Hi Jon, 

Cheers,

Med

Hi Med and all,

|

                                                           |

 

   identifier' list.”

 

[Med] Agree. 

[Med] OK. 

Regards

Jon

Hi all, 

C=====G1====G2====S

C=====G1====G2====S

Thoughts?

Cheers,

Med

---

From: <[email-masked]>
Date: Mon, 18 Dec 2017 15:13:32 +0000

Re-,

Please see inline.

Cheers,
Med

De : Jon Shallow [mailto:[email-masked]]
Envoyé : lundi 18 décembre 2017 15:51
À : BOUCADAIR Mohamed IMT/OLN; [email-masked]; kaname nishizuka
Objet : RE: [Dots] client-identifier: Recurisve signaling & Aggregation

Hi Med,

See inline [Jon2].

Regards

Jon

Re-,

Please see inline.

Cheers,
Med

Hi Med,

[Jon2] Yes - actually, this adds to the confusion in my mind.  For a singular DOTS gateway, it could have a client-facing-side that is in the DOTS client domain, and a server-facing side that is in a different DOTS server domain.  The quoted text implies it is one or the other, but not both.
[Med] Do you have a particular case in mind in which we should allow for the "client-facing side" of a gateway to belong to the client domain and its "server-facing side" to belong to the server domain?

[Jon2] Also, being picky, does "Client-side DOTS gateway" (type of DOTS gateway) actually mean the same as "DOTS gateway client-side" (component within a DOTS gateway)?
[Med] No. Those are two distinct things/dimensions:

-    "xxx-side DOTS gateway" means this is owned and operated by xxx.

-    "DOTS gateway client-side" refers to the client-facing interface of a DTOS gateway. It applies for both client- and server-side getaways.

Regards

Jon

Jon,

1st change:

OLD:

NEW:

[Jon2] In terms of helping the implementers, the use of only DOTS server being allowed to generate a 'client-identifier' as discussed later.  If "server-side" was removed as in :-
"client-identifier:  The client identifier MAY be conveyed by a
      DOTS gateway to propagate the DOTS client identity ..."
Removes a lot of confusion in my mind.

[Med] The "server-side" is important because we don't want client-side GWs to reveal the identity of internal dots clients.

[Med] Deal.

[Jon2] Then do we need to instruct the implementers of the signal channel that this is what should be done?
[Med] What about adding this text:

NEW:
      DOTS servers MAY support a
      configuration parameter (e.g., ACLs) to identify DOTS gateways
      that are trusted to supply client-identifier attributes.

OLD:

Cheers,
Med

Re-,

Please see inline.

Cheers,
Med

Hi Med / Kaname,

[Med] Actually,

Regards

Jon

Hi Jon,

Cheers,
Med

Hi Med and all,

[Med] Agree.

Regards

Jon

Hi all,

C=====G1====G2====S

C=====G1====G2====S

Thoughts?

Cheers,
Med

---

From: "Jon Shallow" <[email-masked]>
Date: Mon, 18 Dec 2017 15:45:00 -0000

Hi Med,

See inline [Jon3]

Regards

Jon

Sent: 18 December 2017 15:14

Re-,

Please see inline.

Cheers,

Med

Hi Med,

See inline [Jon2].

Regards

Jon

Re-,

Please see inline.

Cheers,

Med

Hi Med,

      DOTS server's domain.

[Med] Do you have a particular case in mind in which we should allow for the
“client-facing side” of a gateway to belong to the client domain and its
“server-facing side” to belong to the server domain? 

[Jon3]The recursive gateway comes immediately to mind – when an ISP cannot
handle the current attack and wants to invoke someone else to handle it.
Otherwise to me, a gateway to me is either an aggregation point of clients
within a common domain or a border between two different domains.

-    “xxx-side DOTS gateway” means this is owned and operated by xxx.

-    “DOTS gateway client-side” refers to the client-facing interface of a
DTOS gateway. It applies for both client- and server-side getaways.  

[Jon3] I agree with your distinct definitions, but not the use of the
definition in the requirements I-D to cover the definition of “DOTS Gateway
client-side”

Regards

Jon

Jon, 

1st change: 

OLD:

     authorized to manage.

NEW:

      enforcement purposes.

[Med] The “server-side” is important because we don’t want client-side GWs
to reveal the identity of internal dots clients. 

[Jon3] Why do we need to be restrictive to “Server-side DOTS gateways” here?

[Jon3] “Client-side DOTS gateways” may, or may not, want to pass on
“client-identifiers” (which are obfuscated to hide identity).  If they do
not pass on “client-identifiers” then the DOTS server they connect to (which
is in the same domain by definition) will not be able to differentiate
between the different clients – the whole purpose of “client-identifiers” –
or am I missing something here?

[Jon3] To me, the only time that “client-identifiers” may need to be dropped
(not that I recommend doing this) is when a DOTS Gateway is sitting in both
a client’s domain and a different server’s domain as a domain border
gateway.

[Med] Deal.  

      by DOTS clients.

NEW: 

 

[Med] Ok, thanks.

OLD:

   identifier' list.

[Jon1] OK 

Cheers,

Med

Re-,

Please see inline.

Cheers,

Med

Hi Med / Kaname,

[Med] Actually, 

Regards

Jon

Hi Jon, 

Cheers,

Med

Hi Med and all,

|

                                                           |

 

   identifier' list.”

 

[Med] Agree. 

[Med] OK. 

Regards

Jon

Hi all, 

C=====G1====G2====S

C=====G1====G2====S

Thoughts?

Cheers,

Med

---

From: <[email-masked]>
Date: Mon, 18 Dec 2017 16:03:24 +0000

Re-,

Please see inline.

Cheers,
Med

De : Jon Shallow [mailto:[email-masked]]
Envoyé : lundi 18 décembre 2017 16:45
À : BOUCADAIR Mohamed IMT/OLN; [email-masked]; kaname nishizuka
Objet : RE: [Dots] client-identifier: Recurisve signaling & Aggregation

Hi Med,

See inline [Jon3]

Regards

Jon

Re-,

Please see inline.

Cheers,
Med

Hi Med,

See inline [Jon2].

Regards

Jon

Re-,

Please see inline.

Cheers,
Med

Hi Med,

[Jon2] Yes - actually, this adds to the confusion in my mind.  For a singular DOTS gateway, it could have a client-facing-side that is in the DOTS client domain, and a server-facing side that is in a different DOTS server domain.  The quoted text implies it is one or the other, but not both.
[Med] Do you have a particular case in mind in which we should allow for the "client-facing side" of a gateway to belong to the client domain and its "server-facing side" to belong to the server domain?
[Jon3]The recursive gateway comes immediately to mind - when an ISP cannot handle the current attack and wants to invoke someone else to handle it.  Otherwise to me, a gateway to me is either an aggregation point of clients within a common domain or a border between two different domains.
[Med] Given that recursive signalling is opaque to the origin DOTS client, all involved gateways are IMHO at the server-side (from the perspective of the source client). The only difference is that the intermediate dots gateway (server) is managed by Provider 1 while the final server is managed by another provider.

-    "DOTS gateway client-side" refers to the client-facing interface of a DTOS gateway. It applies for both client- and server-side getaways.
[Jon3] I agree with your distinct definitions, but not the use of the definition in the requirements I-D to cover the definition of "DOTS Gateway client-side"

Regards

Jon

Jon,

1st change:

OLD:

NEW:

[Med] The "server-side" is important because we don't want client-side GWs to reveal the identity of internal dots clients.
[Jon3] Why do we need to be restrictive to "Server-side DOTS gateways" here?
[Med] For privacy concerns: e.g., avoid revealing how/where DOTS clients are deployed in the client's domain.

We do have this text (that may be tweaked):

   In order to prevent leaking internal information outside a client-
   domain, DOTS gateways located in the client-domain SHOULD NOT reveal
   the identification information that pertains to internal DOTS clients
   (client-identifier) unless explicitly configured to do so.

[Jon3] "Client-side DOTS gateways" may, or may not, want to pass on "client-identifiers" (which are obfuscated to hide identity).  If they do not pass on "client-identifiers" then the DOTS server they connect to (which is in the same domain by definition) will not be able to differentiate between the different clients - the whole purpose of "client-identifiers" - or am I missing something here?
[Med] For client-side DOTS gateways, the server does not need to rely upon the identity of internal DOTS clients; the identity of the gw is sufficient. Imagine an enterprise network with multiple DOTS clients and a DOTS gateway located on the CPE that intercepts all messages from these clients. The ultimate DOTS server does not to know about those DOTS clients.

[Jon3] To me, the only time that "client-identifiers" may need to be dropped (not that I recommend doing this) is when a DOTS Gateway is sitting in both a client's domain and a different server's domain as a domain border gateway.

[Med] Deal.

NEW:

OLD:

Cheers,
Med

Re-,

Please see inline.

Cheers,
Med

Hi Med / Kaname,

[Med] Actually,

Regards

Jon

Hi Jon,

Cheers,
Med

Hi Med and all,

[Med] Agree.

Regards

Jon

Hi all,

C=====G1====G2====S

C=====G1====G2====S

Thoughts?

Cheers,
Med

---

From: "Jon Shallow" <[email-masked]>
Date: Mon, 18 Dec 2017 16:29:11 -0000

Hi Med,

See inline [Jon4].  I have deleted some of the “see inline messages”.

Regards

Jon

Hi Med,

      DOTS server's domain.

[Med] Given that recursive signalling is opaque to the origin DOTS client,
all involved gateways are IMHO at the server-side (from the perspective of
the source client). The only difference is that the intermediate dots
gateway (server) is managed by Provider 1 while the final server is managed
by another provider.

[Jon4] Hmm – I am not convinced.  Some of your examples below actually give
examples for a DOTS gateway sitting in both client and (different) server
domains.

Regards

Jon

Jon, 

1st change: 

OLD:

     authorized to manage.

NEW:

      enforcement purposes.

[Med] For privacy concerns: e.g., avoid revealing how/where DOTS clients are
deployed in the client’s domain.

[Jon4] But all this (deployment etc.) information is in the client domain
only using your definition of a client-side DOTS gateway – so within the
client space who the really cares?

[Jon4] But this information going into another domain is the security
concern.  However, to get a mitigation request to go between domains, there
has to be a border at some point.  How do we handle that?  What does the
border look like (it cannot be a client-side or server-side DOTS gateway as
that is not allowed to straddle domains as you assert)? 

[Jon4] I had always read this as being a DOTS gateway on the border of a
different client and server domain

[Med] For client-side DOTS gateways, the server does not need to rely upon
the identity of internal DOTS clients; the identity of the gw is sufficient.
Imagine an enterprise network with multiple DOTS clients and a DOTS gateway
located on the CPE that intercepts all messages from these clients. The
ultimate DOTS server does not to know about those DOTS clients.

[Jon4] Again an example of a DOTS gateway that sits both in a client and
(different) server domain.

[Med] Deal.  

      by DOTS clients.

NEW: 

[Jon4] I do not think ACL is the right term here.  In the same way the a
DOTS server needs to know the valid client IDs of the DOTS clients that can
use it (along with the valid target IP addresses etc.) “valid gateway” could
be added in.  I would just drop “(e.g. ACLS)”.

[Med] Ok, thanks.

OLD:

   identifier' list.

[Jon1] OK 

Cheers,

Med

Re-,

Please see inline.

Cheers,

Med

Hi Med / Kaname,

[Med] Actually, 

Regards

Jon

Hi Jon, 

Cheers,

Med

Hi Med and all,

|

                                                           |

 

   identifier' list.”

 

[Med] Agree. 

[Med] OK. 

Regards

Jon

Hi all, 

C=====G1====G2====S

C=====G1====G2====S

Thoughts?

Cheers,

Med

---

From: <[email-masked]>
Date: Tue, 19 Dec 2017 07:15:16 +0000

Hi Jon,

Please see inline.

Cheers,
Med

De : Jon Shallow [mailto:[email-masked]]
Envoyé : lundi 18 décembre 2017 17:29
À : BOUCADAIR Mohamed IMT/OLN; [email-masked]; kaname nishizuka
Objet : RE: [Dots] client-identifier: Recurisve signaling & Aggregation

Hi Med,

See inline [Jon4].  I have deleted some of the "see inline messages".

Regards

Jon

Hi Med,

[Jon2] Yes - actually, this adds to the confusion in my mind.  For a singular DOTS gateway, it could have a client-facing-side that is in the DOTS client domain, and a server-facing side that is in a different DOTS server domain.  The quoted text implies it is one or the other, but not both.
[Med] Do you have a particular case in mind in which we should allow for the "client-facing side" of a gateway to belong to the client domain and its "server-facing side" to belong to the server domain?
[Jon3]The recursive gateway comes immediately to mind - when an ISP cannot handle the current attack and wants to invoke someone else to handle it.  Otherwise to me, a gateway to me is either an aggregation point of clients within a common domain or a border between two different domains.
[Med] Given that recursive signalling is opaque to the origin DOTS client, all involved gateways are IMHO at the server-side (from the perspective of the source client). The only difference is that the intermediate dots gateway (server) is managed by Provider 1 while the final server is managed by another provider.
[Jon4] Hmm - I am not convinced.  Some of your examples below actually give examples for a DOTS gateway sitting in both client and (different) server domains.
[Med] I suspect the disconnect is caused by mixing connectivity and DOTS control aspects.

Regards

Jon

Jon,

1st change:

OLD:

NEW:

[Med] The "server-side" is important because we don't want client-side GWs to reveal the identity of internal dots clients.
[Jon3] Why do we need to be restrictive to "Server-side DOTS gateways" here?
[Med] For privacy concerns: e.g., avoid revealing how/where DOTS clients are deployed in the client's domain.
[Jon4] But all this (deployment etc.) information is in the client domain only using your definition of a client-side DOTS gateway - so within the client space who the really cares?
[Jon4] But this information going into another domain is the security concern.  However, to get a mitigation request to go between domains, there has to be a border at some point.  How do we handle that?  What does the border look like (it cannot be a client-side or server-side DOTS gateway as that is not allowed to straddle domains as you assert)?
[Med] It looks like what is described in the architecture draft: a gateway located in the server-side.

                        example.net domain
                        . . . . . . . . . . . . . . . . .
                        .    Gn                         .
          +----+    1   .  +----+       +-----------+   .
          | Cc |<--------->| Sn |~~~~~~~| Mitigator |   .
          +----+        .  +====+       |     Mn    |   .
                        .  | Cn |       +-----------+   .
        example.com     .  +----+                       .
           client       .    ^                          .
                        . . .|. . . . . . . . . . . . . .
                             |
                           1 |
                             |
                        . . .|. . . . . . . . . . . . . .
                        .    v                          .
                        .  +----+       +-----------+   .
                        .  | So |~~~~~~~| Mitigator |   .
                        .  +----+       |     Mo    |   .
                        .               +-----------+   .
                        .                               .
                        . . . . . . . . . . . . . . . . .
                        example.org domain

                      Figure 13: Recursive Signaling

   In order to prevent leaking internal information outside a client-
   domain, DOTS gateways located in the client-domain SHOULD NOT reveal
   the identification information that pertains to internal DOTS clients
   (client-identifier) unless explicitly configured to do so.
[Jon4] I had always read this as being a DOTS gateway on the border of a different client and server domain
[Med] The mention which is important in that text is: "DOTS gateways located in the client-domain".

[Jon3] "Client-side DOTS gateways" may, or may not, want to pass on "client-identifiers" (which are obfuscated to hide identity).  If they do not pass on "client-identifiers" then the DOTS server they connect to (which is in the same domain by definition) will not be able to differentiate between the different clients - the whole purpose of "client-identifiers" - or am I missing something here?
[Med] For client-side DOTS gateways, the server does not need to rely upon the identity of internal DOTS clients; the identity of the gw is sufficient. Imagine an enterprise network with multiple DOTS clients and a DOTS gateway located on the CPE that intercepts all messages from these clients. The ultimate DOTS server does not to know about those DOTS clients.
[Jon4] Again an example of a DOTS gateway that sits both in a client and (different) server domain.
[Med] The CPE is in the border from a connectivity standpoint, but for DOTS, the gateway is under the control of the client. I don't see the "server domain" part in this example.

[Med] Deal.

NEW:
      DOTS servers MAY support a
      configuration parameter (e.g., ACLs) to identify DOTS gateways
      that are trusted to supply client-identifier attributes.
[Jon4] I do not think ACL is the right term here.  In the same way the a DOTS server needs to know the valid client IDs of the DOTS clients that can use it (along with the valid target IP addresses etc.) "valid gateway" could be added in.  I would just drop "(e.g. ACLS)".
[Med] Dropped.

OLD:

Cheers,
Med

Re-,

Please see inline.

Cheers,
Med

Hi Med / Kaname,

[Med] Actually,

Regards

Jon

Hi Jon,

Cheers,
Med

Hi Med and all,

[Med] Agree.

Regards

Jon

Hi all,

C=====G1====G2====S

C=====G1====G2====S

Thoughts?

Cheers,
Med

---

From: "Jon Shallow" <[email-masked]>
Date: Tue, 19 Dec 2017 09:56:39 -0000

Hi Med,

“[Med] I suspect the disconnect is caused by mixing connectivity and DOTS
control aspects”

Ahh – the light bulb has gone off – why our discussions had a disconnect.
It is down to the interpretation of the word “side” as used in “Client Side
DOTS gateway”.  To you it meant “control or ownership”, to me “connectivity
or position relative to DOTS gateway”.

To prevent others getting confused, my suggestion would be to update the
following in the various draft specs

“Client-Side DOTS Gateway” to “Client Domain Managed DOTS gateway”

“Server-Side DOTS Gateway” to “Server Domain Managed DOTS gateway”

“DOTS gateway server-side” to “DOTS gateway server-facing-side”

“DOTS gateway client-side” to “DOTS gateway client-facing-side”

The latter 2 should be defined somewhere.

To me, a gateway is a border of some sort – where there is a potential
discontinuity of flow (e.g. aggregation, client/server etc.)

Otherwise, see inline [Jon5].

Regards

Jon

Sent: 19 December 2017 07:15

Hi Jon, 

Please see inline. 

Cheers,

Med

Hi Med,

Regards

Jon

Hi Med,

      DOTS server's domain.

[Med] I suspect the disconnect is caused by mixing connectivity and DOTS
control aspects.

[Jon5] Thanks – this is the cause of our disconnect in interpretation of
“side” – well spotted

Regards

Jon

Jon, 

1st change: 

OLD:

     authorized to manage.

NEW:

      enforcement purposes.

[Med] It looks like what is described in the architecture draft: a gateway
located in the server-side.

                        example.net domain

                        .    Gn                         .

          +----+        .  +====+       |     Mn    |   .

                        .  | Cn |       +-----------+   .

        example.com     .  +----+                       .

           client       .    ^                          .

                             |

                           1 |

                             |

                        .    v                          .

                        .  +----+       +-----------+   .

                        .  +----+       |     Mo    |   .

                        .               +-----------+   .

                        .                               .

                        example.org domain

[Jon5] Note: It is possible that Cc actually is a gateway – which would be
client managed and is the border point

[Med] The mention which is important in that text is: “DOTS gateways located
in the client-domain”.

[Jon5] Agreed.  However, if there are multiple gateways in the chain, all
client managed, it is only the one on the border with a server domain that
needs to be extra careful.

[Med] The CPE is in the border from a connectivity standpoint, but for DOTS,
the gateway is under the control of the client. I don’t see the “server
domain” part in this example.

[Jon5] Again a disconnect in our interpretation, now understood.  To me the
gateway (albeit it client managed) is the border between the client and
server domains.

[Med] Deal.  

      by DOTS clients.

NEW: 

[Med] Dropped. 

[Med] Ok, thanks.

OLD:

   identifier' list.

[Jon1] OK 

Cheers,

Med

Re-,

Please see inline.

Cheers,

Med

Hi Med / Kaname,

[Med] Actually, 

Regards

Jon

Hi Jon, 

Cheers,

Med

Hi Med and all,

|

                                                           |

 

   identifier' list.”

 

[Med] Agree. 

[Med] OK. 

Regards

Jon

Hi all, 

C=====G1====G2====S

C=====G1====G2====S

Thoughts?

Cheers,

Med

---

From: <[email-masked]>
Date: Tue, 19 Dec 2017 10:21:50 +0000

Re-,

Please see inline.

Cheers,
Med

De : Jon Shallow [mailto:[email-masked]]
Envoyé : mardi 19 décembre 2017 10:57
À : BOUCADAIR Mohamed IMT/OLN; [email-masked]; kaname nishizuka
Objet : RE: [Dots] client-identifier: Recurisve signaling & Aggregation

Hi Med,

"[Med] I suspect the disconnect is caused by mixing connectivity and DOTS control aspects"

Ahh - the light bulb has gone off - why our discussions had a disconnect.  It is down to the interpretation of the word "side" as used in "Client Side DOTS gateway".  To you it meant "control or ownership", to me "connectivity or position relative to DOTS gateway".
[Med] Yes, indeed.

To prevent others getting confused, my suggestion would be to update the following in the various draft specs

"Client-Side DOTS Gateway" to "Client Domain Managed DOTS gateway"
"Server-Side DOTS Gateway" to "Server Domain Managed DOTS gateway"
"DOTS gateway server-side" to "DOTS gateway server-facing-side"
"DOTS gateway client-side" to "DOTS gateway client-facing-side"

[Med] I extracted this comment and sent it as a comment to the ongoing WGLC on the requirements I-D. The signal channel/data channel drafts will be updated to reflect whatever change will be endorsed in the requirements I-D.

To me, a gateway is a border of some sort - where there is a potential discontinuity of flow (e.g. aggregation, client/server etc.)

Regards

Jon

Hi Jon,

Please see inline.

Cheers,
Med

Hi Med,

Regards

Jon

Hi Med,

[Jon5] Thanks - this is the cause of our disconnect in interpretation of "side" - well spotted

Regards

Jon

Jon,

1st change:

OLD:

NEW:

                        example.net domain

                      Figure 13: Recursive Signaling
[Jon5] Note: It is possible that Cc actually is a gateway - which would be client managed and is the border point
[Med] Yes, Cc may a be "client-side DOTS gateway" or "Client Domain Managed DOTS gateway" if you will :)

[Jon5] Agreed.  However, if there are multiple gateways in the chain, all client managed, it is only the one on the border with a server domain that needs to be extra careful.

[Jon3] "Client-side DOTS gateways" may, or may not, want to pass on "client-identifiers" (which are obfuscated to hide identity).  If they do not pass on "client-identifiers" then the DOTS server they connect to (which is in the same domain by definition) will not be able to differentiate between the different clients - the whole purpose of "client-identifiers" - or am I missing something here?
[Med] For client-side DOTS gateways, the server does not need to rely upon the identity of internal DOTS clients; the identity of the gw is sufficient. Imagine an enterprise network with multiple DOTS clients and a DOTS gateway located on the CPE that intercepts all messages from these clients. The ultimate DOTS server does not to know about those DOTS clients.
[Jon4] Again an example of a DOTS gateway that sits both in a client and (different) server domain.
[Med] The CPE is in the border from a connectivity standpoint, but for DOTS, the gateway is under the control of the client. I don't see the "server domain" part in this example.
[Jon5] Again a disconnect in our interpretation, now understood.  To me the gateway (albeit it client managed) is the border between the client and server domains.
[Med] Let's fix the wording to avoid confusion.

[Med] Deal.

NEW:

OLD:

Cheers,
Med

Re-,

Please see inline.

Cheers,
Med

Hi Med / Kaname,

[Med] Actually,

Regards

Jon

Hi Jon,

Cheers,
Med

Hi Med and all,

[Med] Agree.

Regards

Jon

Hi all,

C=====G1====G2====S

C=====G1====G2====S

Thoughts?

Cheers,
Med

---

From: "Konda, Tirumaleswar Reddy" <[email-masked]>
Date: Tue, 19 Dec 2017 11:12:33 +0000

I don't think the functionality of DOTS gateway needs to be complicated by aggregating mitigation requests and forking responses. The drafts need to clarify that DOTS gateway only performs aggregation at session-level but not at the request-level.

-Tiru

From: Dots [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Tuesday, December 19, 2017 3:52 PM
To: Jon Shallow <[email-masked]>; [email-masked]; kaname nishizuka <[email-masked]>
Subject: Re: [Dots] client-identifier: Recurisve signaling & Aggregation

Re-,

Please see inline.

Cheers,
Med

Hi Med,

Regards

Jon

Hi Jon,

Please see inline.

Cheers,
Med

Hi Med,

Regards

Jon

Hi Med,

Regards

Jon

Jon,

1st change:

OLD:

NEW:

                        example.net domain

[Med] Deal.

NEW:

OLD:

Cheers,
Med

Re-,

Please see inline.

Cheers,
Med

Hi Med / Kaname,

[Med] Actually,

Regards

Jon

Hi Jon,

Cheers,
Med

Hi Med and all,

[Med] Agree.

Regards

Jon

Hi all,

C=====G1====G2====S

C=====G1====G2====S

Thoughts?

Cheers,
Med