Subject: [Dots] Call home in the signal channel (was RE: draft-ietf-dots-data-channel: Filter Direction)

From: <[email-masked]>
Date: Fri, 16 Feb 2018 10:18:57 +0000

Hi Jon,

I'm changing the title to keep track of signal-channel specific issues.

Please use this one to discuss this use case.

Thank you.

Cheers,
Med

De : Jon Shallow [mailto:[email-masked]]
Envoyé : vendredi 16 février 2018 10:57
À : 'Konda, Tirumaleswar Reddy'; BOUCADAIR Mohamed IMT/OLN; [email-masked]
Objet : RE: [Dots] draft-ietf-dots-data-channel: Filter Direction

I understand the concept of call home - which makes good sense to me and rfc8071 will, if implemented, handle the data channel and "destination" is still where the 'controlled' traffic is flowing to.

However, we also need call home in the signal channel.  I'm not sure how this will be done - do we need a new CoAP Method (e.g. switch roles) - do we need to define a different port (rfc8071 defines 4336) etc.

Regards

Jon

From: Dots [mailto: [email-masked]<mailto:[email-masked]>] On Behalf Of Konda, Tirumaleswar Reddy
Sent: 16 February 2018 09:07
To: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re: [Dots] draft-ietf-dots-data-channel: Filter Direction

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]]
Sent: Friday, February 16, 2018 2:19 PM
To: Konda, Tirumaleswar Reddy <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: RE: draft-ietf-dots-data-channel: Filter Direction

Re-,

Please see inline.

Cheers,
Med

De : Dots [mailto:[email-masked]] De la part de Konda, Tirumaleswar Reddy
Envoyé : vendredi 16 février 2018 09:28
À : BOUCADAIR Mohamed IMT/OLN; [email-masked]<mailto:[email-masked]>
Objet : Re: [Dots] draft-ietf-dots-data-channel: Filter Direction

There is no ambiguity in the roles. The CPE is acting as DOTS server but the DOTS server is initiating connection to the DOTS client in the access network.
[Med] Don't get the last part. The server (CPE) will receive a request from the network (client) to filter traffic exiting from that CPE.

[TR] I mean to use the call home feature discussed in https://tools.ietf.org/html/rfc8071, though the CPE is acting as a DOTS server it will initiate the connection (TLS or DTLS) to the DOTS client in the access network. The call home feature helps avoid various threats like the DOTS server in the CPE will not be subjected to DDoS attacks, and reachability is not problem even if the CPE is behind NAT.

The DOTS client will convey the black-list filtering in the "out" direction to block the traffic originating from the DOTS server domain.
[Med] Which corresponds to the "DOTS Server to DOTS Client" direction; that is the DOTS client domain (access network) is the destination. All is fine so far :)

[TR] The direction is "outgoing traffic" whereas for other use cases the direction is "incoming traffic".

I don't understand what you mean by a "optional" parameter ?
[Med] I meant adding a parameter to indicate explicitly the direction. It would be optional because we do already have a default direction.

[TR] Okay.

-Tiru

-Tiru

From: Dots [mailto:[email-masked]] On Behalf Of [email-masked]<mailto:[email-masked]>
Sent: Friday, February 16, 2018 1:24 PM
To: Konda, Tirumaleswar Reddy <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: Re: [Dots] draft-ietf-dots-data-channel: Filter Direction

Hi Tiru,

There will be an ambiguity in interpreting filters if and only if the same DOTS agents have to manipulate filters in both directions.

As you rightfully mentioned, the bb use case assumes the following:

   In order to achieve this capability, the telemetry analysis system
   utilized by the broadband access provider must have DOTS client
   functionality, and the end-customer CPE devices must have DOTS server
   functionality.

Which means that there is no ambiguity in that case with the current default direction: "the destination is the DOTS client domain".

No matter how roles were negotiated, but as far as each an agent acts as a client and its peer as a server, things are clear.

Of course we can always define an optional parameter for this, but it is preferable to have a case for it.

Cheers,

Med

De : Konda, Tirumaleswar Reddy [mailto:[email-masked]]
Envoyé : jeudi 15 février 2018 16:31
À : BOUCADAIR Mohamed IMT/OLN; [email-masked]<mailto:[email-masked]>
Objet : RE: draft-ietf-dots-data-channel: Filter Direction

