Re: [Dots] (draft-ietf-dots-signal-filter-control) ACL Stats issue

[<[e-mail]>]

Re-,

Why it would be useful to share stats for ACLs activated via the signal channel but not for (pre-installed) ACLs that are automatically activated during mitigations?

Cheers,
Med

> -----Message d'origine-----
> De : Konda, Tirumaleswar Reddy [mailto:[e-mail]]
> Envoyé : jeudi 25 avril 2019 16:13
> À : BOUCADAIR Mohamed TGI/OLN; Jon Shallow; 'kaname nishizuka'; [e-mail]
> Objet : RE: [Dots] (draft-ietf-dots-signal-filter-control) ACL Stats issue
> 
> > -----Original Message-----
> > From: [e-mail]
> > <[e-mail]>
> > Sent: Thursday, April 25, 2019 5:37 PM
> > To: Konda, Tirumaleswar Reddy
> > <[e-mail]>; Jon Shallow <supjps-
> > [e-mail]>; 'kaname nishizuka' <[e-mail]>;
> > [e-mail]
> > Subject: RE: [Dots] (draft-ietf-dots-signal-filter-control) ACL Stats issue
> >
> >
> >
> > Tiru,
> >
> > Even if we assume that ACL-specific stats can be communicated via the
> signal
> > channel (which we don't have an agreement on it so far), this is not
> specific
> > to the filter-control spec but the same reasoning would apply for all ACLs
> > instructed by the DOTS client (not only those that are adjusted during
> attack
> > times).
> 
> My point is, If the ACL is activated using the signal channel, since the ACL
> is part of the mitigation request, only the activated ACL stats needs to be
> conveyed in the mitigation status.  Other ACLs activated using data channel
> are not part of mitigation request,
> so no need to convey their stats using the signal channel.
> 
> -Tiru
> 
> >
> > Cheers,
> > Med
> >
> > > -----Message d'origine-----
> > > De : Konda, Tirumaleswar Reddy
> > > [mailto:[e-mail]]
> > > Envoyé : jeudi 25 avril 2019 13:04
> > > À : Jon Shallow; 'kaname nishizuka'; BOUCADAIR Mohamed TGI/OLN;
> > > [e-mail] Objet : RE: [Dots]
> > > (draft-ietf-dots-signal-filter-control) ACL Stats issue
> > >
> > > > -----Original Message-----
> > > > From: Dots <[e-mail]> On Behalf Of Jon Shallow
> > > > Sent: Thursday, April 25, 2019 2:58 PM
> > > > To: 'kaname nishizuka' <[e-mail]>;
> > > > [e-mail]; [e-mail]
> > > > Subject: Re: [Dots] (draft-ietf-dots-signal-filter-control) ACL
> > > > Stats issue
> > > >
> > > > This email originated from outside of the organization. Do not click
> > > > links
> > > or
> > > > open attachments unless you recognize the sender and know the
> > > > content is safe.
> > > >
> > > > Hi there,
> > > >
> > > > The advantage of separating out the counters for the different ACLs
> > > > is that the DOTS client can then determine what is being effective or
> not.
> > > However,
> > > > if (signal) data is able to get from the DOTS server to the DOTS
> > > > client,
> > > then it
> > > > is likely that the data channel will still be operable and can be
> > > > used to
> > > get
> > > > these numbers so I still do not think that this should be over the
> > > > signal channel.
> > > >
> > > > I think that that the GET response (or observe response) bytes-dropped
> > etc.
> > > > should be the total dropped - i.e. the sum of the ACls and what the
> > > > DMS is otherwise doing as it refers to the mitigation request.
> > >
> > > If the DOTS server knows the traffic dropped by ACLs and the traffic
> > > dropped by DMS, why can't it provide this statistics separately
> > > instead of summing it.  If the incoming link is saturated, data
> > > channel will not function  but signal channel (using UDP) will work
> > > and there is a good possibility that one of the GET responses
> > > periodically sent will reach the client (As you already know, DOTS signal
> > channel is tolerant to high packet loss in one direction).
> > >
> > > -Tiru
> > >
> > > >
> > > > Regards
> > > >
> > > > Jon
> > > >
> > > > > -----Original Message-----
> > > > > From: Dots [mailto: [e-mail]] On Behalf Of kaname
> > > > > nishizuka
> > > > > Sent: 25 April 2019 10:00
> > > > > To: [e-mail]; [e-mail]
> > > > > Subject: Re: [Dots] (draft-ietf-dots-signal-filter-control) ACL
> > > > > Stats issue
> > > > >
> > > > > Hi Med, all,
> > > > >
> > > > > Regarding with the issue, I'm not convinced of the benefit to
> > > > > return the activated ACL statistics over signal-channel.
> > > > >
> > > > > The idea of this draft is based on this situation (quoted from
> > > > > Jon's
> > > > > comment):
> > > > > (It is) very unreliable when the inbound pipe is running full.  If
> > > > > the pipe is not running full, then this information can be
> > > > > obtained over the
> > > data
> > > > channel.
> > > > >
> > > > > ACL stats can be get over the data-channel. I don't see any reason
> > > > > to reproduce the same function.
> > > > >
> > > > > Further more, I don't think the DOTS server should notify that
> > > > > DOTS client with the change by including the corresponding acl-*
> > > > > parameters in an asynchronous notification.
> > > > > The basic behavior is already written in the draft:
> > > > >     This specification does not require any modification to the
> efficacy
> > > > >     update and the withdrawal procedures defined in
> > > > >     [I-D.ietf-dots-signal-channel].  In particular, ACL-related
> clauses
> > > > >     are not included in a PUT request used to send an efficacy update
> and
> > > > >     DELETE requests.
> > > > >
> > > > > If so, the server need not to store any resource about acl-* per
> > > > > mitigation request, which make the function of the
> > > > > signal-filter-control
> > > > simple enough.
> > > > >
> > > > > thanks,
> > > > > Kaname
> > > > >
> > > > > On 2019/04/24 15:24, [e-mail] wrote:
> > > > > > Hi all,
> > > > > >
> > > > > > We do have one pending issue to be resolved for this draft. The
> > > > > > issue is
> > > > > available at:
> > > > > > https://github.com/boucadair/filter-control/issues/1
> > > > > >
> > > > > > We need your feedback on this.
> > > > > >
> > > > > > Cheers,
> > > > > > Med
> > > > > >
> > > > > >> -----Message d'origine-----
> > > > > >> De : Dots [mailto:[e-mail]] De la part de
> > > > > >> internet- [e-mail] Envoyé : mercredi 24 avril 2019 07:34 À
> :
> > > > > >> [e-mail] Cc : [e-mail] Objet : [Dots] I-D
> Action:
> > > > > >> draft-ietf-dots-signal-filter-control-00.txt
> > > > > >>
> > > > > >>
> > > > > >> A New Internet-Draft is available from the on-line
> > > > > >> Internet-Drafts directories.
> > > > > >> This draft is a work item of the DDoS Open Threat Signaling WG
> > > > > >> of the
> > > > > IETF.
> > > > > >>
> > > > > >>          Title           : Controlling Filtering Rules Using
> > > Distributed
> > > > > >> Denial-of-Service Open Threat Signaling (DOTS) Signal Channel
> > > > > >>          Authors         : Kaname Nishizuka
> > > > > >>                            Mohamed Boucadair
> > > > > >>                            Tirumaleswar Reddy
> > > > > >>                            Takahiko Nagata
> > > > > >> 	Filename        : draft-ietf-dots-signal-filter-control-00.txt
> > > > > >> 	Pages           : 23
> > > > > >> 	Date            : 2019-04-23
> > > > > >>
> > > > > >> Abstract:
> > > > > >>     This document specifies an extension to the DOTS signal
> channel
> > so
> > > > > >>     that DOTS clients can control their filtering rules when an
> attack
> > > > > >>     mitigation is active.
> > > > > >>
> > > > > >>     Particularly, this extension allows a DOTS client to
> > > > > >> activate or
> > > de-
> > > > > >>     activate existing filtering rules during a DDoS attack.  The
> > > > > >>     characterization of these filtering rules is supposed to be
> > > conveyed
> > > > > >>     by a DOTS client during an idle time by means of the DOTS data
> > > > > >>     channel protocol.
> > > > > >>
> > > > > >> 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 Distributed
> > > Denial-
> > > > > >>        of-Service Open Threat Signaling (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-ietf-dots-signal-filter-
> > > > > >> cont
> > > > > >> rol/
> > > > > >>
> > > > > >> There are also htmlized versions available at:
> > > > > >> https://tools.ietf.org/html/draft-ietf-dots-signal-filter-contr
> > > > > >> ol-0
> > > > > >> 0
> > > > > >> https://datatracker.ietf.org/doc/html/draft-ietf-dots-signal-fi
> > > > > >> lter
> > > > > >> -control-
> > > > > >> 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/
> > > > > >>
> > > > > >> _______________________________________________
> > > > > >> Dots mailing list
> > > > > >> [e-mail]
> > > > > >> https://www.ietf.org/mailman/listinfo/dots
> > > > > > _______________________________________________
> > > > > > Dots mailing list
> > > > > > [e-mail]
> > > > > > https://www.ietf.org/mailman/listinfo/dots
> > > > >
> > > > > _______________________________________________
> > > > > Dots mailing list
> > > > > [e-mail]
> > > > > https://www.ietf.org/mailman/listinfo/dots
> > > >
> > > > _______________________________________________
> > > > Dots mailing list
> > > > [e-mail]
> > > > https://www.ietf.org/mailman/listinfo/dots