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

["Tirumaleswar Reddy (tireddy)" <[e-mail]>]

Hi Kaname,

Please see inline

> -----Original Message-----
> From: kaname nishizuka [mailto:[e-mail]]
> Sent: Thursday, August 18, 2016 3:32 PM
> To: Tirumaleswar Reddy (tireddy) <[e-mail]>; [e-mail]
> Subject: Re: [Dots] FW: New Version Notification for draft-reddy-dots-
> transport-05.txt
> 
> Hi Tiru,
> 
> 
> On 2016/08/08 15:46, Tirumaleswar Reddy (tireddy) wrote:
> > 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.
> OK, That's great.
> 
> > Please see inline
> >
> >> -----Original Message-----
> >> From: kaname nishizuka [mailto:[e-mail]]
> >> Sent: Friday, July 22, 2016 12:22 PM
> >> To: Tirumaleswar Reddy (tireddy) <[e-mail]>; [e-mail]
> >> 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 ?
> 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.

Okay, but it may not be possible to setup and exchange bulk-data using DOTS data channel during a DDOS 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 ?
> 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.

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.
> > 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.
> 
> >>        - 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.
> 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

> 
> 
> >> 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.
> Okay, I'll see that.
> 
> regards,
> kaname
> 
> > -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: [e-mail] [mailto:[e-mail]]
> >>> 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
> >>> [e-mail]
> >>> https://www.ietf.org/mailman/listinfo/dots