Re: [Dots] FW: New Version Notification for draft-reddy-dots-transport-05.txt

Hi Kaname,

Yes, DOTS data channel should also cover pre-provisioning. As per our discussion at IETF, will remove DOTS channel from this draft, and create a new draft and pick specific sections and JSON attributes from draft-nishizuka-dots-inter-domain-mechanism and include pre-provisioning. 

Please see inline

> -----Original Message-----
> From: kaname nishizuka [mailto:kaname@nttv6.jp]
> Sent: Friday, July 22, 2016 12:22 PM
> To: Tirumaleswar Reddy (tireddy) <tireddy@cisco.com>; dots@ietf.org
> Subject: Re: [Dots] FW: New Version Notification for draft-reddy-dots-
> transport-05.txt
> 
> Hi Tiru,
> 
> I have a comment on section 6.  DOTS Data Channel.
> 
>   * Data channel is for bulk data exchanges
>   * Rough Consensus @ Design Team Meeting: Data channel is for pre-
> provisioning

Yup.

> 
> I think we need 2 types of filtering.
> 1. filtering which limit the scope of mitigation
>   * example
>       - if an organization have other sites from which only legitimate traffic in
> coming and is afraid of false positive, the sites should be treated as a
> exception of mitigation with white-list.

Yes, white-list rules can also be created using the DOTS data channel discussed in the draft (see traffic-rate attribute defined in DOTS data channel). 

>       - if a service is working only on port 80, traffic destined to other port can
> be dropped without any consideration.

Yes, the above rule can also be provisioned during peacetime using the DOTS data channel proposed in the draft.

>   * this type of filtering may be installed in pre-provisioning phase (on data
> channel)
>        - can be changed even while it is under attack

What is the use case for changing these type of filters during the attack ?

> 
>   Also there should be a limitation on a request
>   * requests from DOTS clients should be limited

It's an implementation detail, what do you suggest needs to be discussed in this draft ?

>       - request for blocking, rate-limiting, etc.. can be another attack vector if the
> request is spoofed.

DOTS client has to authenticate to the DOTS server, how will DOTS requests be spoofed ?

>       - limitation on possible range of target (=IP addresses/prefixes) should be
> pre-defined per customer basis.
>       - installed in pre-provisioning phase (on data channel)

Agreed.

> 
>   [note]:this filtering is required without regard to protection methods

I did not get the above line, please clarify.

> 
> 2. filtering instruction for mitigation
>   * filtering of traffic is one of protection methods taken by mitigators

Okay.

>   * DOTS client can request filtering of traffic with desired action (blocking,
> rate-limiting...)
>   * instructed while it is under attack (on signaling channel)

DOTS signaling channel does not signal filtering rules, it's the job of DOTS data channel.

> 
> Data model of Filtering Rules described in section 6 (DOTS Data Channel)
> looks like type 2 of filtering.

No, Filtering rules can be provisioned either before or during the attack.
I will update the draft to clarify, currently the draft is only high-lighting the example of black-list rules provisioned during an attack.

-Tiru

> So I think it looks like for signaling channel.
> 
> 
> best regards,
> kaname nishizuka
> 
> 
> On 2016/07/06 9:46, Tirumaleswar Reddy (tireddy) wrote:
> > Added new section https://tools.ietf.org/html/draft-reddy-dots-transport-
> 05#section-8 to discuss about mutual authentication of DOTS Agents &
> authorization of DOTS clients. Comments and suggestions are welcome.
> >
> > Cheers,
> > -Tiru
> >
> > -----Original Message-----
> > From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org]
> > Sent: Wednesday, July 06, 2016 1:04 PM
> > To: Prashanth Patil (praspati); Dan Wing (dwing); Mike Geller
> > (mgeller); Robert Moskowitz; Mohamed Boucadair; Tirumaleswar Reddy
> > (tireddy)
> > Subject: New Version Notification for
> > draft-reddy-dots-transport-05.txt
> >
> >
> > A new version of I-D, draft-reddy-dots-transport-05.txt has been
> > successfully submitted by Tirumaleswar Reddy and posted to the IETF
> > repository.
> >
> > Name:		draft-reddy-dots-transport
> > Revision:	05
> > Title:		Co-operative DDoS Mitigation
> > Document date:	2016-07-06
> > Group:		Individual Submission
> > Pages:		26
> > URL:            https://www.ietf.org/internet-drafts/draft-reddy-dots-transport-
> 05.txt
> > Status:         https://datatracker.ietf.org/doc/draft-reddy-dots-transport/
> > Htmlized:       https://tools.ietf.org/html/draft-reddy-dots-transport-05
> > Diff:           https://www.ietf.org/rfcdiff?url2=draft-reddy-dots-transport-05
> >
> > Abstract:
> >     This document specifies a mechanism that a DOTS client can use to
> >     signal that a network is under a Distributed Denial-of-Service (DDoS)
> >     attack to an upstream DOTS server so that appropriate mitigation
> >     actions are undertaken (including, blackhole, drop, rate-limit, or
> >     add to watch list) on the suspect traffic.  The document specifies
> >     both DOTS signal and data channels.  Happy Eyeballs considerations
> >     for the DOTS signal channel are also elaborated.
> >
> >
> >
> >
> > 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
> >
> > _______________________________________________
> > Dots mailing list
> > Dots@ietf.org
> > https://www.ietf.org/mailman/listinfo/dots