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

["Panwei (William)" <[e-mail]>]

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.
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.

Best Regards
Wei Pan

发件人: Dots [mailto:[e-mail]] 代表 kaname nishizuka
发送时间: 2018年11月21日 9:50
收件人: [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

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

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