Subject: Re: [Dots] TR: New Version Notification for draft-nishizuka-dots-signal-control-filtering-02.txt

From: Takahiko Nagata <[email-masked]>
Date: Sun, 10 Feb 2019 16:52:14 +0900

Hi Med, all,

Thank you for updated draft.

I have a question for usecase of this draft -03 specification.

(Question) Would we allow using Mitigation request with
   only control-filtering attributes?

This mean, PUT SignalChannel Mitigation request with
only acl-list (without any target-xxx).

Usecase:
   Only update status of DataChannel ACL during a DDoS attack.
   (If DataChannel ACL is enough for protection. )

Best Regards,
Takahiko Nagata

On 2019/01/21 23:25, [email-masked] wrote:
> Hi Takahiko,
> 
> I updated the draft to take into account your comments:
> 
> * Make sure that by default, the data channel is used for ACL-related operations.
> * No update is required to efficacy update, get, and delete.
> 
> Please let us know if the changes addresses your comments.
> 
> Don't hesitate to share any further comment you may have. Thanks.
> 
> Cheers,
> Med
> 
>> -----Message d'origine-----
>> De : [email-masked] [mailto:[email-masked]]
>> Envoyé : lundi 21 janvier 2019 15:21
>> À : Takahiko Nagata; Tirumaleswar Reddy; BOUCADAIR Mohamed TGI/OLN; Reddy K;
>> Kaname Nishizuka
>> Objet : New Version Notification for draft-nishizuka-dots-signal-control-
>> filtering-02.txt
>>
>>
>> A new version of I-D, draft-nishizuka-dots-signal-control-filtering-02.txt
>> has been successfully submitted by Mohamed Boucadair and posted to the
>> IETF repository.
>>
>> Name:		draft-nishizuka-dots-signal-control-filtering
>> Revision:	02
>> Title:		Controlling Filtering Rules Using DOTS Signal Channel
>> Document date:	2019-01-21
>> Group:		Individual Submission
>> Pages:		15
>> URL:            https://www.ietf.org/internet-drafts/draft-nishizuka-dots-
>> signal-control-filtering-02.txt
>> Status:         https://datatracker.ietf.org/doc/draft-nishizuka-dots-signal-
>> control-filtering/
>> Htmlized:       https://tools.ietf.org/html/draft-nishizuka-dots-signal-
>> control-filtering-02
>> Htmlized:       https://datatracker.ietf.org/doc/html/draft-nishizuka-dots-
>> signal-control-filtering
>> Diff:           https://www.ietf.org/rfcdiff?url2=draft-nishizuka-dots-
>> signal-control-filtering-02
>>
>> Abstract:
>>     This document specifies an extension to the DOTS signal channel to
>>     control the filtering rules when an attack mitigation is active.
>>
>>     Particularly, this extension allows a DOTS client to activate or de-
>>     activate filtering rules during a DDoS attack.  The characterization
>>     of these filtering rules 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.
>>
>>
>>
>>
>> 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.
>>
>> The IETF Secretariat
> 

-- 
=============================
株式会社レピダム
永田　貴彦

Mail: [email-masked]
Tel:   03-6276-5103

〒151-0071
東京都渋谷区本町3-12-1　住友不動産西新宿ビル6号館
=============================

---

From: <[email-masked]>
Date: Mon, 11 Feb 2019 07:39:50 +0000

Hi Takahiko, 

The parameters used in the initial request must be repeated in the refresh request to modify the control filtering.

Please note that sending only acl-list attributes in a PUT will fail because of the checks against mandatory attributes:

   In the PUT request at least one of the attributes 'target-prefix',
   'target-fqdn','target-uri', or 'alias-name' MUST be present.

   ...

   If the request is missing a mandatory attribute, does not include
   'cuid' or 'mid' Uri-Path options, includes multiple 'scope'
   parameters, or contains invalid or unknown parameters, the DOTS
   server MUST reply with 4.00 (Bad Request).

Cheers,
Med

> De : Dots [mailto:[email-masked]] De la part de Takahiko Nagata
> Envoyé : dimanche 10 février 2019 08:52
> À : [email-masked]
> Objet : Re: [Dots] TR: New Version Notification for draft-nishizuka-dots-
> _______________________________________________
> Dots mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dots

---

From: <[email-masked]>
Date: Fri, 15 Feb 2019 07:42:08 +0000

Hi Takahiko, 

The draft is updated to make this more clear. Please check -04.

Cheers,
Med

> De : Dots [mailto:[email-masked]] De la part de
> [email-masked]
> Envoyé : lundi 11 février 2019 08:40
> À : Takahiko Nagata; [email-masked]
> Please note that sending only acl-list attributes in a PUT will fail because
> of the checks against mandatory attributes:
> 
> > >> À : Takahiko Nagata; Tirumaleswar Reddy; BOUCADAIR Mohamed TGI/OLN;
> Reddy
> > K;
> > >> Kaname Nishizuka