The filtering rule for outgoing traffic is required for the "Suppression of outbound DDoS traffic originating from a consumer broadband access network" use case discussed in https://tools.ietf.org/html/draft-ietf-dots-use-cases-09#section-3.2.1. In this use case, the CPE initially acts as a DOTS client but after the TCP connection is established, reverses its role and acts as DOTS server (see https://tools.ietf.org/html/rfc8071). The access network can then program the CPE using the DOTS data channel to block the DDoS attack traffic originated from the compromised devices in the
local customer network.

Cheers,
-Tiru

From: Dots [mailto:[email-masked]] On Behalf Of [email-masked]<mailto:[email-masked]>
Sent: Wednesday, February 14, 2018 1:49 PM
To: [email-masked]<mailto:[email-masked]>
Subject: [Dots] draft-ietf-dots-data-channel: Filter Direction

Hi all,

As agreed during the interim, there are some issues that need fixes in the data-channel spec. We would like to hear from the WG to know what to record in the document.

Issue description: Do we need to support explicit "direction" in filtering rules ("in"/"out")? That is, do we allow a DOTS client to create filters for both incoming and outgoing traffic?

Below a proposal for discussion:

-    The current default direction is aligned with the nature of DDoS attacks targeted by DOTS: i.e. incoming. The DOTS client domain is assumed to be the destination. No ambiguity so far with such default behavior.

-    There is no clear use case for the support of outgoing filtering handling in the context of DOTS.

-    No text change is required to the draft.

Any objection?

Cheers,

Med

---

From: "Konda, Tirumaleswar Reddy" <[email-masked]>
Date: Fri, 16 Feb 2018 11:00:24 +0000

For the discussed use case https://tools.ietf.org/html/draft-ietf-dots-use-cases-09#section-3.2.1, the CPE needs to act as a DOTS server only for the data channel but not for the signal channel. I don't think signal-channel requires call home functionality, what is the use case ?

-Tiru

From: [email-masked] [mailto:[email-masked]]
Sent: Friday, February 16, 2018 3:49 PM
To: Jon Shallow <[email-masked]>; Konda, Tirumaleswar Reddy <[email-masked]>; [email-masked]
Subject: Call home in the signal channel (was RE: [Dots] draft-ietf-dots-data-channel: Filter Direction)

Hi Jon,

Thank you.

Cheers,
Med

De : Jon Shallow [mailto:[email-masked]]
Envoyé : vendredi 16 février 2018 10:57
À : 'Konda, Tirumaleswar Reddy'; BOUCADAIR Mohamed IMT/OLN; [email-masked]<mailto:[email-masked]>
Objet : RE: [Dots] draft-ietf-dots-data-channel: Filter Direction

Regards

Jon

Re-,

Please see inline.

Cheers,
Med

[TR] Okay.

-Tiru

-Tiru

Hi Tiru,

Cheers,

Med

Cheers,
-Tiru

Hi all,

Any objection?

Cheers,

Med

---

From: "Jon Shallow" <[email-masked]>
Date: Fri, 16 Feb 2018 12:02:31 -0000

Hi Tiru,

The more I think about it, “Call Home” support in either the data or signal
channel makes no real sense for
https://tools.ietf.org/html/draft-ietf-dots-use-cases-09#section-3.2.1 .
The CPE devices don’t need to trigger the DOTS clients to get mitigation in
place as it will be the provider who works this out.

However, for 3.2.1, the DOTS client will need to make a mitigation request
to initiate the implementing of (previously defined) ACLs using the signal
channel as there will be a high possibility of the outbound pipe running
full.

Regards

Jon

From: Dots [mailto:[email-masked]] On Behalf Of Konda,
Tirumaleswar Reddy
Sent: 16 February 2018 11:00
To: [email-masked]; Jon Shallow; [email-masked]
Subject: Re: [Dots] Call home in the signal channel (was RE:
draft-ietf-dots-data-channel: Filter Direction)

For the discussed use case
https://tools.ietf.org/html/draft-ietf-dots-use-cases-09#section-3.2.1, the
CPE needs to act as a DOTS server only for the data channel but not for the
signal channel. I don’t think signal-channel requires call home
functionality, what is the use case ?

-Tiru

