Re: [Dots] Suggestions about draft-nishizuka-dots-signal-control-filtering

["Konda, Tirumaleswar Reddy" <[e-mail]>]

If accept-listed sources are attacking the target, the DOTS server cannot turn-off the accept-list filtering rules without the consent from the DOTS client. DOTS server can inform the DOTS client of the conflict and/or the DOTS client with DDoS detection capability can identify the attack, and using the signal channel de-activate the accept-list filtering rules.

“accept-list” does not mean only the traffic matching the accept-list will be allowed to reach the target.

Cheers,
-Tiru

From: Dots <[e-mail]> On Behalf Of [e-mail]
Sent: Friday, November 23, 2018 12:04 PM
To: Panwei (William) <[e-mail]>; kaname nishizuka <[e-mail]>
Cc: [e-mail]
Subject: Re: [Dots] Suggestions about draft-nishizuka-dots-signal-control-filtering


CAUTION: External email. Do not click links or open attachments unless you recognize the sender and know the content is safe.


________________________________
Hi Wei,

Please see inline.

Cheers,
Med

De : Dots [mailto:[e-mail]] De la part de Panwei (William)
Envoyé : vendredi 23 novembre 2018 04:09
À : kaname nishizuka
Cc : [e-mail]<mailto:[e-mail]>
Objet : [Dots] Suggestions about draft-nishizuka-dots-signal-control-filtering

Hi Kaname,

I have read your draft recently, and I have two suggestions about it.

1.      I’d like to suggest using “whitelist” or “DDoS detection whitelist” instead of “accept-list” in the typical case.

[Med] accept-list means white-list. accept-list is already used in DOTS requirements and data channel. The signal channel will make use of that term too. FWIW, that change is made because of what was reported by hrpc.

A typical case is a DOTS client which configures during peace time
filtering rules using data channel to permit traffic from accept-
listed sources, but during the volumetric DDoS attack the DDoS
mitigator identifies the source addresses/prefixes in the accept-
listed filtering rules are attacking the target. For example, an
attacker can spoof the IP addresses of accept-listed sources to
generate attack traffic or the attacker can compromise the accept-
listed sources and program them to launch DDoS attack.
In this typical case, when you use “accept-list”, it sounds like that only the traffic which match the accept-list can reach the target. I don’t know if you mean so, but if YES, I feel like the extension may not be essentially needed in such case. Because if a DDoS attack occurs in such situation, the attacker must have been included in the accept-list. The DOTS server can get this conclusion as the DOTS client can, so the DOTS server can de-activate the accept-list by its own without DOTS client’s request of filtering rules.
In my opinion, “whitelist” or “DDoS detection whitelist” is more suitable than  “accept-list”. Because it indicates that the traffic which doesn’t match the DDoS whitelist can also reach the target, as long as it passes the detection. And if a DDoS attack happens, the DOTS server can’t know if the attacker is in the whitelist. If DOTS client find that the attacker is included in the DDoS whitelist, it must request the DOTS server to de-activate the whitelist.

I’m not object to your case, I just want to make it clear and no misunderstanding.

2. I’d like to suggest adding a guideline or suggestion about using signal channel to control filtering rules.
The purpose of using DOTS signal channel to control filtering rules is trying to help mitigate the DDoS attack when under attack time. This purpose should also be the guideline.
Requests which can help mitigate the attack should be send by the signal channel immediately. Requests which can’t help mitigate the attack should wait for the data channel to be re-established and then be sent by the data channel.
For example, during attack time, de-activating a drop-list (or blacklist) or activating a accept-list (or whitelist) may usually not help mitigate the DDoS attack. So If there is no necessary reason, these two requests should wait for using the data channel.

[Med] Agree. We do have the following in -01:

   A DOTS client relies on the information received from the DOTS server
   and/or local information to the DOTS client domain to trigger a
   filter control request.  Obviously, only filters that are pertinent
   for an ongoing mitigation should be controlled by a DOTS client using
   the DOTS signal channel.

And

   The DOTS client can also decide to send a PUT request to deactivate
   the "an-accept-list" ACL, if suspect traffic is received from an
   accept-listed source (2001:db8:1234::/48).  The structure of that PUT
   is the same as the one shown in Figure 4.


Best Regards
Wei Pan

发件人: Dots [mailto:[e-mail]] 代表 kaname nishizuka
发送时间: 2018年11月21日 9:50
收件人: [e-mail]<mailto:[e-mail]>
主题: [Dots] Fwd: I-D Action: draft-nishizuka-dots-signal-control-filtering-00.txt

Hi,

Base on the discussion of Bangkok interop: control data channel filtering via signal channel,
we've submitted the new draft for an extension to the DOTS signal channel to control the filtering rules during attack mitigation.

thanks,
Kaname Nishizuka



-------- Forwarded Message --------
Subject:

I-D Action: draft-nishizuka-dots-signal-control-filtering-00.txt

Date:

Tue, 20 Nov 2018 17:42:13 -0800

From:

[e-mail]<mailto:[e-mail]>

Reply-To:

[e-mail]<mailto:[e-mail]>

To:

[e-mail]<mailto:[e-mail]>



A New Internet-Draft is available from the on-line Internet-Drafts directories.





        Title           : Controlling Filtering Rules Using DOTS Signal Channel

        Authors         : Kaname Nishizuka

                          Takahiko Nagata

                          Tirumaleswar Reddy

                          Mohamed Boucadair

    Filename        : draft-nishizuka-dots-signal-control-filtering-00.txt

    Pages           : 11

    Date            : 2018-11-20



Abstract:

   This document specifies an extension to the DOTS signal channel to

   control the filtering rules during attack mitigation.



   This extension allows a DOTS client to activate or de-activate

   filtering rules during a DDoS attack.  The characterization of these

   filters is supposed to be conveyed by a DOTS client during peace time

   by means of DOTS data channel.



Editorial Note (To be removed by RFC Editor)



   Please update these statements within the document with the RFC

   number to be assigned to this document:



   o  "This version of this YANG module is part of RFC XXXX;"



   o  "RFC XXXX: Controlling Filtering Rules Using DOTS Signal Channel";



   o  reference: RFC XXXX



   o  [RFCXXXX]



   Please update these statements with the RFC number to be assigned to

   the following documents:



   o  "RFC SSSS: Distributed Denial-of-Service Open Threat Signaling

      (DOTS) Signal Channel Specification" (used to be

      [I-D.ietf-dots-signal-channel])



   o  "RFC DDDD: Distributed Denial-of-Service Open Threat Signaling

      (DOTS) Data Channel Specification" (used to be

      [I-D.ietf-dots-data-channel])



   Please update the "revision" date of the YANG module.





The IETF datatracker status page for this draft is:

https://datatracker.ietf.org/doc/draft-nishizuka-dots-signal-control-filtering/



There are also htmlized versions available at:

https://tools.ietf.org/html/draft-nishizuka-dots-signal-control-filtering-00

https://datatracker.ietf.org/doc/html/draft-nishizuka-dots-signal-control-filtering-00





Please note that it may take a couple of minutes from the time of submission

until the htmlized version and diff are available at tools.ietf.org.



Internet-Drafts are also available by anonymous FTP at:

ftp://ftp.ietf.org/internet-drafts/



_______________________________________________

I-D-Announce mailing list

[e-mail]<mailto:[e-mail]>

https://www.ietf..org/mailman/listinfo/i-d-announce<https://www.ietf.org/mailman/listinfo/i-d-announce>

Internet-Draft directories: http://www.ietf.org/shadow.html

or ftp://ftp.ietf.org/ietf/1shadow-sites.txt