Re: [Dots] Signal / Data / Alias / Filter Implementation

I guess I am confused by your response.  Yes, the DOTS Server may be able to
work out the source-* information before passing it to the DOTS Mitigator,
but may need some hints from the DOTS client as to what to do.  I was not
expecting the DOTS Server to be feeding back information to the DOTS client
for the DOTS client to mitigate.

I (probably badly) was trying to describe a DOTS Client that had some
intelligence and could feed hints up to the DOTS Server.

In draft-ietf-dots-use-cases-07 
3.1.6.  End-customer operating a CPE network infrastructure device with
        an integrated DOTS client
The CPE device with integrated DOTS Client may be able to work out which
source-* and destination-* is needed to mitigate the attack (which could be
internet pipe flooding etc.) but has no mechanism to signal any source-*
information upstream to the DOTS server.

Hence 3  questions as to how can this source-* information be handled with
the current draft-ietf-dots-signal-channel ?

Regards

Jon

-----Original Message-----
From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of Roland Dobbins
Sent: 02 August 2017 11:46
To: Jon Shallow
Cc: dots@ietf.org
Subject: Re: [Dots] Signal / Data / Alias / Filter Implementation

On 2 Aug 2017, at 17:13, Jon Shallow wrote:

> The DOTS client may have the smarts to work out what are the 
> problematic
> source-* etc. values (e.g. can generate smart BGP FlowSpec rules) are 
> that will sensibly control the DDoS Attack.

Whatever orchestration system is getting input from the receiving DOTS
server, actually.

-----------------------------------
Roland Dobbins <rdobbins@arbor.net>

_______________________________________________
Dots mailing list
Dots@ietf.org
https://www.ietf.org/mailman/listinfo/dots