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

From: "Tirumaleswar Reddy (tireddy)" <[email-masked]>
Date: Mon, 8 Aug 2016 06:46:07 +0000

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:[email-masked]]
> Sent: Friday, July 22, 2016 12:22 PM
> To: Tirumaleswar Reddy (tireddy) <[email-masked]>; [email-masked]
> 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: [email-masked] [mailto:[email-masked]]
> > 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
> > [email-masked]
> > https://www.ietf.org/mailman/listinfo/dots

---

From: kaname nishizuka <[email-masked]>
Date: Thu, 18 Aug 2016 19:02:02 +0900

Hi Tiru,

> 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 attrib…
OK, That's great.

> What is the use case for changing these type of filters during the attack ?
One, human make mistakes.
Two, white-list type of filtering rule could need to be more specific in order to filter out the attack more precisely.

> It's an implementation detail, what do you suggest needs to be discussed in this draft ?
OK, it's an implementation detail.
I just wanted to point out that the DOTS server should not accept all of the filtering request from the DOTS client without checking the CIDR block of the DOTS clients' domain.

> DOTS client has to authenticate to the DOTS server, how will DOTS requests be spoofed ?
As described above, the DOTS client can spoof the prefixes of filtering request (not the DOTS client's address itself) in order to block traffic not to its domain but to other organization.

> I did not get the above line, please clarify.
It was meant to say that "The range of target (=IP addresses/prefixes) in the requests from DOTS clients should be checked by DOTS server. It is independent of the protection methods the DOTS server will take."

> I will update the draft to clarify, currently the draft is only high-lighting the example of black-list rules provisioned during an attack.
Okay, I'll see that.

regards,
kaname

---

From: "Tirumaleswar Reddy (tireddy)" <[email-masked]>
Date: Thu, 18 Aug 2016 10:40:39 +0000

Hi Kaname,

Please see inline

> Sent: Thursday, August 18, 2016 3:32 PM
> > 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.
> OK, That's great.
> 
> > Please see inline
> >
> >> Subject: Re: [Dots] FW: New Version Notification for
> >> draft-reddy-dots- transport-05.txt
> >>
> >> Hi Tiru,
> >>
> >>        - 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.

Okay, but it may not be possible to setup and exchange bulk-data using DOTS data channel during a DDOS attack.

> I just wanted to point out that the DOTS server should not accept all of the
> filtering request from the DOTS client without checking the CIDR block of the
> DOTS clients' domain.

Yes, the mechanism for enforcement is not in the scope of this doc. DOTS servers can use pre-provisioning as part of the configuration for the customer or can also use dynamic mechanisms like RPKI.
It's already covered in the architecture doc (https://tools.ietf.org/html/draft-ietf-dots-architecture-00#section-2.2.2). 

> 
> >>        - request for blocking, rate-limiting, etc.. can be another
> >> attack vector if the request is spoofed.
> As described above, the DOTS client can spoof the prefixes of filtering request
> (not the DOTS client's address itself) in order to block traffic not to its domain
> but to other organization.
> 
> >>        - limitation on possible range of target (=IP
> >> addresses/prefixes) should be pre-defined per customer basis.
> It was meant to say that "The range of target (=IP addresses/prefixes) in the
> requests from DOTS clients should be checked by DOTS server. It is
> independent of the protection methods the DOTS server will take."

Got it.

Cheers,
-Tiru

> >> Data model of Filtering Rules described in section 6 (DOTS Data
> >> Channel) looks like type 2 of filtering.
> > I will update the draft to clarify, currently the draft is only high-lighting the
> example of black-list rules provisioned during an attack.
> Okay, I'll see that.
> 
> regards,
> kaname
> 
> > -Tiru
> >
> >>> Added new section
> >>> https://tools.ietf.org/html/draft-reddy-dots-transport-