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

From: "Tirumaleswar Reddy (tireddy)" <[email-masked]>
Date: Wed, 6 Jul 2016 07:46:44 +0000

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

---

From: Jérôme François <[email-masked]>
Date: Wed, 06 Jul 2016 16:26:36 +0200

Thanks Tiru,

You introduce an AAA server in the DOTS gateway domain but it is not
clear for me whether this is also the case at the DOTS server side.
I would say yes, especially needed if there is no gateway.

BTW, would it be better to locate the AAA server and communication
outside example.com domain, to have the lower overhead close to where
the attack occurs?

Jérôme

Le 06/07/2016 09:46, Tirumaleswar Reddy (tireddy) a écrit :
> _______________________________________________
> Dots mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dots

---

From: "Tirumaleswar Reddy (tireddy)" <[email-masked]>
Date: Fri, 15 Jul 2016 03:09:07 +0000

> From: Dots [mailto:[email-masked]] On Behalf Of Jérôme François
> Sent: Wednesday, July 06, 2016 7:57 PM
> To: [email-masked]
> Subject: Re: [Dots] FW: New Version Notification for draft-reddy-dots-
> transport-05.txt
> 
> Thanks Tiru,
> 
> You introduce an AAA server in the DOTS gateway domain but it is not clear
> for me whether this is also the case at the DOTS server side.

AAA server may or may not be required on the DOTS server side, DOTS server in the access network needs to be provisioned with the certificate of the DOTS gateway and knows the prefixes assigned to DOTS gateway domain. However DOTS server in the cloud may need to use RPKI or other mechanisms to identify if the DOTS gateway domain owns the prefixes/addresses advertised in the DOTS signal for DDOS attack mitigation. Please see updated draft-ietf-dots-architecture-00 on authorization discussion.
 
> I would say yes, especially needed if there is no gateway.

Yes. 

> 
> BTW, would it be better to locate the AAA server and communication outside
> example.com domain, to have the lower overhead close to where the attack
> occurs ?

Location of the AAA server is outside the scope of the this document because it is a deployment decision. The figure only illustrates the fact that the DOTS gateway reaches out to a AAA server for an authorization verdict

-Tiru

> > 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
> >
> > To: Prashanth Patil (praspati); Dan Wing (dwing); Mike Geller
> > (mgeller); Robert Moskowitz; Mohamed Boucadair; Tirumaleswar Reddy
> > (tireddy)
> > 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.
> >
> > 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
> >

---

From: kaname nishizuka <[email-masked]>
Date: Fri, 22 Jul 2016 08:52:08 +0200

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

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.
      - if a service is working only on port 80, traffic destined to other port can be dropped without any consideration.
  * this type of filtering may be installed in pre-provisioning phase (on data channel)
       - can be changed even while it is under attack

  Also there should be a limitation on a request
  * requests from DOTS clients should be limited
      - request for blocking, rate-limiting, etc.. can be another attack vector if the request is 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)

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

2. filtering instruction for mitigation
  * filtering of traffic is one of protection methods taken by mitigators
  * DOTS client can request filtering of traffic with desired action (blocking, rate-limiting...)
  * instructed while it is under attack (on signaling channel)

Data model of Filtering Rules described in section 6 (DOTS Data Channel) looks like type 2 of filtering.
So I think it looks like for signaling channel.

best regards,
kaname nishizuka