From: [email-masked] [mailto:[email-masked]] 
Sent: Friday, February 16, 2018 3:49 PM
To: Jon Shallow <[email-masked]>; Konda, Tirumaleswar Reddy
<[email-masked]>; [email-masked]
Subject: Call home in the signal channel (was RE: [Dots]
draft-ietf-dots-data-channel: Filter Direction)

Hi Jon, 

I’m changing the title to keep track of signal-channel specific issues. 

Thank you. 

Cheers,

Med

I understand the concept of call home – which makes good sense to me and
rfc8071 will, if implemented, handle the data channel and “destination” is
still where the ‘controlled’ traffic is flowing to.

However, we also need call home in the signal channel.  I’m not sure how
this will be done – do we need a new CoAP Method (e.g. switch roles) – do we
need to define a different port (rfc8071 defines 4336) etc.

Regards

Jon

From: Dots [mailto: [email-masked]] On Behalf Of Konda, Tirumaleswar
Reddy
Sent: 16 February 2018 09:07
To: [email-masked]; [email-masked]
Subject: Re: [Dots] draft-ietf-dots-data-channel: Filter Direction

From: [email-masked] [mailto:[email-masked]] 
Sent: Friday, February 16, 2018 2:19 PM
To: Konda, Tirumaleswar Reddy <[email-masked]>;
[email-masked]
Subject: RE: draft-ietf-dots-data-channel: Filter Direction

Re-,

Please see inline. 

Cheers,

Med

De : Dots [mailto:[email-masked]] De la part de Konda, Tirumaleswar
Reddy
Envoyé : vendredi 16 février 2018 09:28
À : BOUCADAIR Mohamed IMT/OLN; [email-masked]
Objet : Re: [Dots] draft-ietf-dots-data-channel: Filter Direction

There is no ambiguity in the roles. The CPE is acting as DOTS server but the
DOTS server is initiating connection to the DOTS client in the access
network.

[Med] Don’t get the last part. The server (CPE) will receive a request from
the network (client) to filter traffic exiting from that CPE. 

[TR] I mean to use the call home feature discussed in
https://tools.ietf.org/html/rfc8071, though the CPE is acting as a DOTS
server it will initiate the connection (TLS or DTLS) to the DOTS client in
the access network. The call home feature helps avoid various threats like
the DOTS server in the CPE will not be subjected to DDoS attacks, and
reachability is not problem even if the CPE is behind NAT. 

The DOTS client will convey the black-list filtering in the “out” direction
to block the traffic originating from the DOTS server domain.

[Med] Which corresponds to the “DOTS Server to DOTS Client” direction; that
is the DOTS client domain (access network) is the destination. All is fine
so far :) 

[TR] The direction is “outgoing traffic” whereas for other use cases the
direction is “incoming traffic”. 

I don’t understand what you mean by a “optional” parameter ?

[Med] I meant adding a parameter to indicate explicitly the direction. It
would be optional because we do already have a default direction.

[TR] Okay.

-Tiru

-Tiru

From: Dots [mailto:[email-masked]] On Behalf Of
[email-masked]
Sent: Friday, February 16, 2018 1:24 PM
To: Konda, Tirumaleswar Reddy <[email-masked]>;
[email-masked]
Subject: Re: [Dots] draft-ietf-dots-data-channel: Filter Direction

Hi Tiru, 

There will be an ambiguity in interpreting filters if and only if the same
DOTS agents have to manipulate filters in both directions. 

   functionality.

Which means that there is no ambiguity in that case with the current default
direction: “the destination is the DOTS client domain”. 

No matter how roles were negotiated, but as far as each an agent acts as a
client and its peer as a server, things are clear. 
 
Of course we can always define an optional parameter for this, but it is
preferable to have a case for it.  
 
Cheers,
Med

De : Konda, Tirumaleswar Reddy [mailto:[email-masked]] 
Envoyé : jeudi 15 février 2018 16:31
À : BOUCADAIR Mohamed IMT/OLN; [email-masked]
Objet : RE: draft-ietf-dots-data-channel: Filter Direction

