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

["Jon Shallow" <[e-mail]>]

Hi Tiru,

 

I therefor propose to the WG that ietf-dots-signal (and its counterpart
ietf-dots-data-channel) is extended to cover the source-*, icmp types and
fragmentation as optional (and hint) entries to handle any future work in
Telemetry etc.

 

This simply would be extending the text in the appropriate places - agreed a
laborious job, but not rocket science.

 

New DDOS Attacks will be "created" and we need a way of being able to handle
them moving forward rather than what we have at present which is a
Destination RTBH with the added bonus of some extra destination fields
capability from the DOTS client - very limiting in my opinion.

 

Regards

 

Jon

 

From: Dots [mailto: [e-mail]] On Behalf Of Konda, Tirumaleswar
Reddy
Sent: 03 August 2017 10:35
To: Jon Shallow; [e-mail]
Subject: Re: [Dots] Signal / Data / Alias / Filter Implementation

 

Hi Jon,

 

This draft was presented and discussed in the WG, but since DOTS telemetry
is optional the feedback we got was to pursue this work later and there was
no agreement in the WG on the common attributes of an DDoS attack and the
protocol to convey this information (there were proposals to use DOTS signal
channel, data channel and IPFIX). 

 

-Tiru

 

From: Dots [mailto:[e-mail]] On Behalf Of Jon Shallow
Sent: Thursday, August 3, 2017 2:31 PM
To: [e-mail]
Subject: Re: [Dots] Signal / Data / Alias / Filter Implementation

 

Hi Tiru,

 

Thanks for the document pointer - a good read and reminds me of the initial
work I did with Nik Teague on getting DOTS started.

 

However, it is still unclear to me how the "DOTS Telemetry"
intelligence/hints can be conveyed over the signal and data channels using
what is currently defined, unless it is all done over the data channel using
ietf-dots-access-control-list.  My preferred option is that ietf-dots-signal
is extended to cover the more common attributes of an DDoS Attack.

 

Regards

 

Jon

 

From: Dots [mailto: [e-mail]] On Behalf Of Konda, Tirumaleswar
Reddy
Sent: 03 August 2017 09:44
To: Jon Shallow; [e-mail]
Subject: Re: [Dots] Signal / Data / Alias / Filter Implementation

 

Hi Jon,

 

We discussed various such hints including "attack details" in
https://tools.ietf.org/html/draft-doron-dots-telemetry-00.

 

-Tiru

 

From: Dots [mailto:[e-mail]] On Behalf Of Jon Shallow
Sent: Thursday, August 3, 2017 1:45 PM
To: [e-mail]
Subject: Re: [Dots] Signal / Data / Alias / Filter Implementation

 

Hi Tiru,

 

I agree that it is highly likely that a DDoS Attack will mutate over its
life time.  Reflections attacks (where the source port is constant - e.g. 53
or 123 udp) do not mutate so frequently in my experience and there is no way
to signal for that type of to be stopped currently.  The DOTS client may
continue to change its mitigation requests as the attacks evolve / mutate
which is fine from my perspective.

 

I really want to move away from Vendor Specifics for the more common
definitions so that there is a standard across all vendors - even if the
parameters are optional and are just hints.

 

I am not trying to re-create FlowSpec here in the signal  parameters, but
there (co-incidentally) is a large overlap.  FlowSpec does not support Uri,
but I think that is a good thing in dots-signal-channel.

 

Regards

 

Jon

 

From: Dots [mailto: [e-mail]] On Behalf Of Konda, Tirumaleswar
Reddy
Sent: 03 August 2017 08:58
To: Jon Shallow; [e-mail]
Subject: Re: [Dots] Signal / Data / Alias / Filter Implementation

 

The source IP addresses and source ports used by the DDoS attacker could
change, the type of attack itself could evolve or change from one attack
type to another.

It was discussed in the WG that this kind of information are only hints and
not mandatory to be conveyed by the DOTS client in the mitigation request.
https://tools.ietf.org/html/draft-ietf-dots-requirements-06 only discusses
conveying the mitigation scope and not the source or type of the attack.
However, DOTS signal channel draft allows vendor specific parameters and
reserved key values in the range of 32768 to 65536 for vendor specific
parameters, these hints can be conveyed as vendor-specific parameters to the
DOTS server.

 

-Tiru

 

From: Dots [mailto:[e-mail]] On Behalf Of Jon Shallow
Sent: Wednesday, August 2, 2017 3:43 PM
To: [e-mail]
Subject: [Dots] Signal / Data / Alias / Filter Implementation

 

Hi There,

 

I am trying to get my mind around how to implement this and have some
questions / statements.

 

Signal Channel

 

The Signal channel looks very like Destination RTBH with some extras
(protocols / port) as everything is target-* based.  There is no concept of
source-ip, source-port (to handle reflection attacks) etc. or dealing with
fragmented packet, icmp types and rate-limiting.

 

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.

 

It is possible to use a previously defined alias over the Data Channel as an
alternative for a mitigation request, but this too has source-* etc.
limitations.

I have not found a way of using a Filter defined over the Data Channel as a
signal

 

Sending a signal will cause all traffic to stop (or rate-limit possibly if
it also happens to match a filter) to the target IP on the ports in question
-  DDoS attack is now effective unless the DOTS server elects (via DNS or
BGP swing) to scrub that particular traffic (by controlling rates, Source
IPs / Source Ports etc.).

 

Data Channel

 

Can be used to set up aliases for later use.  These again however appear to
be target-* based, with no source-*, icmp type or fragmentation
capabilities.

 

Can set up a Filter, which does include both source and destination IPs, but
appears that it is acted on when pushed over the data channel, and cannot be
send as a signal - appears to be in place more for black/white listing IPs
than as a signal for mitigation, but does include rate-limiting

 

Questions

 

How do we handle Source-* information in a mitigation signal request?

How do we handle specific ICMP types  in a mitigation signal request?

How do we handle fragmentation  in a mitigation signal request?

 

Regards

 

Jon