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

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

Hi There,

 

This thread has flagged up to me that we are trying to represent a tri-state of actions (“always-drop”, “always-let-through” and “let-through-if-after-being-mitigated-it-is-allowed”) with a duo-state of “accept-list” and “drop-list” in the (Data Channel) ACLs.

 

The traditional ACL is a set of match criteria and then an appropriate action if matched.  

[As a separate note, picked up later, it has always been unclear in my mind over many years as to what happens if a packet does not trigger a match in any of the ACLs (falls off the end of the list).  What happens is usually defined by documentation of what actually happens in the underlying logic.  The Data Channel currently states “If there is no match, then there is no action to be taken against the packet.”.]

The Data Channel only defines the DOTS forwarding actions as ‘accept’ or ‘drop’ with the addition of ‘rate-limit’ if ‘accept’ is defined.

It does state that, as an example, “Accept-list management, which enables a DOTS client to inform a DOTS server about sources from which traffic should always be accepted” which implies that ‘accept’ is the same as what we knew as white-list.  However, ‘accept’ means just that – it is accepted at this point in the process.  Yes, it is effectively defined as a white list in the requirements document, but even though those working with the DOTS documents can get confused as they also are thinking about mitigate or mitigation [Is it accepted for mitigation, or is it unconditionally accepted?].

 

We need the DOTS server to clearly understand the tri-state, and  cause (how is out of scope) traffic to be always accepted, always dropped or be analysed to see if it needs to be mitigated.

 

In terms of moving forward, we could (in Data Channel) have an additional ‘leaf mitigate’ in ‘container actions’ which is only available when ‘accept’.  If true, traffic is passed to a mitigator (how out of scope), if false traffic is always passed through. (‘leaf rate-limit’ is a special case of mitigation I guess.)

Alternatively, we could have actions of ‘accept’, ‘drop’ or ‘mitigate’.  ‘accept’ would then have the traditional meaning of pass – effectively a white-list as previously intended, and ‘mitigate’ much clearer to the reader as to the intent.  Then we just need a definition for “Mitigate-List:”.  I think ‘rate-limit’ would then have to only be associated with ‘mitigate’, not ‘accept’ as ‘accept’ is whitelist(no expected additional action).

 

Using ‘accept’, ‘drop’ or ‘mitigate’ (or ‘accept + mitigate’, ‘accept + no-mitigate’ or ‘drop’ if going with the additional leaf suggestion) makes it much easier to directly instantiate these actions in the DOTS server environment.

 

That then just leaves the question of what happens if there are no ACL matches (there could be no ACLs defined).  Do we go for an implied last ACL of all other traffic is to be mitigated if mitigating (Signal channel request), or do we take ‘no action’ as defined in the Data Channel?

 

Regards

 

Jon

 

From: Dots [mailto: [e-mail]] On Behalf Of Panwei (William)
Sent: 23 November 2018 08:25
To: Konda, Tirumaleswar Reddy; [e-mail]
Cc: [e-mail]; kaname nishizuka
Subject: Re: [Dots] Suggestions about draft-nishizuka-dots-signal-control-filtering

 

Hi Tiru, Med,

 

Thank you for explaining and reminding me. I just remembered that this terminology has already been described in the requirement draft.

Accept-list: A list of filters indicating sources from which traffic

should always be allowed, regardless of contradictory data gleaned

in a detected attack.

 

Best Regards

Wei Pan

 

发件人: Konda, Tirumaleswar Reddy [mailto:[e-mail]] 
发送时间: 2018年11月23日 16:07
收件人: [e-mail]; Panwei (William) <[e-mail]>; kaname nishizuka <[e-mail]>
抄送: [e-mail]
主题: RE: Suggestions about draft-nishizuka-dots-signal-control-filtering

 

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]
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]
主题: [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]


Reply-To: 

[e-mail]


To: 

[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]
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