The filtering rule for outgoing traffic is required for the "Suppression of
outbound DDoS traffic originating from a consumer broadband access network"
use case discussed in
https://tools.ietf.org/html/draft-ietf-dots-use-cases-09#section-3.2.1. In
this use case, the CPE initially acts as a DOTS client but after the TCP
connection is established, reverses its role and acts as DOTS server (see
https://tools.ietf.org/html/rfc8071). The access network can then program
the CPE using the DOTS data channel to block the DDoS attack traffic
originated from the compromised devices in the 

local customer network. 

Cheers,

-Tiru

From: Dots [mailto:[email-masked]] On Behalf Of
[email-masked]
Sent: Wednesday, February 14, 2018 1:49 PM
To: [email-masked]
Subject: [Dots] draft-ietf-dots-data-channel: Filter Direction

Hi all, 

As agreed during the interim, there are some issues that need fixes in the
data-channel spec. We would like to hear from the WG to know what to record
in the document. 

Issue description: Do we need to support explicit “direction” in filtering
rules (“in”/“out”)? That is, do we allow a DOTS client to create filters for
both incoming and outgoing traffic? 

–    The current default direction is aligned with the nature of DDoS
attacks targeted by DOTS: i.e. incoming. The DOTS client domain is assumed
to be the destination. No ambiguity so far with such default behavior. 

–    There is no clear use case for the support of outgoing filtering
handling in the context of DOTS.

–    No text change is required to the draft.

Any objection? 

Cheers,

Med

---

From: "Konda, Tirumaleswar Reddy" <[email-masked]>
Date: Fri, 16 Feb 2018 13:13:29 +0000

Hi Jon,

Please see inline

From: Jon Shallow [mailto:[email-masked]]
Sent: Friday, February 16, 2018 5:33 PM
To: Konda, Tirumaleswar Reddy <[email-masked]>; [email-masked]; [email-masked]
Subject: RE: [Dots] Call home in the signal channel (was RE: draft-ietf-dots-data-channel: Filter Direction)

Hi Tiru,

The more I think about it, "Call Home" support in either the data or signal channel makes no real sense for https://tools.ietf.org/html/draft-ietf-dots-use-cases-09#section-3.2.1 .  The CPE devices don't need to trigger the DOTS clients to get mitigation in place as it will be the provider who works this out.

[TR] No, the above use case helps the CPE isolate the compromised devices launching DDoS attacks and protect other devices in the local network from getting infected.

However, for 3.2.1, the DOTS client will need to make a mitigation request to initiate the implementing of (previously defined) ACLs using the signal channel as there will be a high possibility of the outbound pipe running full.

[TR] ACL can be enforced  with "activation" type set to "immediate" using the DOTS data channel itself.

-Tiru

Regards

Jon
From: Dots [mailto:[email-masked]] On Behalf Of Konda, Tirumaleswar Reddy
Sent: 16 February 2018 11:00
To: [email-masked]<mailto:[email-masked]>; Jon Shallow; [email-masked]<mailto:[email-masked]>
Subject: Re: [Dots] Call home in the signal channel (was RE: draft-ietf-dots-data-channel: Filter Direction)

-Tiru

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]]
Sent: Friday, February 16, 2018 3:49 PM
To: Jon Shallow <[email-masked]<mailto:[email-masked]>>; Konda, Tirumaleswar Reddy <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: Call home in the signal channel (was RE: [Dots] draft-ietf-dots-data-channel: Filter Direction)

Hi Jon,

Thank you.

Cheers,
Med

Regards

Jon

Re-,

Please see inline.

Cheers,
Med

[TR] Okay.

-Tiru

-Tiru

Hi Tiru,

Cheers,

Med

Cheers,
-Tiru

Hi all,

Any objection?

Cheers,

Med

---

From: "Jon Shallow" <[email-masked]>
Date: Fri, 16 Feb 2018 13:40:29 -0000

Hi Tiru,

See inline [Jon]

Regards

Jon

From: Dots [mailto: [email-masked]] On Behalf Of Konda, Tirumaleswar
Reddy
Sent: 16 February 2018 13:13
To: Jon Shallow; [email-masked]; [email-masked]
Subject: Re: [Dots] Call home in the signal channel (was RE:
draft-ietf-dots-data-channel: Filter Direction)

Hi Jon,

Please see inline

From: Jon Shallow [mailto:[email-masked]] 
Sent: Friday, February 16, 2018 5:33 PM
To: Konda, Tirumaleswar Reddy <[email-masked]>;
[email-masked]; [email-masked]
Subject: RE: [Dots] Call home in the signal channel (was RE:
draft-ietf-dots-data-channel: Filter Direction)

