Subject: [Dots] DOTS Gateways Challenges

From: "Jon Shallow" <[email-masked]>
Date: Wed, 4 Oct 2017 22:21:06 +0100

I am having trouble with the DOTS Gateway implementation when primarily
thinking about alias-names and filters.

    +----+
    | c1 |\
    +----+ \              +---+
            \-----UDP-----| D |------UDP------+---+
    +----+                | O |               |   |
    | c2 |--------UDP-----| T |------UDP------| S |
    +----+                | S |               |   |
            /-----UDP-----| G |------UDP------+---+
    +----+ /              +---+
    | c3 |/
    +----+

Non aggregated

Question 1

=========

Does DOTSGW user a common PKI certificate for all 3 connections to S?

If so, what happens when C1 POST an acl filter called filter-1.  How does S
know that it came from (is associated with) C1 as opposed to C2 or C3?

Question 2

=========

What happens when C2 POST an acl filter called filter-1 - but it has a
different definition to C1's version.  How should DOTSGW (who knows it is
associated with C2) and S handle this?

Question 3

==========

C1 POSTs a filter filter-1.  C2 POSTs a filter filter-2.  C1 signals a
mitigation request.  How does S know whether to invoke filter-1 or filter-2
or both for this mitigation request?

        +----+

        | c1 |\

        +----+ \              +---+

                \-----UDP-----| D |               +---+

        +----+                | O |               |   |

        | c2 |--------UDP-----| T |------UDP------| S |

        +----+                | S |               |   |

                /-----UDP-----| G |               +---+

        +----+ /              +---+

        | c3 |/

        +----+

Aggregated.

DOSTGW has to use a singular PKI Certificate for the DOSTGW to S session, so
there cannot (easily) be 3 different certificates.

The same 3 questions as the non-aggregated still stand.  S somehow needs to
know which Client is issuing the information.

There potentially needs to be some sort of NAT translation equivalent taking
place as information is sent from the Clients to the Server and untranslated
on the way back.

So for example, an alias definition alias-1 from C1 perhaps needs to be
prefixed with c1- by DOTSGW (i.e. c1-alias-1) before passing it on to S and
then a signal mitigation request from C1 referring to alias-1 needs to be
changed to c1-alias-1 - and when a GET mitigation status is done the S
response with c1-alias-1 needs to be changed back to alias-1 by DOTSGW
before sending it on to C1.

If there are a large number of DOTSGW in the chain, the NAT'd name can get
large - especially if the pre-pended text is the certificate common name /
altSubjectName.  This is not really scalable.

Another suggestion is that as well as the PKI mutual authentication taking
place, there is support for an additional client identifier in the protocol
that the DOTSGW can use to add into the DOTSGW to S session.  For the signal
channel, it could be at the mitigation-id or session-id level - e.g.
"client-id" : "string".  It could also be "client-id" : "string" at the
alias-name level in the data channel for
"ietf-dots-data-channel-identifier:identifier".  For the data channel
access-control-list, draft-ietf-netmod-acl-model-14 (just released) has just
introduced a new container "interfaces" sitting at the same level as list
"acl" under container "access-lists".  Interfaces have a list of (sortable)
ACLs (taken from 'list acl') associated with them (which separately is a way
of working around the ACL sorting issue raised at the virtual meeting) .
The interface-name could be the "client-id" string and so S has a list of
interfaces, one per actual client.  

The use of a client-id would help in the directing of any traffic from S to
the appropriate Cn.

There is a possibility of client-id name clashes though with more than one
DOTSGW in the C -> S chain.

Suggestion / Ideas / Solutions welcome.

Regards

Jon

---

From: "Roland Dobbins" <[email-masked]>
Date: Thu, 05 Oct 2017 04:37:04 +0700

> The use of a client-id would help in the directing of any traffic from S to

This is already present, is it not?

-----------------------------------
Roland Dobbins <[email-masked]>

---

From: "Jon Shallow" <[email-masked]>
Date: Thu, 5 Oct 2017 08:58:13 +0100

Hi Roland,

Perhaps "original-client-id" would be a better name - in a similar sort of
way that the "X-Forwarding-For:" header provides the original IP making the
HTTP request when passing through a load-balancer or SSL terminator.

        +----+

        | c1 |\

        +----+ \              +---+

        +----+                | O |               |   |

        +----+                | S |               |   |

        +----+ /              +---+

        | c3 |/

        +----+

The DOTSGW'Server (G'S) does know the client-id of C1, but in the connection
DOTSGW'Client (G'C) <-> S this is not (currently) passed on.

When traffic from S when received at G'C (e.g. unsolicited Observe status
change), this has to be looked up in DOTSGW to work out which Cn G'S is
going to send it on to.  Having the (original)-client-id in the G'C <-> S
communication helps the lookup on G.

For example,  the lookup (for unsolicited Observe status change)is based on
the COAP TAG in the message - but if both C1 and C2 have used the same TAG
id in their GET with Observe set request then either the TAG has to be 'NAT'
when forwarded on somehow to make sure the response goes back to the correct
client, or the additional key is (original)-client-id.

Regards

Jon

-----Original Message-----
From: Dots [mailto: [email-masked]] On Behalf Of Roland Dobbins
Sent: 04 October 2017 22:37
To: [email-masked]
Subject: Re: [Dots] DOTS Gateways Challenges

On 5 Oct 2017, at 4:21, Jon Shallow wrote:

> The use of a client-id would help in the directing of any traffic from 

> S to the appropriate Cn.

Roland Dobbins < <mailto:[email-masked]> [email-masked]>

_______________________________________________

Dots mailing list

 <mailto:[email-masked]> [email-masked]

 <https://www.ietf.org/mailman/listinfo/dots>
https://www.ietf.org/mailman/listinfo/dots

---

From: "Dobbins, Roland" <[email-masked]>
Date: Thu, 5 Oct 2017 09:42:10 +0000

On Oct 5, 2017, at 14:58, Jon Shallow <[email-masked]<mailto:[email-masked]>> wrote:

Perhaps "original-client-id" would be a better name - in a similar sort of way that the "X-Forwarding-For:" header provides the original IP making the HTTP request when passing through a load-balancer or SSL terminator.

This is how it *must* work, agreed; I remember discussing this topic at one of the WG meetings, specifically.

If it somehow was dropped, we need to fix it.  Gateways are a necessary initial capability, as is preserving DOTS client IDs across them.

-----------------------------------
Roland Dobbins <[email-masked]<mailto:[email-masked]>>

---

From: "Jon Shallow" <[email-masked]>
Date: Thu, 5 Oct 2017 12:35:25 +0100

As the use of “original-client-id” is a *must*, then I propose the following changes.  It is defined as an array should there be a client-id name clash and a second (or more) entry needs to be added by a DOTS Gateway in a long chain.  In normal use, it is expected that there will only be one entry, even though several DOTS Gateways have been passed through.

The following YANG changes need to be made to the signal spec and associated references updated

   This document defines the YANG module "ietf-dots-signal", which has

   the following tree structure:

   module: ietf-dots-signal

       +--rw mitigation-scope

          +--rw scope* [mitigation-id]

             +--rw mitigation-id         int32

             +--rw original-client-id*   string

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

             +--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 fqdn*                 inet:domain-name

             +--rw uri*                  inet:uri

             +--rw alias-name*           string

             +--rw lifetime?             int32

