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

[<[e-mail]>]

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

> -----Message d'origine-----
> De : Dots [mailto:[e-mail]] De la part de Takahiko Nagata
> Envoyé : dimanche 10 février 2019 08:52
> À : [e-mail]
> Objet : Re: [Dots] TR: New Version Notification for draft-nishizuka-dots-
> signal-control-filtering-02.txt
> 
> 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, [e-mail] 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 : [e-mail] [mailto:[e-mail]]
> >> 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: [e-mail]
> Tel:   [phone]
> 
> 〒151-0071
> 東京都渋谷区本町3-12-1　住友不動産西新宿ビル6号館
> =============================
> 
> _______________________________________________
> Dots mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dots