Hi Tiru,

[TR] No, the above use case helps the CPE isolate the compromised devices
launching DDoS attacks and protect other devices in the local network from
getting infected.

[Jon] OK, so the CPE says to itself “No idea what is going on, but something
bad is happening”, so I will call home to the provider for them to work out
what is going on and get them to tell me what to do by sending me some ACLs.

[Jon] Did I understand this correctly?

[TR] ACL can be enforced  with “activation” type set to “immediate” using
the DOTS data channel itself. 

[Jon] Agreed this can be done, but (TCP) will fail if the outgoing pipe is
full and so the ACL cannot be put in place.  A signal “mitigate to this
target prefix” will get through though and so kill off some of the traffic
going out to the Internet going to the target prefix.

-Jon

-Tiru

Regards

Jon

From: Dots [mailto: [email-masked]
<mailto:mailto:[email-masked]> ] On Behalf Of Konda, Tirumaleswar
Reddy
Sent: 16 February 2018 11:00
To: [email-masked]; Jon Shallow; [email-masked]
Subject: Re: [Dots] Call home in the signal channel (was RE:
draft-ietf-dots-data-channel: Filter Direction)

-Tiru

Hi Jon, 

Thank you. 

Cheers,

Med

Regards

Jon

Re-,

Please see inline. 

Cheers,

Med

 

[TR] Okay.

-Tiru

-Tiru

Hi Tiru, 

   functionality.

 
 
Cheers,
Med

local customer network. 

Cheers,

-Tiru

Hi all, 

Any objection? 

Cheers,

Med

---

From: "Konda, Tirumaleswar Reddy" <[email-masked]>
Date: Fri, 16 Feb 2018 14:18:54 +0000

From: Jon Shallow [mailto:[email-masked]]
Sent: Friday, February 16, 2018 7:10 PM
To: Konda, Tirumaleswar Reddy <[email-masked]>; [email-masked]; [email-masked]
Subject: RE: [Dots] Call home in the signal channel (was RE: draft-ietf-dots-data-channel: Filter Direction)

Hi Tiru,

See inline [Jon]

Regards

Jon

From: Dots [mailto: [email-masked]<mailto:[email-masked]>] On Behalf Of Konda, Tirumaleswar Reddy
Sent: 16 February 2018 13:13
To: Jon Shallow; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re: [Dots] Call home in the signal channel (was RE: draft-ietf-dots-data-channel: Filter Direction)

Hi Jon,

Please see inline

From: Jon Shallow [mailto:[email-masked]]
Sent: Friday, February 16, 2018 5:33 PM
To: Konda, Tirumaleswar Reddy <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: RE: [Dots] Call home in the signal channel (was RE: draft-ietf-dots-data-channel: Filter Direction)

Hi Tiru,

[TR] No, the above use case helps the CPE isolate the compromised devices launching DDoS attacks and protect other devices in the local network from getting infected.
[Jon] OK, so the CPE says to itself "No idea what is going on, but something bad is happening", so I will call home to the provider for them to work out what is going on and get them to tell me what to do by sending me some ACLs.
[Jon] Did I understand this correctly?