----

     container mitigation-scope {

          description

             "Top level container for a mitigation request.";

          list scope {

             key mitigation-id;

             description "Identifier for the mitigation request.";

             leaf mitigation-id {

                type int32;

                description "Mitigation request identifier.";

             }

             list original-client-id {

                type string;

                description "Original Client ID requesting the mitigation, REQUIRED and added when passing through a DOTS Gateway.";

             }

             leaf-list target-ip {

                type inet:ip-address;

                description

                   "IPv4 or IPv6 address identifying the target.";

             }

----

       signal-config

          +--rw session-id?           int32

          +--rw original-client-id*   string  

          +--rw heartbeat-interval?   int16

          +--rw missing-hb-allowed?   int16

          +--rw max-retransmit?       int16

          +--rw ack-timeout?          int16

          +--rw ack-random-factor?    decimal64

          +--rw trigger-mitigation?   Boolean

---

     container signal-config {

          description "Top level container for DOTS signal channel session

                       configuration.";

          leaf session-id {

              type int32;

              description "An identifier for the DOTS signal channel

                           session configuration data.";

          }  

          list original-client-id {

              type string;

              description "Original Client ID requesting the mitigation, REQUIRED and added when passing through a DOTS Gateway.";

          }

          leaf heartbeat-interval {

---

The following YANG changes need to be made to the data spec and associated references updated

   module: ietf-dots-data-channel-identifier

       +--rw identifier

          +--rw alias* [alias-name]

             +--rw alias-name           string

             +--rw original-client-id*  string

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

             +--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 fqdn*                inet:domain-name

             +--rw uri*

---

     container identifier {

          description "top level container for identifiers";

              list alias {

                   key alias-name;

                   description "list of identifiers";

                   leaf alias-name {

                      type string;

                      description "alias name";

                   }

                   list original-client-id {

                       type string;

                       description "Original Client ID requesting the mitigation, REQUIRED and added when passing through a DOTS Gateway.";

                   }

                   leaf-list target-ip {

---

The ietf-access-control-list:access-lists is more complicated.  With the introduction of ‘container interfaces’ in draft-ietf-netmod-acl-model-14 the text in general in draft-ietf-dots-data-channel needs updating.  This change in draft-ietf-netmod-acl-model-14 gives us the ability to attach a specific set of sorted ACLs to an interface, but still does not easily associate a set of ACL definitions with a particular client.

My suggestion is that we add in an additional JSON entry as follows, with the YANG module module ietf-dots-access-control-list updated (my YANG is not currently up to doing that) that defines what we are doing.

  POST /restconf/data/ietf-access-control-list HTTP/1.1

  Host: www.example.com

  Content-Format: "application/yang.api+json"

  {

   "original-client-id" : ["string" ], 

   "ietf-access-control-list:access-lists": {

      "acl": [

[And should not we be posting to /restconf/data/ietf-dots-access-control-list anyway?]

Regards

Jon

From: Dots [mailto: [email-masked]] On Behalf Of Dobbins, Roland
Sent: 05 October 2017 10:42
To: [email-masked]
Subject: Re: [Dots] DOTS Gateways Challenges

On Oct 5, 2017, at 14:58, Jon Shallow <[email-masked]> wrote:

---

From: <[email-masked]>
Date: Fri, 6 Oct 2017 07:20:25 +0000

Hi Jon,

Please see inline.

Cheers,
Med

De : Dots [mailto:[email-masked]] De la part de Jon Shallow
Envoyé : jeudi 5 octobre 2017 09:58
À : 'Roland Dobbins'; [email-masked]
Objet : Re: [Dots] DOTS Gateways Challenges

Hi Roland,

[Med] I would say: it depends whether the gateway is located in the client domain (e.g., https://tools.ietf.org/html/draft-boucadair-dots-multihoming-01#section-4.2) or at the operator domain. If the DOTS gateway is at the client side, then the question to reveal the original client-id may be questioned.

        +----+

        | c1 |\

        +----+ \              +---+

        +----+                | O |               |   |

        +----+                | S |               |   |

        +----+ /              +---+

        | c3 |/

        +----+

The DOTSGW'Server (G'S) does know the client-id of C1, but in the connection DOTSGW'Client (G'C) <-> S this is not (currently) passed on.

When traffic from S when received at G'C (e.g. unsolicited Observe status change), this has to be looked up in DOTSGW to work out which Cn G'S is going to send it on to.  Having the (original)-client-id in the G'C <-> S communication helps the lookup on G.

For example,  the lookup (for unsolicited Observe status change)is based on the COAP TAG in the message - but if both C1 and C2 have used the same TAG id in their GET with Observe set request then either the TAG has to be 'NAT' when forwarded on somehow to make sure the response goes back to the correct client, or the additional key is (original)-client-id.

Regards

Jon

-----Original Message-----
From: Dots [mailto: [email-masked]<mailto:[email-masked]>] On Behalf Of Roland Dobbins
Sent: 04 October 2017 22:37
To: [email-masked]<mailto:[email-masked]>
Subject: Re: [Dots] DOTS Gateways Challenges

Dots mailing list

[email-masked]<mailto:[email-masked]>

---

From: <[email-masked]>
Date: Fri, 6 Oct 2017 07:36:58 +0000

Re-,

I disagree with the following :

                type string;

A gateway may be instructed the reveal the original client identity only in some deployments (not all); otherwise it is the gateway identify that is used by the remote server. The gateway identity is extracted from the authentication credentials.

A configurable parameter to enable/disable that the original client identity is passed, may be considered (disabled by default, IMO). The original client identity is therefore optional, not mandatory.

BTW, it may be worth to consider a dedicated YANG module for DOTS gateways.

Cheers,
Med

De : Dots [mailto:[email-masked]] De la part de Jon Shallow
Envoyé : jeudi 5 octobre 2017 13:35
À : 'Dobbins, Roland'; [email-masked]
Objet : Re: [Dots] DOTS Gateways Challenges

   module: ietf-dots-signal
       +--rw mitigation-scope

----

          list scope {
             key mitigation-id;

          leaf session-id {
              type int32;

---

  Host: www.example.com<http://www.example.com>

Regards

Jon
From: Dots [mailto: [email-masked]<mailto:[email-masked]>] On Behalf Of Dobbins, Roland
Sent: 05 October 2017 10:42
To: [email-masked]<mailto:[email-masked]>
Subject: Re: [Dots] DOTS Gateways Challenges

---

From: "Konda, Tirumaleswar Reddy" <[email-masked]>
Date: Fri, 6 Oct 2017 13:57:34 +0000

I don’t see a need for client-side DOTS gateway to convey the “DOTS client identity” to the DOTS server. “DOTS client identity” looks required only for the server-side DOTS gateways. In case of server-side DOTS gateway, it can convey the client-id generated from the “DOTS client identity” to the DOTS server. The DOTS gateway can generate a unique client-id and does not have to send an array of client-ids to the DOTS server to resolve clashes.

-Tiru

From: Dots [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Friday, October 6, 2017 1:07 PM
To: Jon Shallow <[email-masked]>; 'Dobbins, Roland' <[email-masked]>; [email-masked]
Subject: Re: [Dots] DOTS Gateways Challenges

Re-,

                type string;

Cheers,
Med

De : Dots [mailto:[email-masked]] De la part de Jon Shallow
Envoyé : jeudi 5 octobre 2017 13:35
À : 'Dobbins, Roland'; [email-masked]<mailto:[email-masked]>
Objet : Re: [Dots] DOTS Gateways Challenges

   module: ietf-dots-signal
       +--rw mitigation-scope

----

          list scope {
             key mitigation-id;

          leaf session-id {
              type int32;

---

Regards

Jon

---

From: "Jon Shallow" <[email-masked]>
Date: Fri, 6 Oct 2017 15:11:40 +0100

Hi Tiru,

Unless I am missing something, how does the Client side of DOTS GW convey to the upstream server a unique “client-id” which is different to the implied client id as derived from the PKI certificate that the DOTS GW’Client uses/presents when communicating to the server?

To me, there needs to be an option such as “original-client-id” or “client-id” (which is confusing when also referring to the client identity as derived from the (DOTS GW) Client’s PKI certificate) as a part of the protocol.

I agree that the DOTS GW can generate its own unique client-id to stop multiple entries being needed.

I agree that is not a good thing to “leak” out internal information when passing through a DOTS GW, so my REQUIRED does not make sense.

Regards

Jon

PS – I am having to deal with other stuff at present – I will get back later on the other issues under discussion

From: Konda, Tirumaleswar Reddy [mailto: [email-masked]] 
Sent: 06 October 2017 14:58
To: [email-masked]; Jon Shallow; 'Dobbins, Roland'; [email-masked]
Subject: RE: [Dots] DOTS Gateways Challenges

-Tiru

---

From: <[email-masked]>
Date: Fri, 6 Oct 2017 14:44:36 +0000

Re-,

Please see inline.

Cheers,
Med

De : Konda, Tirumaleswar Reddy [mailto:[email-masked]]
Envoyé : vendredi 6 octobre 2017 15:58
À : BOUCADAIR Mohamed IMT/OLN; Jon Shallow; 'Dobbins, Roland'; [email-masked]
Objet : RE: [Dots] DOTS Gateways Challenges

I don’t see a need for client-side DOTS gateway to convey the “DOTS client identity” to the DOTS server.
[Med] Agree.

“DOTS client identity” looks required only for the server-side DOTS gateways.
[Med] Yes.

In case of server-side DOTS gateway, it can convey the client-id generated from the “DOTS client identity” to the DOTS server. The DOTS gateway can generate a unique client-id and does not have to send an array of client-ids to the DOTS server to resolve clashes.
[Med] Whatever the mechanism used to generate that id, we will need a channel to convey it to the server. Obviously, it cannot be extracted from the identity of the gateway itself because it aggregates many clients (that belongs to distinct subscribers). There is a room for an optional parameter for this.

-Tiru

From: Dots [mailto:[email-masked]] On Behalf Of [email-masked]<mailto:[email-masked]>
Sent: Friday, October 6, 2017 1:07 PM
To: Jon Shallow <[email-masked]<mailto:[email-masked]>>; 'Dobbins, Roland' <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: Re: [Dots] DOTS Gateways Challenges

Re-,

                type string;

Cheers,
Med

   module: ietf-dots-signal
       +--rw mitigation-scope

----

          list scope {
             key mitigation-id;

          leaf session-id {
              type int32;

---

Regards

Jon

---

From: "Jon Shallow" <[email-masked]>
Date: Fri, 6 Oct 2017 21:14:41 +0100

Hi All,

Comment inline.

Regards

Jon

From: Dots [mailto: [email-masked]] On Behalf Of [email-masked]
Sent: 06 October 2017 15:45
To: Konda, Tirumaleswar Reddy; Jon Shallow; 'Dobbins, Roland'; [email-masked]
Subject: Re: [Dots] DOTS Gateways Challenges

Re-,

Please see inline. 

Cheers,

Med

[Med] Agree.

[Jon] But we do need to transfer something in this session – the unique client-id – see below

[Med] Yes. 

[Jon] Agreed that support for this additional parameter is required and it needs to be conveyed at the CBOR / RESTCONF layer – which I initially suggested (badly) as “original-client-id”.

-Tiru

Re-,

                type string;

             }

Cheers,

Med

   module: ietf-dots-signal

       +--rw mitigation-scope

             +--rw uri*                  inet:uri

             +--rw alias-name*           string

             +--rw lifetime?             int32

----

          description

          list scope {

             key mitigation-id;

             leaf mitigation-id {

                type int32;

             }

                type string;

             }

             leaf-list target-ip {

                type inet:ip-address;

                description

             }

----

       signal-config

          +--rw session-id?           int32

          +--rw ack-timeout?          int16

---

                       configuration.";

          leaf session-id {

              type int32;

          }  

              type string;

          }

---

       +--rw identifier

             +--rw alias-name           string

             +--rw uri*

---

     container identifier {

              list alias {

                   key alias-name;

                   leaf alias-name {

                      type string;

                   }

                       type string;

                   }

                   leaf-list target-ip {

---

  Host: www.example.com

  {

      "acl": [

Regards

Jon

---

From: "Konda, Tirumaleswar Reddy" <[email-masked]>
Date: Sat, 7 Oct 2017 03:28:04 +0000

In case of client-side DOTS gateway, why does the DOTS server need to know which “DOTS client” has conveyed the mitigation request ?
For example, the DOTS client could be a DDoS detector or an Application server, and the client-side gateway will have to resolve the conflicting mitigation requests from the DOTS clients, aggregate the mitigation requests from the DOTS client and send the updated mitigation request to the DOTS server.

-Tiru

From: Jon Shallow [mailto:[email-masked]]
Sent: Friday, October 6, 2017 7:42 PM
To: Konda, Tirumaleswar Reddy <[email-masked]>; [email-masked]; [email-masked]; Roland Dobbins <[email-masked]>
Subject: RE: [Dots] DOTS Gateways Challenges

Hi Tiru,

Regards

Jon

From: Konda, Tirumaleswar Reddy [mailto: [email-masked]<mailto:[email-masked]>]
Sent: 06 October 2017 14:58
To: [email-masked]<mailto:[email-masked]>; Jon Shallow; 'Dobbins, Roland'; [email-masked]<mailto:[email-masked]>
Subject: RE: [Dots] DOTS Gateways Challenges

-Tiru

---

From: "Konda, Tirumaleswar Reddy" <[email-masked]>
Date: Sat, 7 Oct 2017 03:33:00 +0000

[TR] Yes, will update draft.

[TR] Please provide more details on the updates required to the DOTS data channel draft.

Cheers,
-Tiru

---

From: "Jon Shallow" <[email-masked]>
Date: Sat, 7 Oct 2017 09:37:06 +0100

Hi Tiru,

This discussion goes beyond just the mitigation request.  We need to consider what happens with both alias-name and acl-name (data channel)

The simple case of a mitigation request with no alias-name does not require any knowledge of the original client.  

However, if the mitigation request uses alias-name, then there are 3 ways of handling this

a)      The DOTS GW replaces the alias-name with its actual definition (target-ips etc. merged as appropriate), so alias-name is not forwarded on to Server – just the expanded mitigation request is forwarded

b)      The DOTS GW updates the alias-name with a unique alias-name that is forwarded (and has to do the same thing when the alias-name is configured on the data channel) – to handle 2 or more clients defining the same alias-name which have different characteristics

c)      The DOTS GW recognises that alias-name is not unique and adds in ”additional-client-info” (I think I prefer this “-info” name to client-id or original-client-id as “-id” is too closely  associated with Client Identity derived from the DOTS GW Client certificate)

We have agreed that when a client requests mitigation status, the “alias-name” should be returned as “alias-name” and not the substituted alias-name configuration (this does need to be stated in the spec for clarity).  This makes (a) difficult to be handled by DOTS GW which then raises the question – do we really need alias-name?

The definition and association of ACLs/Filters of the data channel is more difficult – the Server must install / apply the appropriate ACLs on a per (Original) Client basis when mitigation is invoked.

Client 1’s concept of a Whitelist IP could be Client 2’s concept of a Blacklist IP.  The Server needs to know which client is requesting the mitigation and install the correct ACLs – if there was no ”additional-client-info”, the Server only knows that he has to install ALL of the ACLs (i.e. both the Black and White list of the same IP as defined by Client 1 and Client 2) as defined by his client (DOTS GW) when his client requests a mitigation.  Here, I think that if there is more than one client for the DOTS GW, ”additional-client-info” is required.

Regards

Jon

From: Dots [mailto: [email-masked]] On Behalf Of Konda, Tirumaleswar Reddy
Sent: 07 October 2017 04:28
To: Jon Shallow; [email-masked]; [email-masked]; Roland Dobbins
Subject: Re: [Dots] DOTS Gateways Challenges

-Tiru

Hi Tiru,

Regards

Jon

-Tiru

---

From: "Dobbins, Roland" <[email-masked]>
Date: Sat, 7 Oct 2017 11:09:06 +0000

On Oct 7, 2017, at 10:28, Konda, Tirumaleswar Reddy <[email-masked]<mailto:[email-masked]>> wrote:

Because there may be mitigation specifics, policy, and/or contractual obligations which are client-specific.

---

From: "Konda, Tirumaleswar Reddy" <[email-masked]>
Date: Mon, 9 Oct 2017 13:16:23 +0000

Yes, we can add an optional additional parameter to the yang models (mandatory only for the server-side DOTS gateways to convey to the DOTS server).

-Tiru

From: Dots [mailto:[email-masked]] On Behalf Of Jon Shallow
Sent: Saturday, October 7, 2017 1:45 AM
To: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re: [Dots] DOTS Gateways Challenges

Hi All,

Comment inline.

Regards

Jon

From: Dots [mailto: [email-masked]<mailto:[email-masked]>] On Behalf Of [email-masked]<mailto:[email-masked]>
Sent: 06 October 2017 15:45
To: Konda, Tirumaleswar Reddy; Jon Shallow; 'Dobbins, Roland'; [email-masked]<mailto:[email-masked]>
Subject: Re: [Dots] DOTS Gateways Challenges

Re-,

Please see inline.

Cheers,
Med

De : Konda, Tirumaleswar Reddy [mailto:[email-masked]]
Envoyé : vendredi 6 octobre 2017 15:58
À : BOUCADAIR Mohamed IMT/OLN; Jon Shallow; 'Dobbins, Roland'; [email-masked]<mailto:[email-masked]>
Objet : RE: [Dots] DOTS Gateways Challenges

-Tiru

Re-,

                type string;

Cheers,
Med

   module: ietf-dots-signal
       +--rw mitigation-scope

----

          list scope {
             key mitigation-id;

          leaf session-id {
              type int32;

---

Regards

Jon

---

From: "Konda, Tirumaleswar Reddy" <[email-masked]>
Date: Mon, 9 Oct 2017 13:26:46 +0000

From: Dobbins, Roland [mailto:[email-masked]]
Sent: Saturday, October 7, 2017 4:39 PM
To: Konda, Tirumaleswar Reddy <[email-masked]>
Cc: Jon Shallow <[email-masked]>; [email-masked]; [email-masked]
Subject: Re: [Dots] DOTS Gateways Challenges

Agreed, but the above statement is only true for server-side DOTS gateway but not for client-side DOTS gateway. The DOTS clients and client-side DOTS gateway belong to the same domain, the DOTS client will only be authorized to communicate with the client-side DOTS gateway but not with the DOTS server. DOTS clients cannot by-pass the DOTS gateway and signal conflicting rules to the DOTS server.

-Tiru

---

From: "Konda, Tirumaleswar Reddy" <[email-masked]>
Date: Mon, 9 Oct 2017 13:34:30 +0000

Hi Jon,

I agree the below problems are applicable for server-side DOTS gateway, it must convey the “client identity” to the DOTS server. But for the client-side DOTS gateway, it should resolve conflicting rules b/w DOTS clients (e.g. one client installing black-list ACL for an IP address but the other client installs white-list ACL for the same IP address, same alias-names for different mitigation scopes). I don’t see the need for a client-side DOTS gateway to convey the “client identity” to the server-side DOTS gateway or DOTS server.

-Tiru

From: Jon Shallow [mailto:[email-masked]]
Sent: Saturday, October 7, 2017 2:07 PM
To: Konda, Tirumaleswar Reddy <[email-masked]>; [email-masked]; [email-masked]; Roland Dobbins <[email-masked]>
Subject: RE: [Dots] DOTS Gateways Challenges

Hi Tiru,

Regards

Jon

From: Dots [mailto: [email-masked]<mailto:[email-masked]>] On Behalf Of Konda, Tirumaleswar Reddy
Sent: 07 October 2017 04:28
To: Jon Shallow; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; Roland Dobbins
Subject: Re: [Dots] DOTS Gateways Challenges

-Tiru

From: Jon Shallow [mailto:[email-masked]]
Sent: Friday, October 6, 2017 7:42 PM
To: Konda, Tirumaleswar Reddy <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; Roland Dobbins <[email-masked]<mailto:[email-masked]>>
Subject: RE: [Dots] DOTS Gateways Challenges

Hi Tiru,

Regards

Jon

-Tiru

---

From: <[email-masked]>
Date: Mon, 9 Oct 2017 14:12:58 +0000

Exactly.

I guess we need to include a clarification about client-side DOTSG vs. server-side DOTSG in the draft (or preferably in the requirements/architecture I-Ds).

Cheers,
Med

De : Konda, Tirumaleswar Reddy [mailto:[email-masked]]
Envoyé : lundi 9 octobre 2017 15:27
À : Dobbins, Roland
Cc : Jon Shallow; BOUCADAIR Mohamed IMT/OLN; [email-masked]
Objet : RE: [Dots] DOTS Gateways Challenges

From: Dobbins, Roland [mailto:[email-masked]]
Sent: Saturday, October 7, 2017 4:39 PM
To: Konda, Tirumaleswar Reddy <[email-masked]<mailto:[email-masked]>>
Cc: Jon Shallow <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re: [Dots] DOTS Gateways Challenges

-Tiru

---

From: "Jon Shallow" <[email-masked]>
Date: Mon, 9 Oct 2017 15:39:29 +0100

Hi Tiru,

I think part of the challenge here in our thinking is that a mitigation request does not (cannot) ask for a specific ACL/Filter (or set of ACLS) to be installed – in a similar vein to the mitigation request being able to call up a specific alias-name to be used.

[You refer to “but the other client installs white-list ACL for the same IP address, same alias-names for different mitigation scopes)” below – however alias-names do not currently dictate which ACL to use as per module: ietf-dots-data-channel-identifier.]

The current design appears to me is that the ACL/filter list is defined on the DOTS Server (by a DOTS client or directly on the DOTS Server) and you then get all the defined ACLs instantiated by DOTS Mitigator – for a single mitigation request.  Even if the Filters are held on a per client basis, there no way to upload a set of different filters in peace time ready for selection as to which is be used in case of DDoS Attack.  White/Black lists are probably fairly static, it is the customizable filters that are the issue currently for me. 

If there was an additional parameter in the mitigation request – e.g. “filter-name: []” to define which ACLs are to be used, this would simplify a lot of things and give a greater degree of flexibility should it be needed.

Once  “filter-name: []” is in place, then conflicting requests are much easier to resolve – especially if the 2 clients defining the filter have different client identifiers [I am making a naive assumption that Client-1 and Client 2 are responsible for a different set of IP addresses that the DOTS Server or GW client facing side know about – so white list filter for these set of IP and black-list filter for those set of IPs].

If the 2 clients have the same “client identifier”, both request mitigation with the same filter name, then a conflict needs to be resolved.  However, the last client to define/update the filter will win I guess.

If the GW Server facing side passes on “filter-name” and something like “extra-info: {string}” (related to Client-1 and Client-2), then the upstream DOTS server with the GW as its client will also be able to simply sort out what to do.

Regards

Jon

From: Dots [mailto: [email-masked]] On Behalf Of Konda, Tirumaleswar Reddy
Sent: 09 October 2017 14:35
To: Jon Shallow; [email-masked]; [email-masked]; Roland Dobbins
Subject: Re: [Dots] DOTS Gateways Challenges

Hi Jon,

-Tiru

Hi Tiru,

Regards

Jon

-Tiru

Hi Tiru,

Regards

Jon

-Tiru

---

From: "Konda, Tirumaleswar Reddy" <[email-masked]>
Date: Mon, 9 Oct 2017 15:19:09 +0000

Hi Jon,

Please see inline

From: Jon Shallow [mailto:[email-masked]]
Sent: Monday, October 9, 2017 8:09 PM
To: Konda, Tirumaleswar Reddy <[email-masked]>; [email-masked]; [email-masked]; Roland Dobbins <[email-masked]>
Subject: RE: [Dots] DOTS Gateways Challenges

Hi Tiru,

The current design appears to me is that the ACL/filter list is defined on the DOTS Server (by a DOTS client or directly on the DOTS Server) and you then get all the defined ACLs instantiated by DOTS Mitigator – for a single mitigation request.

[TR] No, black-list and white-list rules created using the DOTS data channel have no dependency on conveying the mitigation request in the DOTS signal channel (You may want to look into the DOTS requirements and architecture drafts).

Even if the Filters are held on a per client basis, there no way to upload a set of different filters in peace time ready for selection as to which is be used in case of DDoS Attack.  White/Black lists are probably fairly static, it is the customizable filters that are the issue currently for me.

[TR] This is a new requirement and needs to be discussed.

-Tiru

Regards

Jon

Hi Jon,

-Tiru

Hi Tiru,

Regards

Jon

-Tiru

Hi Tiru,

Regards

Jon

-Tiru

---

From: kaname nishizuka <[email-masked]>
Date: Tue, 10 Oct 2017 12:18:30 +0900

Hi,

 > I agree the below problems are applicable for server-side DOTS gateway, it must convey the “client identity” to the DOTS server.
I agree with this server-side DOTS gateway case.
At the same time, I agree with below:
 > I agree that is not a good thing to “leak” out internal information when passing through a DOTS GW,

Then, should DOTS GW send “client identity” (i.e. certificates of DOTS clients) itself or hashed(“client identity”) to DOTS server?
If later, how can DOTS server react to the ambiguous information of the hashed(“client identity”).

regards,
Kaname

On 2017/10/09 22:34, Konda, Tirumaleswar Reddy wrote:
> *From:*Jon Shallow [mailto:[email-masked]]
> *Sent:* Saturday, October 7, 2017 2:07 PM
> *To:* Konda, Tirumaleswar Reddy <[email-masked]>; [email-masked]; [email-masked]; Roland Dobbins <[email-masked]>
> *Subject:* RE: [Dots] DOTS Gateways Challenges
>
> Hi Tiru,
>
> a)The DOTS GW replaces the alias-name with its actual definition (target-ips etc. merged as appropriate), so alias-name is not forwarded on to Server – just the expanded mitigation request is forwarded
>
> b)The DOTS GW updates the alias-name with a unique alias-name that is forwarded (and has to do the same thing when the alias-name is configured on the data channel) – to handle 2 or more clients defining the same alias-name which have different characteristics
>
> c)The DOTS GW recognises that alias-name is not unique and adds in ”additional-client-info” (I think I prefer this “-info” name to client-id or original-client-id as “-id” is too closely  associated with Client Identity derived from the DOTS GW Client certificate)
>
> *From:*Dots [mailto: [email-masked] <mailto:[email-masked]>] *On Behalf Of *Konda, Tirumaleswar Reddy
> *Sent:* 07 October 2017 04:28
> *To:* Jon Shallow; [email-masked] <mailto:[email-masked]>; [email-masked] <mailto:[email-masked]>; Roland Dobbins
> *Subject:* Re: [Dots] DOTS Gateways Challenges
>
> *From:*Jon Shallow [mailto:[email-masked]]
> *Sent:* Friday, October 6, 2017 7:42 PM
> *To:* Konda, Tirumaleswar Reddy <[email-masked] <mailto:[email-masked]>>; [email-masked] <mailto:[email-masked]>; [email-masked] <mailto:[email-masked]>; Roland Dobbins <[email-masked] <mailto:[email-masked]>>
> *Subject:* RE: [Dots] DOTS Gateways Challenges
>
> Hi Tiru,
>
> *From:*Konda, Tirumaleswar Reddy [mailto: [email-masked] <mailto:[email-masked]>]
> *Sent:* 06 October 2017 14:58
> *To:* [email-masked] <mailto:[email-masked]>; Jon Shallow; 'Dobbins, Roland'; [email-masked] <mailto:[email-masked]>
> *Subject:* RE: [Dots] DOTS Gateways Challenges
>
> [email-masked]

---

From: "Jon Shallow" <[email-masked]>
Date: Tue, 10 Oct 2017 10:23:17 +0100

Hi Kaname,

I do not think that information necessarily needs to be the original client identity.  The GW Client side will have its own identity which the DOTS Server can use to differentiate between DOTS (GW) Clients.

So, yes, a hashed set of names can be used – it is up to the DOTS GW Client side to make sure that there are no hash collisions.  Or it could be a simple list such as C1, C2 …Cn.

Regards

Jon

From: Dots [mailto: [email-masked]] On Behalf Of kaname nishizuka
Sent: 10 October 2017 04:19
To: Konda, Tirumaleswar Reddy; Jon Shallow; [email-masked]; [email-masked]; Roland Dobbins
Subject: Re: [Dots] DOTS Gateways Challenges

Hi,

regards,
Kaname

Hi Jon,

-Tiru

From: Jon Shallow [mailto:[email-masked]] 
Sent: Saturday, October 7, 2017 2:07 PM
To: Konda, Tirumaleswar Reddy  <mailto:[email-masked]> <[email-masked]>; [email-masked]; [email-masked]; Roland Dobbins  <mailto:[email-masked]> <[email-masked]>
Subject: RE: [Dots] DOTS Gateways Challenges

Hi Tiru,

Regards

Jon

-Tiru

Hi Tiru,

Regards

Jon

-Tiru

---

From: "Jon Shallow" <[email-masked]>
Date: Tue, 10 Oct 2017 10:43:06 +0100

Hi Tiru,

See inline to your 2 responses.

Regards

Jon

From: Dots [mailto: [email-masked]] On Behalf Of Konda, Tirumaleswar Reddy
Sent: 09 October 2017 16:19
To: Jon Shallow; [email-masked]; [email-masked]; Roland Dobbins
Subject: Re: [Dots] DOTS Gateways Challenges

Hi Jon,

Please see inline 

Hi Tiru,

[Jon] I have re-read the requirements / architecture drafts.  I agree that currently the White/Black/Filter definitions have no dependency on the mitigation request – it is up to the DOTS server (GW or not) as to how the White/Black/Filter definitions get passed on to DOTS mitigator (out of spec), but the DOTS server needs to know which of the White/Black/Filter definitions are relevant when a mitigation request comes in.  Currently, it is possible for the DOTS Server to hold White/Black/Filter definitions on a per client identity.  When the White/Black/Filter definitions are passed from a GW Client side to a GW server side and on to the next DOTS server, GW server side has to convey also something about the clients on the GW client side for the DOTS server to maintain the White/Black/Filter definitions on a per pseudo “client identity” – so when the migration request is passed to the DOS server via a GW it knows what White/Black/Filter definitions to apply to that mitigation request.

Even if the Filters are held on a per client identity basis, there no way to upload a set of different filters in peace time ready for selection as to which is be used in case of DDoS Attack.  White/Black lists are probably fairly static, it is the customizable filters that are the issue currently for me. 

[Jon] Agreed.  We need to be able to support the flexibility of being able to have different sets ACLs, one or more of which can be triggered by a mitigation request.

-Tiru

Regards

Jon

Hi Jon,

-Tiru

Hi Tiru,

Regards

Jon

-Tiru

Hi Tiru,

Regards

Jon

-Tiru

---

From: "Konda, Tirumaleswar Reddy" <[email-masked]>
Date: Tue, 10 Oct 2017 11:52:54 +0000

Hi Kaname,

Please see inline

From: Dots [mailto:[email-masked]] On Behalf Of kaname nishizuka
Sent: Tuesday, October 10, 2017 8:49 AM
To: Konda, Tirumaleswar Reddy <[email-masked]<mailto:[email-masked]>>; Jon Shallow <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; Roland Dobbins <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Dots] DOTS Gateways Challenges

Hi,

Then, should DOTS GW send “client identity” (i.e. certificates of DOTS clients) itself or hashed(“client identity”) to DOTS server?
If later, how can DOTS server react to the ambiguous information of the hashed(“client identity”).
[TR] The DOTS client certificate may not fit within the path MTU. The alternative approach is, the server-side DOTS GW computes SHA-256 of the Subject Public Key Info (SPKI) of the client certificate and send the hashed output to the DOTS server in the new client-id parameter (see https://tools.ietf.org/html/rfc7469#section-2.4). SHA-256 is resistant to collisions. Further, server-side DOTS gateway and DOTS server are in the same domain operating the EST server, DOTS client will be using the certificate provisioned by the EST server to authenticate itself to the server-side DOTS gateway and I don’t see any ambiguous information in the hashed client identity generated and conveyed by the server-side DOTS gateway to the DOTS server.
-Tiru

regards,
Kaname

-Tiru

From: Jon Shallow [mailto:[email-masked]]
Sent: Saturday, October 7, 2017 2:07 PM
To: Konda, Tirumaleswar Reddy <[email-masked]><mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; Roland Dobbins <[email-masked]><mailto:[email-masked]>
Subject: RE: [Dots] DOTS Gateways Challenges

Hi Tiru,

Regards

Jon

-Tiru

Hi Tiru,

Regards

Jon

-Tiru

Dots mailing list

---

From: "Konda, Tirumaleswar Reddy" <[email-masked]>
Date: Tue, 10 Oct 2017 12:16:23 +0000

I thought we agreed that based on the current DOTS requirements only the server-side DOTS GW needs to convey the DOTS client (or client-side DOTS WG) identity to the DOTS server.

-Tiru

From: Jon Shallow [mailto:[email-masked]]
Sent: Tuesday, October 10, 2017 2:53 PM
To: 'kaname nishizuka' <[email-masked]>; Konda, Tirumaleswar Reddy <[email-masked]>; [email-masked]; [email-masked]; Roland Dobbins <[email-masked]>
Subject: RE: [Dots] DOTS Gateways Challenges

Hi Kaname,

Regards

Jon

From: Dots [mailto: [email-masked]<mailto:[email-masked]>] On Behalf Of kaname nishizuka
Sent: 10 October 2017 04:19
To: Konda, Tirumaleswar Reddy; Jon Shallow; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; Roland Dobbins
Subject: Re: [Dots] DOTS Gateways Challenges

Hi,

regards,
Kaname

-Tiru

Hi Tiru,

Regards

Jon

-Tiru

Hi Tiru,

Regards

Jon

-Tiru

Dots mailing list

---

From: "Jon Shallow" <[email-masked]>
Date: Tue, 10 Oct 2017 13:44:46 +0100

Hi Tiru,

Agreed that only a DOTS GW server facing needs to send information to the upstream DOTS Server – which could also be a DOTS GW.

                         +-------------+

                         |    | D |    |

         +----+          |    | O |    |         +----+

         | c1 |----------| s1 | T | c2 |---------| s2 |

         +----+          |    | S |    |         +----+

                         |    | G |    |

                         +-------------+

https://tools.ietf.org/html/draft-ietf-dots-architecture-04#section-2.2.3

However, the DOTS GW client facing (s1) is the one with knowledge of the individual clients that are currently using  the DOTS server running on the DOTS GW.  This information has to somehow be passed over to the DOTS GW server facing (c2), but separate DOTS stacks are being run for (s1) and (c2) as per architecture spec 2.2.3.  I was referring to what (s1) may need to pass on to (c2) in my email response to Kaname, not what is sent by (c1).

Regards

Jon

From: Dots [mailto: [email-masked]] On Behalf Of Konda, Tirumaleswar Reddy
Sent: 10 October 2017 13:16
To: Jon Shallow; 'kaname nishizuka'; [email-masked]; [email-masked]; Roland Dobbins
Subject: Re: [Dots] DOTS Gateways Challenges

-Tiru

Hi Kaname,

Regards

Jon

Hi,

regards,
Kaname

Hi Jon,

-Tiru

Hi Tiru,

Regards

Jon

-Tiru

Hi Tiru,

Regards

Jon

-Tiru

---

From: "Jon Shallow" <[email-masked]>
Date: Tue, 10 Oct 2017 13:57:56 +0100

Hi Tiru,

I am having trouble parsing this – it is definition of terms – server and client when referring to DOTS Client, DOTS Server and DOTS Gateway.  I think there is a typo.  [I many times have got muddled in my thinking when referring to, say, DOTS GW client side – which actually is a DOTS server in its own rights.]

To me, server-side DOTS gateway definition is the upstream DOTS server facing part of the DOTS Gateway – c2 in

                         +-------------+

                         |    | D |    |

         +----+          |    | O |    |         +----+

         +----+          |    | S |    |         +----+

                         |    | G |    |

                         +-------------+

Issue 1

========

So how does “DOTS client will be using the certificate provisioned by the EST server to authenticate itself to the server-side DOTS gateway” work?

- ((c1) to (c2) is illegal!)

Issue 2

=====

“server-side DOTS gateway and DOTS server are in the same domain operating the EST server, DOTS client will be using the certificate provisioned by the EST server”

Whilst (c2) and (s2) will be in the same domain for mutual authentication, the same is not necessarily true for (c1) and (s2).  However the use of SPKI will work if all the (c1) type clients talking to (s1) are using PKI.  If there is another trust mechanism for (c1)<->((s1), then it is going to have to be a hash on something different.

Regards

Jon

From: Dots [mailto: [email-masked]] On Behalf Of Konda, Tirumaleswar Reddy
Sent: 10 October 2017 12:53
To: kaname nishizuka; Jon Shallow; [email-masked]; [email-masked]; Roland Dobbins
Subject: Re: [Dots] DOTS Gateways Challenges

Hi Kaname,

Please see inline

From: Dots [ <mailto:[email-masked]> mailto:[email-masked]] On Behalf Of kaname nishizuka
Sent: Tuesday, October 10, 2017 8:49 AM
To: Konda, Tirumaleswar Reddy < <mailto:[email-masked]> [email-masked]>; Jon Shallow < <mailto:[email-masked]> [email-masked]>;  <mailto:[email-masked]> [email-masked];  <mailto:[email-masked]> [email-masked]; Roland Dobbins < <mailto:[email-masked]> [email-masked]>
Subject: Re: [Dots] DOTS Gateways Challenges

Hi,

-Tiru

regards,
Kaname

Hi Jon,

-Tiru

From: Jon Shallow [ <mailto:[email-masked]> mailto:[email-masked]] 
Sent: Saturday, October 7, 2017 2:07 PM
To: Konda, Tirumaleswar Reddy  <mailto:[email-masked]> <[email-masked]>;  <mailto:[email-masked]> [email-masked];  <mailto:[email-masked]> [email-masked]; Roland Dobbins  <mailto:[email-masked]> <[email-masked]>
Subject: RE: [Dots] DOTS Gateways Challenges

Hi Tiru,

Regards

Jon

From: Dots [mailto:  <mailto:[email-masked]> [email-masked]] On Behalf Of Konda, Tirumaleswar Reddy
Sent: 07 October 2017 04:28
To: Jon Shallow;  <mailto:[email-masked]> [email-masked];  <mailto:[email-masked]> [email-masked]; Roland Dobbins
Subject: Re: [Dots] DOTS Gateways Challenges

-Tiru

From: Jon Shallow [ <mailto:[email-masked]> mailto:[email-masked]] 
Sent: Friday, October 6, 2017 7:42 PM
To: Konda, Tirumaleswar Reddy < <mailto:[email-masked]> [email-masked]>;  <mailto:[email-masked]> [email-masked];  <mailto:[email-masked]> [email-masked]; Roland Dobbins < <mailto:[email-masked]> [email-masked]>
Subject: RE: [Dots] DOTS Gateways Challenges

Hi Tiru,

Regards

Jon

From: Konda, Tirumaleswar Reddy [mailto:  <mailto:[email-masked]> [email-masked]] 
Sent: 06 October 2017 14:58
To:  <mailto:[email-masked]> [email-masked]; Jon Shallow; 'Dobbins, Roland';  <mailto:[email-masked]> [email-masked]
Subject: RE: [Dots] DOTS Gateways Challenges

-Tiru

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

---

From: "Konda, Tirumaleswar Reddy" <[email-masked]>
Date: Tue, 10 Oct 2017 14:15:16 +0000

Agree with your response, consider a deployment which has the following DOTS agents.

DOTS clients (c1) <--------------------> (s1) client-side DOTS gateway (c2) <----------------> (s2) server-side DOTS gateway (c3) <--------------> (s3) DOTS server

My point is, (c2) need not convey the “c1 identity” to (s2) but (s2) needs to convey the “c2 identity” to (c3) and (c3) in-turn propagates the “c2 identity” to (s3).

-Tiru

From: Jon Shallow [mailto:[email-masked]]
Sent: Tuesday, October 10, 2017 6:15 PM
To: Konda, Tirumaleswar Reddy <[email-masked]>; kaname nishizuka <[email-masked]>; [email-masked]; [email-masked]; Roland Dobbins <[email-masked]>
Subject: RE: [Dots] DOTS Gateways Challenges

Hi Tiru,

Regards

Jon

From: Dots [mailto: [email-masked]<mailto:[email-masked]>] On Behalf Of Konda, Tirumaleswar Reddy
Sent: 10 October 2017 13:16
To: Jon Shallow; 'kaname nishizuka'; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; Roland Dobbins
Subject: Re: [Dots] DOTS Gateways Challenges

-Tiru

From: Jon Shallow [mailto:[email-masked]]
Sent: Tuesday, October 10, 2017 2:53 PM
To: 'kaname nishizuka' <[email-masked]<mailto:[email-masked]>>; Konda, Tirumaleswar Reddy <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; Roland Dobbins <[email-masked]<mailto:[email-masked]>>
Subject: RE: [Dots] DOTS Gateways Challenges

Hi Kaname,

Regards

Jon

Hi,

regards,
Kaname

-Tiru

Hi Tiru,

Regards

Jon

-Tiru

Hi Tiru,

Regards

Jon

-Tiru

Dots mailing list

---

From: "Konda, Tirumaleswar Reddy" <[email-masked]>
Date: Tue, 10 Oct 2017 14:34:26 +0000

Hi Jon,

Please see inline

From: Jon Shallow [mailto:[email-masked]]
Sent: Tuesday, October 10, 2017 6:28 PM
To: Konda, Tirumaleswar Reddy <[email-masked]>; [email-masked]; kaname nishizuka <[email-masked]>; Roland Dobbins <[email-masked]>; [email-masked]
Subject: RE: [Dots] DOTS Gateways Challenges

Hi Tiru,

                         +-------------+
                         |    | D |    |
         +----+          |    | O |    |         +----+

Issue 1
========

[TR] c1 authenticates to s1 using the certificate it received from the EST server in the same domain as s1, c2 and s2.

Issue 2
=====

Whilst (c2) and (s2) will be in the same domain for mutual authentication, the same is not necessarily true for (c1) and (s2).

However the use of SPKI will work if all the (c1) type clients talking to (s1) are using PKI.

[TR] The assumption is DOTS agents in different domains must use PKI for mutual authentication.

If there is another trust mechanism for (c1)<->((s1), then it is going to have to be a hash on something different.

[TR] Yes, we can propose SPKI as one mechanisms (since s1, c2 and s3 are in the same domain, they all will be aware of the alternate trust mechanism).

-Tiru

Regards

Jon

From: Dots [mailto: [email-masked]<mailto:[email-masked]>] On Behalf Of Konda, Tirumaleswar Reddy
Sent: 10 October 2017 12:53
To: kaname nishizuka; Jon Shallow; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; Roland Dobbins
Subject: Re: [Dots] DOTS Gateways Challenges

Hi Kaname,

Please see inline

Hi,

regards,
Kaname

-Tiru

Hi Tiru,

Regards

Jon

-Tiru

Hi Tiru,

Regards

Jon

-Tiru

Dots mailing list

---

From: "Jon Shallow" <[email-masked]>
Date: Tue, 10 Oct 2017 15:41:09 +0100

Hi Tiru,

I agree in part, but we need to look at the end (c1) to end (s3) potential issues.  What you are proposing works fine for (s2) to (s3).

(c1) requests mitigation with an alias-name “alias-1”.  If (s1) does not pass anything extra to (c2) for onward transmission, (s2) sees a single client (c2) requesting mitigation with alias-name “alias-1”.  Fine, that works.

If there was another DOTS client in the same location as (c1)(i.e. c1diff), both using (s1) who also decided to use alias-name “alias-1” who then requests mitigation, (s2) has no idea that there are different “alias-1” definitions if (c2) does not send also an extra differentiator. 

So, any DOTS GW in the chain should be passing on a “unique-extra” piece of information.

Regards

Jon 

From: Dots [mailto: [email-masked]] On Behalf Of Konda, Tirumaleswar Reddy
Sent: 10 October 2017 15:15
To: Jon Shallow; kaname nishizuka; [email-masked]; [email-masked]; Roland Dobbins
Subject: Re: [Dots] DOTS Gateways Challenges

DOTS clients (c1) ß----------------à (s1) client-side DOTS gateway (c2) ß------------à (s2) server-side DOTS gateway (c3) ß----------à (s3) DOTS server

-Tiru

Hi Tiru,

                         +-------------+

                         |    | D |    |

         +----+          |    | O |    |         +----+

         +----+          |    | S |    |         +----+

                         |    | G |    |

                         +-------------+

Regards

Jon

-Tiru

Hi Kaname,

Regards

Jon

Hi,

regards,
Kaname

Hi Jon,

-Tiru

Hi Tiru,

Regards

Jon

-Tiru

Hi Tiru,

Regards

Jon

-Tiru

---

From: "Konda, Tirumaleswar Reddy" <[email-masked]>
Date: Tue, 10 Oct 2017 14:52:13 +0000

The conflicting alias-names from DOTS client (c1) and another client (let’ call (c11)) behind (s1) should be resolved by s1 itself, it is also the responsibility of (s1) to resolve conflicting mitigation requests from (c1) and (c11), aggregate the mitigation requests from the DOTS clients (c1 and c11) and send the updated mitigation request (c2).

-Tiru

From: Jon Shallow [mailto:[email-masked]]
Sent: Tuesday, October 10, 2017 8:11 PM
To: Konda, Tirumaleswar Reddy <[email-masked]>; kaname nishizuka <[email-masked]>; [email-masked]; [email-masked]; Roland Dobbins <[email-masked]>
Subject: RE: [Dots] DOTS Gateways Challenges

Hi Tiru,

Regards

Jon

From: Dots [mailto: [email-masked]<mailto:[email-masked]>] On Behalf Of Konda, Tirumaleswar Reddy
Sent: 10 October 2017 15:15
To: Jon Shallow; kaname nishizuka; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; Roland Dobbins
Subject: Re: [Dots] DOTS Gateways Challenges

-Tiru

From: Jon Shallow [mailto:[email-masked]]
Sent: Tuesday, October 10, 2017 6:15 PM
To: Konda, Tirumaleswar Reddy <[email-masked]<mailto:[email-masked]>>; kaname nishizuka <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; Roland Dobbins <[email-masked]<mailto:[email-masked]>>
Subject: RE: [Dots] DOTS Gateways Challenges

Hi Tiru,

Regards

Jon

-Tiru

Hi Kaname,

Regards

Jon

Hi,

regards,
Kaname

-Tiru

Hi Tiru,

Regards

Jon

-Tiru

Hi Tiru,

Regards

Jon

-Tiru

Dots mailing list

---

From: "Jon Shallow" <[email-masked]>
Date: Tue, 10 Oct 2017 15:56:57 +0100

Hi Tiru,

See inline.

Regards

Jon

From: Dots [mailto:[email-masked]] On Behalf Of Konda, Tirumaleswar Reddy
Sent: 10 October 2017 15:34
To: Jon Shallow; [email-masked]; kaname nishizuka; Roland Dobbins; [email-masked]
Subject: Re: [Dots] DOTS Gateways Challenges

Hi Jon,

Please see inline

Hi Tiru,

                         +-------------+

                         |    | D |    |

         +----+          |    | O |    |         +----+

         +----+          |    | S |    |         +----+

                         |    | G |    |

                         +-------------+

Issue 1

========

[Jon], So your text should really have read “DOTS client will be using the certificate provisioned by the EST server to authenticate itself to the client-side DOTS gateway”.

Issue 2

=====

 

[Jon] To me a DOTS GW is the break point between 2 different domains.  

“SEC-001” in requirements spec states

   SEC-001  Peer Mutual Authentication: DOTS agents MUST authenticate

      each other before a DOTS signal or data channel is considered

      valid.  The method of authentication is not specified, but should

      follow current industry best practices with respect to any

      cryptographic mechanisms to authenticate the remote peer.

“3.1.2 Establishing the DOTS Session” in the architecture spec states

For example, a DOTS client may be directly configured

   to use a specific DOTS server IP address and port, and directly

   provided with any data necessary to satisfy the Peer Mutual

   Authentication requirement in [I-D.ietf-dots-requirements], such as

   symmetric or asymmetric keys, usernames and passwords, etc.  All

   configuration and authentication information in this scenario is

   provided out-of-band by the domain operating the DOTS server.

[Jon] This does not say it has to be PKI.  

[Jon] Not so easy if the DOTS domains use different mutual authentication.

-Tiru

Regards

Jon

Hi Kaname,

Please see inline

Hi,

-Tiru

regards,
Kaname

Hi Jon,

-Tiru

Hi Tiru,

Regards

Jon

-Tiru

Hi Tiru,

Regards

Jon

-Tiru

---

From: "Konda, Tirumaleswar Reddy" <[email-masked]>
Date: Tue, 10 Oct 2017 15:08:13 +0000

Inline [TR2]

From: Jon Shallow [mailto:[email-masked]]
Sent: Tuesday, October 10, 2017 8:27 PM
To: Konda, Tirumaleswar Reddy <[email-masked]>; kaname nishizuka <[email-masked]>; [email-masked]; [email-masked]; Roland Dobbins <[email-masked]>
Subject: RE: [Dots] DOTS Gateways Challenges

Hi Tiru,

See inline.

Regards

Jon

From: Dots [mailto:[email-masked]] On Behalf Of Konda, Tirumaleswar Reddy
Sent: 10 October 2017 15:34
To: Jon Shallow; [email-masked]<mailto:[email-masked]>; kaname nishizuka; Roland Dobbins; [email-masked]<mailto:[email-masked]>
Subject: Re: [Dots] DOTS Gateways Challenges

Hi Jon,

Please see inline

From: Jon Shallow [mailto:[email-masked]]
Sent: Tuesday, October 10, 2017 6:28 PM
To: Konda, Tirumaleswar Reddy <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; kaname nishizuka <[email-masked]<mailto:[email-masked]>>; Roland Dobbins <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: RE: [Dots] DOTS Gateways Challenges

Hi Tiru,

                         +-------------+
                         |    | D |    |
         +----+          |    | O |    |         +----+

Issue 1
========

[TR2] Agreed.

Issue 2
=====

[TR2] Yes, we need to discuss in the WG to mandate PKI across domains. I am planning to put a draft to discuss the possible mutual authentication mechanisms for the WG to decide mandatory and optional mechanisms to implement for interoperability.

[TR2] I don’t see a problem, if let’s say shared secret is used for mutual authentication b/w DOTS agents then SHA-256 can be computed for the shared secret, similarly if raw public keys are used then SHA-256 can be calculated for the raw public key.

-Tiru

Regards

Jon

Hi Kaname,

Please see inline

Hi,

regards,
Kaname

-Tiru

Hi Tiru,

Regards

Jon

-Tiru

Hi Tiru,

Regards

Jon

-Tiru

Dots mailing list

---

From: "Jon Shallow" <[email-masked]>
Date: Tue, 10 Oct 2017 16:16:56 +0100

Hi Tiru,

Then that breaks a signal GET for mitigation status from (c1) (mitigation request uses alias-name) – what gets sent back in the alias-name field when the response that is sent by (s3) when it gets to (c1)?

I thought we had agreed to leave the alias name – as is – (not substituted) in what is sent back to (c1) from (s1).

(c1) is not particularly interested in how (c11) is getting mitigated and probably does not want (c11) stats added into his – (s3) need to know how to differentiate between (c1) and (c11) – which is easily done if (c1) (or (c11) information is passed up to (s3), starting with (s1).

This whole thing needs to be scalable, and I am struggling with how to actually implement your proposal.  Allowing each DOTS GW to learn and pass on something extra that differentiates the DOTS GW immediate clients makes the implementation relatively easy.  There is no need for a DOTS GW to add in additional information if extra information is already embedded – unless he sees a name clash from 2 or more of his uniquely identified DOTS clients – which will be different entities anyway.

Regards

Jon

From: Dots [mailto: [email-masked]] On Behalf Of Konda, Tirumaleswar Reddy
Sent: 10 October 2017 15:52
To: Jon Shallow; kaname nishizuka; [email-masked]; [email-masked]; Roland Dobbins
Subject: Re: [Dots] DOTS Gateways Challenges

-Tiru

Hi Tiru,

Regards

Jon 

-Tiru

Hi Tiru,

                         +-------------+

                         |    | D |    |

         +----+          |    | O |    |         +----+

         +----+          |    | S |    |         +----+

                         |    | G |    |

                         +-------------+

Regards

Jon

-Tiru

Hi Kaname,

Regards

Jon

Hi,

regards,
Kaname

Hi Jon,

-Tiru

Hi Tiru,

Regards

Jon

-Tiru

Hi Tiru,

Regards

Jon

-Tiru

---

From: "Konda, Tirumaleswar Reddy" <[email-masked]>
Date: Tue, 10 Oct 2017 15:58:35 +0000

Hi Jon,

The role of s1 is much more than just forwarding the DOTS client messages, please see (SIG-009 in the requirements drafts), if a DOTS client has used the same alias name previously conveyed by another client then s1 must reject the request. If conflicting requests are resolved by s1 then any response message sent by s3 will be forwarded by s1 to the right DOTS client.

-Tiru

From: Jon Shallow [mailto:[email-masked]]
Sent: Tuesday, October 10, 2017 8:47 PM
To: Konda, Tirumaleswar Reddy <[email-masked]>; kaname nishizuka <[email-masked]>; [email-masked]; [email-masked]; Roland Dobbins <[email-masked]>
Subject: RE: [Dots] DOTS Gateways Challenges

Hi Tiru,

Regards

Jon

-Tiru

Hi Tiru,

Regards

Jon

-Tiru

Hi Tiru,

Regards

Jon

-Tiru

Hi Kaname,

Regards

Jon

Hi,

regards,
Kaname

-Tiru

Hi Tiru,

Regards

Jon

-Tiru

Hi Tiru,

Regards

Jon

-Tiru

Dots mailing list

---

From: "Jon Shallow" <[email-masked]>
Date: Tue, 10 Oct 2017 20:13:54 +0100

Hi Tiru,

I agree that any conflicting request need to be sorted out by the respective DOTS server component – SIG-009 - especially if there are conflicts over IP addresses in the mitigation requests. If (c1) and (c11) whether using alias-name or not do a mitigation request and this create a mitigation conflict, then (s1) needs to sort it out.

However aliases are set up by the data channel and potentially used by the signal channel at a later time.

So, if (c1) and (c11) have different client identities, then in my thinking (perhaps naively) that a setup of “alias-1” by (c1) followed later by (c11) also defining the identical alias-name “alias-1” then the alias-names are treated differently by (s1) as it can separately associate “alias-1” with the correct (c1) or (c11).  As (c1n) could be a large number when scaling out, there is an increased chance of 2 or more of the clients at the (c1) level choosing the same alias-name.

[When the mitigation requests come in from (c1) and (c11), using their appropriate alias-name and there is a conflict when the mitigation request is expanded out – this has to be sorted out by (s1).  However, I am assuming there is not a conflict in the expanded mitigation request]

(s1) can handle this by the association of the alias-names with the appropriate (c1n) identity.

Or are you saying that (s1) has to reject all duplicate alias-names – even though they are coming from different (c1n) entities?

- this does not scale for me

- (c11) – goes Huh?!? – I have not previously defined this. What is broken here?

Assuming my understanding is correct that the (s1)  can differentiate between alias-names used by different (c1n) clients, when (c2) passes the “alias-1” name upstream without any “extra (c1n info)” information to (s2), (s2) will reject the duplicate ((c2) has passed on the data channel request from (c1) and (c11)) which (c2) then sees and then has to tell (c11) ‘Your request to define “alias-1” failed as it is already defined’.  So again, (c11) – goes Huh?!? – I have not previously defined this.

I’m missing the point as to why you are concerned about adding in this extra information between (c2) and (s2) – we have plenty of space in the UDP packet – CBOR mapping has done a good data reduction job.

Regards

Jon

From: Dots [mailto: [email-masked]] On Behalf Of Konda, Tirumaleswar Reddy
Sent: 10 October 2017 16:59
To: Jon Shallow; kaname nishizuka; [email-masked]; [email-masked]; Roland Dobbins
Subject: Re: [Dots] DOTS Gateways Challenges

Hi Jon,

-Tiru

Hi Tiru,

Regards

Jon

-Tiru

Hi Tiru,

Regards

Jon 

-Tiru

Hi Tiru,

                         +-------------+

                         |    | D |    |

         +----+          |    | O |    |         +----+

         +----+          |    | S |    |         +----+

                         |    | G |    |

                         +-------------+

Regards

Jon

-Tiru

Hi Kaname,

Regards

Jon

Hi,

regards,
Kaname

Hi Jon,

-Tiru

Hi Tiru,

Regards

Jon

-Tiru

Hi Tiru,

Regards

Jon

-Tiru

---

From: "Konda, Tirumaleswar Reddy" <[email-masked]>
Date: Wed, 11 Oct 2017 04:38:38 +0000

Hi Jon,

Please see inline

From: Jon Shallow [mailto:[email-masked]]
Sent: Wednesday, October 11, 2017 12:44 AM
To: Konda, Tirumaleswar Reddy <[email-masked]>; kaname nishizuka <[email-masked]>; [email-masked]; [email-masked]; Roland Dobbins <[email-masked]>
Subject: RE: [Dots] DOTS Gateways Challenges

Hi Tiru,

[TR] I don’t think there will be a large number of DOTS clients in a domain, typically a DDoS mitigation system or DDoS detector in a domain will act as DOTS clients (and in future content servers with DDoS detection capability can also act as DOTS clients).

Why do you think there will be large number of DOTS clients in a domain ?

Or are you saying that (s1) has to reject all duplicate alias-names – even though they are coming from different (c1n) entities?
- this does not scale for me
- (c11) – goes Huh?!? – I have not previously defined this. What is broken here ?

[TR] c11 has to re-try with a different alias name, RESTCONF (and NETCONF) deals with this problem by returning “data-exists” error response (409 response code).

[TR] Space is not a problem for adding the extra information, my concern is the need to convey the extra information and DOTS gateway not assisting to resolve the same alias-name from different DOTS clients.

-Tiru

Regards

Jon

Hi Jon,

-Tiru

Hi Tiru,

Regards

Jon

-Tiru

Hi Tiru,

Regards

Jon

-Tiru

Hi Tiru,

Regards

Jon

-Tiru

Hi Kaname,

Regards

Jon

Hi,

regards,
Kaname

-Tiru

Hi Tiru,

Regards

Jon

-Tiru

Hi Tiru,

Regards

Jon

-Tiru

Dots mailing list

---

From: kaname nishizuka <[email-masked]>
Date: Wed, 11 Oct 2017 18:46:35 +0900

Hi Jon, Tiru,

 > If there was another DOTS client in the same location as (c1)(i.e. c1diff), both using (s1) who also decided to use alias-name “alias-1” who then requests mitigation, (s2) has no idea that there a…

 From the viewpoint of s2, if there is a differentiator of request from c1 and c1diff, it will assist some situation. For example, a retrieval request of existing mitigation list from c2 will get all of the data from s2 if there is no differentiator in the request, however if there is, s2 can return only the related information of specific one.
But, I don't think such kind of differentiator is required between c1 and s1, because s1 should identify c1 based on “client identity” which will be certificate of c1 if the mutual authentication is PKI-based. Keeping the binding of “client identity”  and (original)-client-id in signal message is a little bit complicated implementation of s1.

Regarding the data-channel, there is a possibility of collision in alias-name among c1, c1diff,,,, so should we need to describe how to bind a data-channel and signal-channel for various mutual authentication patterns like PKI, SPKI, TLS-PKI etc,.. in the draft?

regards,
Kaname

On 2017/10/11 13:38, Konda, Tirumaleswar Reddy wrote:
> *Sent:* Wednesday, October 11, 2017 12:44 AM
> *To:* Konda, Tirumaleswar Reddy <[email-masked]>; kaname nishizuka <[email-masked]>; [email-masked]; [email-masked]; Roland Dobbins <[email-masked]>
> *Sent:* 10 October 2017 16:59
> *To:* Jon Shallow; kaname nishizuka; [email-masked] <mailto:[email-masked]>; [email-masked] <mailto:[email-masked]>; Roland Dobbins
> *Sent:* Tuesday, October 10, 2017 8:47 PM
> *To:* Konda, Tirumaleswar Reddy <[email-masked] <mailto:[email-masked]>>; kaname nishizuka <[email-masked] <mailto:[email-masked]>>; [email-masked] <mailto:[email-masked]>; [email-masked] <mailto:[email-masked]>; Roland Dobbins <[email-masked] <mailto:[email-masked]>>
> *Sent:* 10 October 2017 15:52
> *To:* Jon Shallow; kaname nishizuka; [email-masked] <mailto:[email-masked]>; [email-masked] <mailto:[email-masked]>; Roland Dobbins
> *Sent:* Tuesday, October 10, 2017 8:11 PM
> *To:* Konda, Tirumaleswar Reddy <[email-masked] <mailto:[email-masked]>>; kaname nishizuka <[email-masked] <mailto:[email-masked]>>; [email-masked] <mailto:[email-masked]>; [email-masked] <mailto:[email-masked]>; Roland Dobbins <[email-masked] <mailto:[email-masked]>>
> *Sent:* 10 October 2017 15:15
> *To:* Jon Shallow; kaname nishizuka; [email-masked] <mailto:[email-masked]>; [email-masked] <mailto:[email-masked]>; Roland Dobbins
> DOTS clients (c1) ß----------------à(s1) client-side DOTS gateway (c2) ß------------à(s2) server-side DOTS gateway (c3) ß----------à(s3) DOTS server
>
> *Sent:* Tuesday, October 10, 2017 6:15 PM
> *To:* Konda, Tirumaleswar Reddy <[email-masked] <mailto:[email-masked]>>; kaname nishizuka <[email-masked] <mailto:[email-masked]>>; [email-masked] <mailto:[email-masked]>; [email-masked] <mailto:[email-masked]>; Roland Dobbins <[email-masked] <mailto:[email-masked]>>
> *Sent:* 10 October 2017 13:16
> *To:* Jon Shallow; 'kaname nishizuka'; [email-masked] <mailto:[email-masked]>; [email-masked] <mailto:[email-masked]>; Roland Dobbins
> *Sent:* Tuesday, October 10, 2017 2:53 PM
> *To:* 'kaname nishizuka' <[email-masked] <mailto:[email-masked]>>; Konda, Tirumaleswar Reddy <[email-masked] <mailto:[email-masked]>>; [email-masked] <mailto:[email-masked]>; [email-masked] <mailto:[email-masked]>; Roland Dobbins <[email-masked] <mailto:[email-masked]>>
> *From:*Dots [mailto: [email-masked] <mailto:[email-masked]>] *On Behalf Of *kaname nishizuka
> *Sent:* 10 October 2017 04:19
> *To:* Konda, Tirumaleswar Reddy; Jon Shallow; [email-masked] <mailto:[email-masked]>; [email-masked] <mailto:[email-masked]>; Roland Dobbins
>     *To:* Konda, Tirumaleswar Reddy <[email-masked]> <mailto:[email-masked]>; [email-masked] <mailto:[email-masked]>; [email-masked] <mailto:[email-masked]>; Roland Dobbins <[email-masked]> <mailto:[email-masked]>
>     [email-masked] <mailto:[email-masked]>
>

---

From: "Jon Shallow" <[email-masked]>
Date: Wed, 11 Oct 2017 12:08:06 +0100

Hi Kaname / Tiru,

See inline – [Jon1] 3 in Kanama’s response and 3 in Tiru’s response.

Regards

Jon

From: Dots [mailto: [email-masked]] On Behalf Of kaname nishizuka
Sent: 11 October 2017 10:47
To: Konda, Tirumaleswar Reddy; Jon Shallow; [email-masked]; [email-masked]; Roland Dobbins
Subject: Re: [Dots] DOTS Gateways Challenges

Hi Jon, Tiru,

>From the viewpoint of s2, if there is a differentiator of request from c1 and c1diff, it will assist some situation. For example, a retrieval request of existing mitigation list from c2 will get all…

[Jon1] Agreed.

[Jon1] Agreed – but (s2) and (s3) will have to do this.

[Jon1] In my current implementation, alias-name (whether data or signal channel) is associated with a client-id (and possibly “extra-client-info” (not yet coded)).  The decision here is whether we have a single pool of alias-names (and ACLs) on a DOTS server, or each DOTS server (standalone or in a GW) maintains separate lists – one per client-id.  And this should be stated in the specs for clarity.

regards,
Kaname

Hi Jon,

Please see inline 

From: Jon Shallow [mailto:[email-masked]] 
Sent: Wednesday, October 11, 2017 12:44 AM
To: Konda, Tirumaleswar Reddy  <mailto:[email-masked]> <[email-masked]>; kaname nishizuka  <mailto:[email-masked]> <[email-masked]>; [email-masked]; [email-masked]; Roland Dobbins  <mailto:[email-masked]> <[email-masked]>
Subject: RE: [Dots] DOTS Gateways Challenges

Hi Tiru,

[Jon1]  One of my customers has over 100 of his customers that are separately protected and each of these customers would be considered a (c1) instance.  Expand this out to a broadband network of home routers and the numbers get very large.  See 3.1.8 and 3.2.2 in dots use cases spec.

[Jon1] I think we need this (optional) extra information that any DOTS GW server side can send upstream.  Allowing (c3) to do this, but not (c2) makes no sense to me.  To me, it is a requirement that DOTS GW resolves conflicts, does data reduction etc. whenever it can to reduce upstream traffic.

[Jon1] I still believe that (s3) has to maintain separation of (c1) and (c11) information (alias-names, ACLs and mitigation requests).  So, when (c11) askes for his mitigation status, he gets only data relevant to him.

-Tiru

Regards

Jon

Hi Jon,

-Tiru

Hi Tiru,

Regards

Jon

-Tiru

Hi Tiru,

Regards

Jon 

-Tiru

Hi Tiru,

                         +-------------+

                         |    | D |    |

         +----+          |    | O |    |         +----+

         +----+          |    | S |    |         +----+

                         |    | G |    |

                         +-------------+

Regards

Jon

-Tiru

Hi Kaname,

Regards

Jon

Hi,

regards,
Kaname

Hi Jon,

-Tiru

Hi Tiru,

Regards

Jon

-Tiru

Hi Tiru,

Regards

Jon

-Tiru

---

From: "Konda, Tirumaleswar Reddy" <[email-masked]>
Date: Wed, 11 Oct 2017 12:28:48 +0000

Thanks Jon for the clarification, I will update both signal and data channel drafts to address the comment.

-Tiru

From: Jon Shallow [mailto:[email-masked]]
Sent: Wednesday, October 11, 2017 4:38 PM
To: 'kaname nishizuka' <[email-masked]>; Konda, Tirumaleswar Reddy <[email-masked]>; [email-masked]; [email-masked]; Roland Dobbins <[email-masked]>
Subject: RE: [Dots] DOTS Gateways Challenges

Hi Kaname / Tiru,

Regards

Jon

Hi Jon, Tiru,

regards,
Kaname

Please see inline

From: Jon Shallow [mailto:[email-masked]]
Sent: Wednesday, October 11, 2017 12:44 AM
To: Konda, Tirumaleswar Reddy <[email-masked]><mailto:[email-masked]>; kaname nishizuka <[email-masked]><mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; Roland Dobbins <[email-masked]><mailto:[email-masked]>
Subject: RE: [Dots] DOTS Gateways Challenges

Hi Tiru,

-Tiru

Regards

Jon

Hi Jon,

-Tiru

Hi Tiru,

Regards

Jon

-Tiru

Hi Tiru,

Regards

Jon

-Tiru

Hi Tiru,

Regards

Jon

-Tiru

Hi Kaname,

Regards

Jon

Hi,

regards,
Kaname

-Tiru

Hi Tiru,

Regards

Jon

-Tiru

Hi Tiru,

Regards

Jon

-Tiru

Dots mailing list

Dots mailing list