Re: [Dots] Secdir last call review of draft-ietf-dots-signal-channel-30

Hi Med,

Stephen is referring to an attack where a compromised DOTS client initiates mitigation request for a target resource that is attacked and learns the mitigation efficacy of the DOTS server, informs the mitigation efficacy to DDoS attacker to change the DDoS attack strategy.  

We can add the following lines to address his comment:

A compromised DOTS client can collude with a DDoS attacker to send mitigation request for a target resource, learns the mitigation efficacy from the DOTS server, and conveys the efficacy to the DDoS attacker to learn the mitigation capabilities of the DDoS mitigation and to possibly change the DDoS attack strategy. This attack can be prevented by auditing the behavior of DOTS clients and authorizing the DOTS client to request mitigation for specific target resources.

Cheers,
-Tiru

> -----Original Message-----
> From: Dots <dots-bounces@ietf.org> On Behalf Of
> mohamed.boucadair@orange.com
> Sent: Friday, March 15, 2019 4:15 PM
> To: Stephen Farrell <stephen.farrell@cs.tcd.ie>; secdir@ietf.org
> Cc: draft-ietf-dots-signal-channel.all@ietf.org; ietf@ietf.org; dots@ietf.org
> Subject: Re: [Dots] Secdir last call review of draft-ietf-dots-signal-channel-30
> 
> 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.
> 
> Re-,
> 
> Please see inline.
> 
> Cheers,
> Med
> 
> > -----Message d'origine-----
> > De : Stephen Farrell [mailto:stephen.farrell@cs.tcd.ie]
> > Envoyé : vendredi 15 mars 2019 11:20
> > À : BOUCADAIR Mohamed TGI/OLN; secdir@ietf.org Cc :
> > draft-ietf-dots-signal-channel.all@ietf.org; ietf@ietf.org;
> > dots@ietf.org Objet : Re: Secdir last call review of
> > draft-ietf-dots-signal-channel-30
> >
> >
> > Hiya,
> >
> > On 15/03/2019 06:47, mohamed.boucadair@orange.com wrote:
> > >> ISTM that all clients can get information about how an attack is
> > >> being seen at other clients, isn't that right?
> > > [Med] No. A client can only get information that is bound to it.
> > Where does the spec say that? I don't recall the term "bound"
> > used that way but may have missed it.
> >
> 
> [Med] The specification says:
> 
>    If a DOTS client is entitled to solicit the DOTS service, the DOTS
>    server enables mitigation on behalf of the DOTS client by
>    communicating the DOTS client's request to a mitigator (which may be
>    colocated with the DOTS server) and relaying the feedback of the
>    thus-selected mitigator to the requesting DOTS client.
>                            ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ And
> 
>    'cuid' is a mandatory Uri-Path parameter for GET requests.
> 
> 
> > And it still seems a bit hard to enforce. If two clients (one ok, one
> > zombied) ask the same server/network how many packets targetted at
> > 10.0.0/24 were dropped won't they get the same answer? (Assuming both
> > clients are within that /24.)
> 
> [Med] Attack status information is bound to a DOTS client as shown in the
> YANG tree module:
> 
>            +--:(mitigation-scope)
>            |  +--rw scope* [cuid mid]
>            |     +--rw cdid?                   string
>            |     +--rw cuid                    string
>            |     +--rw mid                     uint32
>                 ...
>            |     +--ro status?                 iana-signal:status
>                 ...
>            |     +--ro bytes-dropped?          yang:zero-based-counter64
>            |     +--ro bps-dropped?            yang:zero-based-counter64
>            |     +--ro pkts-dropped?           yang:zero-based-counter64
>            |     +--ro pps-dropped?            yang:zero-based-counter64
>            |     +--rw attack-status?          iana-signal:attack-status
> 
> * If client 1 asked for mitigation for 10.0.0/24, then only that client can access
> to attack status information.
> * If another client 2 asks for mitigation for the same prefix, the server applies a
> conflict handling procedure and decides which request to maintain as active.
> Only one mitigation for a given scope can be maintained. Only that selected
> client can access to the attack status information.
> 
> _______________________________________________
> Dots mailing list
> Dots@ietf.org
> https://www.ietf.org/mailman/listinfo/dots