[TR2] No, the CPE may not even know if something bad is happening in its network. The CPE proactively initiates and establishes TLS session with the provider, and simply waits for requests from the provider to tell if there is something wrong (It's a long-lived session). Similar technique is also used to manage secure home gateways from cloud managment.

[TR] ACL can be enforced  with "activation" type set to "immediate" using the DOTS data channel itself.
[Jon] Agreed this can be done, but (TCP) will fail if the outgoing pipe is full and so the ACL cannot be put in place.  A signal "mitigate to this target prefix" will get through though and so kill off some of the traffic going out to the Internet going to the target prefix.

[TR2] My understanding is Mirai attacks do not choke the outgoing link in the local network, otherwise the home admin can easily detect the bandwidth hogging devices, rate-limit the traffic/turn-off the devices. The goal is to attack a target in some external domain but at the same-time not to disrupt local services to avoid any remediation.

-Tiru

-Jon

-Tiru

Regards

Jon
From: Dots [mailto: [email-masked]<mailto:mailto:[email-masked]>] On Behalf Of Konda, Tirumaleswar Reddy
Sent: 16 February 2018 11:00
To: [email-masked]<mailto:[email-masked]>; Jon Shallow; [email-masked]<mailto:[email-masked]>
Subject: Re: [Dots] Call home in the signal channel (was RE: draft-ietf-dots-data-channel: Filter Direction)

-Tiru

Hi Jon,

Thank you.

Cheers,
Med

Regards

Jon

Re-,

Please see inline.

Cheers,
Med

[TR] Okay.

-Tiru

-Tiru

Hi Tiru,

Cheers,

Med

Cheers,
-Tiru

Hi all,

Any objection?

Cheers,

Med

---

From: "Jon Shallow" <[email-masked]>
Date: Fri, 16 Feb 2018 15:30:13 -0000

Hi Tiru,

See inline [Jon1].

Regards

Jon

Hi Tiru,

[TR2] No, the CPE may not even know if something bad is happening in its
network. The CPE proactively initiates and establishes TLS session with the
provider, and simply waits for requests from the provider to tell if there
is something wrong (It’s a long-lived session). Similar technique is also
used to manage secure home gateways from cloud managment.

[Jon1] OK – a way of registering/saying “I’m here if needed”

[TR2] My understanding is Mirai attacks do not choke the outgoing link in
the local network, otherwise the home admin can easily detect the bandwidth
hogging devices, rate-limit the traffic/turn-off the devices. The goal is to
attack a target in some external domain but at the same-time not to disrupt
local services to avoid any remediation. 

[Jon1] Fair comment.  I still think there could be full pipe issues (e.g.
broken malware not smart enough to limit itself) that we need to think about
/ be able to handle.

-Jon1

-Tiru

-Jon

-Tiru

Regards

Jon

-Tiru

Hi Jon, 

Thank you. 

Cheers,

Med

Regards

Jon

Re-,

Please see inline. 

Cheers,

Med

 

[TR] Okay.

-Tiru

-Tiru

Hi Tiru, 

   functionality.

 
 
Cheers,
Med

local customer network. 

Cheers,

-Tiru

Hi all, 

Any objection? 

Cheers,

Med

---

From: "Konda, Tirumaleswar Reddy" <[email-masked]>
Date: Sun, 18 Feb 2018 10:25:07 +0000

Please see inline [TR3]

From: Jon Shallow [mailto:[email-masked]]
Sent: Friday, February 16, 2018 9:00 PM
To: Konda, Tirumaleswar Reddy <[email-masked]>; [email-masked]; [email-masked]
Subject: RE: [Dots] Call home in the signal channel (was RE: draft-ietf-dots-data-channel: Filter Direction)

Hi Tiru,

See inline [Jon1].

Regards

Jon

Hi Tiru,

[TR2] No, the CPE may not even know if something bad is happening in its network. The CPE proactively initiates and establishes TLS session with the provider, and simply waits for requests from the provider to tell if there is something wrong (It's a long-lived session). Similar technique is also used to manage secure home gateways from cloud managment.
[Jon1] OK - a way of registering/saying "I'm here if needed"

[TR3] Yes.

[TR2] My understanding is Mirai attacks do not choke the outgoing link in the local network, otherwise the home admin can easily detect the bandwidth hogging devices, rate-limit the traffic/turn-off the devices. The goal is to attack a target in some external domain but at the same-time not to disrupt local services to avoid any remediation.
[Jon1] Fair comment.  I still think there could be full pipe issues (e.g. broken malware not smart enough to limit itself) that we need to think about / be able to handle.

[TR3] Full pipe issues can be easily detected and blocked by the CPE, but the home CPE typically will not have the capability to detect attacks at L7 (e.g. TLS renegotiation attack) and such attacks won't create a full pipe issue in the attackers network.

Cheers,
-Tiru

-Jon1

-Tiru

-Jon

-Tiru

Regards

Jon

-Tiru

Hi Jon,

Thank you.

Cheers,
Med

Regards

Jon

Re-,

Please see inline.

Cheers,
Med

[TR] Okay.

-Tiru

-Tiru

Hi Tiru,

Cheers,

Med

Cheers,
-Tiru

Hi all,

Any objection?

Cheers,

Med

---

From: "Roland Dobbins" <[email-masked]>
Date: Mon, 19 Feb 2018 04:19:15 +0700

On 16 Feb 2018, at 21:18, Konda, Tirumaleswar Reddy wrote:

>  My understanding is Mirai attacks do not choke the outgoing link in 
> the local network,

This depends - but we aren't designing DOTS around any specific botnet, 
such as Mirai.

The specifics of Mirai attack characteristics are irrelevant to this 
discussion.

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

---

From: "Roland Dobbins" <[email-masked]>
Date: Mon, 19 Feb 2018 04:19:41 +0700

> broken malware not smart enough to limit itself) that we need to think 

Correct.

---

From: "Roland Dobbins" <[email-masked]>
Date: Mon, 19 Feb 2018 04:20:54 +0700

On 18 Feb 2018, at 17:25, Konda, Tirumaleswar Reddy wrote:

> [TR3] Full pipe issues can be easily detected and blocked by the CPE,

This is incorrect.  CPE have zero ability to detect whether the pipe is 
full, and zero capability to block the traffic in question.

---

From: "Konda, Tirumaleswar Reddy" <[email-masked]>
Date: Mon, 19 Feb 2018 06:50:47 +0000

> -----Original Message-----
> From: Roland Dobbins [mailto:[email-masked]]
> Sent: Monday, February 19, 2018 2:49 AM
> To: Konda, Tirumaleswar Reddy <[email-masked]>
> Cc: Jon Shallow <[email-masked]>;
> The specifics of Mirai attack characteristics are irrelevant to this discussion.

Mirai attack is only used as an example. For the use case https://tools.ietf.org/html/draft-ietf-dots-use-cases-09#section-3.2.1, the discussion is when compromised device in the local network launch DDOS attack on targets in other domains, whether these compromised devices would saturate outgoing pipe in the local network itself ?

-Tiru

---

From: "Konda, Tirumaleswar Reddy" <[email-masked]>
Date: Mon, 19 Feb 2018 07:04:44 +0000

> Sent: Monday, February 19, 2018 2:51 AM
> This is incorrect.  CPE have zero ability to detect whether the pipe is full, and
> zero capability to block the traffic in question.

No, for the use case https://tools.ietf.org/html/draft-ietf-dots-use-cases-09#section-3.2.1 CPE will have to be enhanced to act as a DOTS server, suppress attack traffic and isolate compromised devices. 
The discussion is whether DOTS data channel is sufficient to meet the above use case and if DOTS signal channel is also required ?

-Tiru

---

From: "Konda, Tirumaleswar Reddy" <[email-masked]>
Date: Mon, 19 Feb 2018 07:33:20 +0000

> Sent: Monday, February 19, 2018 2:50 AM
> To: Jon Shallow <[email-masked]>
> Cc: Konda, Tirumaleswar Reddy <[email-masked]>;
> > broken malware not smart enough to limit itself) that we need to think
> > about / be able to handle.
> 
> Correct.

