Subject: [Dots] draft-ietf-dots-use-cases-09 posted - please review and provide feedback.

From: "Roland Dobbins" <[email-masked]>
Date: Mon, 13 Nov 2017 05:38:52 +0700

We've re-organized the use-cases so that DOTS implementors won't feel 
compelled to read through multiple use-cases with similar DOTS 
communications models, while at the same time retaining those use-cases 
because they contain significant procedural, operational, and 
topological variances which are of great significance to network 
operators and end-customer organizations.

The wording in the DOTS communications model listings and several of the 
use-cases has been streamlined.  The security considerations were 
updated to include DDoS attacks.

Finally, we really need WG feedback on the applicability of Section 
3.2.2, 'Home Network DDoS Detection Collaboration for ISP network 
management'.

Thanks much!

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

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

---

From: Maheswaran Balasubramanian <[email-masked]>
Date: Mon, 13 Nov 2017 20:22:52 +0000

Typically, SOHO devices(CPE) built with finite resources and offloading the detection function to this CPE has its own limitation. Doing DPI (or) heuristics at SOHO devices certainly requires enough resources (processing power) also necessary intelligence built into it.

Thanks.

________________________________
From: Dots <[email-masked]> on behalf of Roland Dobbins <[email-masked]>
Sent: Monday, November 13, 2017 4:08:52 AM
To: dots
Subject: [Dots] draft-ietf-dots-use-cases-09 posted - please review and provide feedback.

Thanks much!

_______________________________________________
Dots mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dots
Dots Info Page - Internet Engineering Task Force<https://www.ietf.org/mailman/listinfo/dots>
www.ietf.org
Dots -- List for discussion of DDoS Open Threat Signaling (DOTS) technology and directions. About Dots

---

From: Artyom Gavrichenkov <[email-masked]>
Date: Mon, 13 Nov 2017 23:56:17 +0300

Hi,

So what? Someone should have that processing power, either far or
close to the endpoint. Building a DPI system for attack detection on
the ISP side only is costly and error-prone (as it is stated on the
draft). RFC 7754, for one, insists on doing filtering *on* the
endpoint, or at least as close to it as possible.

Moreover, ISPs are recently becoming used to supply SOHO devices to
their customers themselves, so this is purely a decision on their side
where to set up the detection: everything in their network, except for
endpoints, is essentially under their full control. A use case where
DPI is run far from the endpoint is in fact covered already in 3.1, so
3.2.2 is just another option for a service provider.

| Artyom Gavrichenkov
| gpg: 2deb 97b1 0a3c 151d b67f 1ee5 00e7 94bc 4d08 9191
| mailto: [email-masked]
| fb: ximaera
| telegram: xima_era
| skype: xima_era
| tel. no: +7 916 515 49 58

On Mon, Nov 13, 2017 at 11:22 PM, Maheswaran Balasubramanian
<[email-masked]> wrote:
>
>
> Typically, SOHO devices(CPE) built with finite resources and offloading the
> detection function to this CPE has its own limitation. Doing DPI (or)
> heuristics at SOHO devices certainly requires enough resources (processing
> power) also necessary intelligence built into it.
>
>
> Thanks.
>
>
> Dots Info Page - Internet Engineering Task Force
> www.ietf.org

---

From: Flemming Andreasen <[email-masked]>
Date: Mon, 13 Nov 2017 22:56:30 -0500

On 11/12/17 5:38 PM, Roland Dobbins wrote:
> communications models, while at the same time retaining those 
> use-cases because they contain significant procedural, operational, 
> and topological variances which are of great significance to network 
> The wording in the DOTS communications model listings and several of 
> the use-cases has been streamlined.  The security considerations were 
I think the use case itself is perfectly valid. The actual text in the 
section is a bit verbose though.

Thanks

-- Flemming

> .