The brings in additional requirements for the DOTS signal channel to meet the use case https://tools.ietf.org/html/draft-ietf-dots-use-cases-09#section-3.2.1 
a) Call home functionality is required for the DOTS signal channel, a new port is required (just like RESTCONF Call Home https://tools.ietf.org/html/rfc8071#section-6).
b) The mitigation request will have to convey the source IP addresses (to block and Quarantine compromised devices). 

Cheers,
-Tiru

---

From: "Dobbins, Roland" <[email-masked]>
Date: Mon, 19 Feb 2018 09:01:17 +0000

> On Feb 19, 2018, at 13:51, Konda, Tirumaleswar Reddy <[email-masked]> wrote:
> 
> whether these compromised devices would saturate outgoing pipe in the local network itself ?

Sometimes yes, sometimes no.

---

From: "Dobbins, Roland" <[email-masked]>
Date: Mon, 19 Feb 2018 09:03:10 +0000

> On Feb 19, 2018, at 14:05, Konda, Tirumaleswar Reddy <[email-masked]> wrote:
> 
> CPE will have to be enhanced to act as a DOTS server, suppress attack traffic and isolate compromised devices.

That's a future thing, for them to do that on their own. 

In the meantime, it's useful to have this capability based upon centralized instructions.

---

From: "Konda, Tirumaleswar Reddy" <[email-masked]>
Date: Mon, 19 Feb 2018 09:56:17 +0000

> From: Dots [mailto:[email-masked]] On Behalf Of Dobbins, Roland
> Sent: Monday, February 19, 2018 2:33 PM
> > On Feb 19, 2018, at 14:05, Konda, Tirumaleswar Reddy
> <[email-masked]> wrote:
> >

I don't get the above comment, we are discussing the requirements to meet the use case https://tools.ietf.org/html/draft-ietf-dots-use-cases-09#section-3.2.1. 

-Tiru

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

---

From: "Dobbins, Roland" <[email-masked]>
Date: Mon, 19 Feb 2018 16:10:34 +0000

On Feb 19, 2018, at 16:56, Konda, Tirumaleswar Reddy <[email-masked]<mailto:[email-masked]>> wrote:

'In order to achieve this capability, the telemetry analysis system

   functionality'

. . .

'When the telemetry analysis system detects and
   classifies an outbound DDoS attack sourced from one or more end-
   customer networks/devices, the DOTS client of the telemetry analysis
   system sends a DOTS request to the DOTS server implemented on the CPE
   devices, requesting local mitigation assistance in suppressing either
   the identified outbound DDoS traffic, or all outbound traffic sourced
   from the end-customer networks/devices.'

Detection/classification/traceback in this scenario takes place centrally, not on the individual CPE devices.

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

---

From: "Konda, Tirumaleswar Reddy" <[email-masked]>
Date: Tue, 20 Feb 2018 09:00:34 +0000

From: Dots [mailto:[email-masked]] On Behalf Of Dobbins, Roland
Sent: Monday, February 19, 2018 9:41 PM
To: Konda, Tirumaleswar Reddy <[email-masked]>
Cc: [email-masked]; Jon Shallow <[email-masked]>; [email-masked]
Subject: Re: [Dots] Call home in the signal channel (was RE: draft-ietf-dots-data-channel: Filter Direction)

utilized by the broadband access provider must have DOTS client functionality'

. . .

'When the telemetry analysis system detects and classifies an outbound DDoS attack sourced from one or more end- customer networks/devices, the DOTS client of the telemetry analysis system sends a DOTS request to the DOTS server implemented on the CPE devices, requesting local mitigation assistance in suppressing either the identified outbound DDoS traffic, or all outbound traffic sourced from the end-customer networks/devices.'

[TR] Yes, but in this use case the CPE needs to act as a DOTS server and currently the DOTS signal channel only conveys the attack targets, and does not signal the source IP addresses

launching the attack.

-Tiru

---

From: "Dobbins, Roland" <[email-masked]>
Date: Tue, 20 Feb 2018 11:07:14 +0000

On Feb 20, 2018, at 16:01, Konda, Tirumaleswar Reddy <[email-masked]<mailto:[email-masked]>> wrote:

only conveys the attack targets

Sure, so the message is, "Block outbound traffic to xxx.xxx.xxx.xxx".

---

From: "Konda, Tirumaleswar Reddy" <[email-masked]>
Date: Tue, 20 Feb 2018 12:19:14 +0000

From: Dobbins, Roland [mailto:[email-masked]]
Sent: Tuesday, February 20, 2018 4:37 PM
To: Konda, Tirumaleswar Reddy <[email-masked]>
Cc: [email-masked]; Jon Shallow <[email-masked]>; [email-masked]
Subject: Re: [Dots] Call home in the signal channel (was RE: draft-ietf-dots-data-channel: Filter Direction)

Yes, but the mitigation request not only blocks outbound traffic to xxx.xxx.xxx.xxx from bad devices but also from good devices.
If the mitigation request could also convey the source IP addresses, the CPE can isolate or quarantine the compromised device and only block out-band traffic originating from the compromised devices in the home network.

Cheers,
-Tiru

---

From: "Dobbins, Roland" <[email-masked]>
Date: Tue, 20 Feb 2018 13:57:16 +0000

On Feb 20, 2018, at 19:20, Konda, Tirumaleswar Reddy <[email-masked]<mailto:[email-masked]>> wrote:

Yes, but the mitigation request not only blocks outbound traffic to xxx.xxx.xxx.xxx from bad devices but also from good devices.
Which is not a huge concern, in most cases of this nature.
If the mitigation request could also convey the source IP addresses, the CPE can isolate or quarantine the compromised device and only block out-band traffic originating from the compromised devices in the home network.
The centralized detection/classification system can issue the request only to the relevant CPE, based on its identification of the relevant source IPs.