Tiru, I'm not sure if this is the case Stephen is referring to, but this falls under the generic considerations: High-level DOTS security considerations are documented in [I-D.ietf-dots-requirements] and [I-D.ietf-dots-architecture]. And then I-D.ietf-dots-requirements: To detect compromised DOTS agents, DOTS operators should carefully monitor and audit DOTS agents to detect misbehavior and to deter misuse, while employing current secure network communications best practices to reduce attack surface. Still, a good strategy for an attack to succeed is to not signal the attack! Cheers, Med > -----Message d'origine----- > De : Konda, Tirumaleswar Reddy [mailto:TirumaleswarReddy_Konda@xxxxxxxxxx] > Envoyé : vendredi 15 mars 2019 11:56 > À : BOUCADAIR Mohamed TGI/OLN; Stephen Farrell; secdir@xxxxxxxx > Cc : draft-ietf-dots-signal-channel.all@xxxxxxxx; ietf@xxxxxxxx; > dots@xxxxxxxx > Objet : RE: 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@xxxxxxxx> On Behalf Of > > mohamed.boucadair@xxxxxxxxxx > > Sent: Friday, March 15, 2019 4:15 PM > > To: Stephen Farrell <stephen.farrell@xxxxxxxxx>; secdir@xxxxxxxx > > Cc: draft-ietf-dots-signal-channel.all@xxxxxxxx; ietf@xxxxxxxx; > dots@xxxxxxxx > > 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@xxxxxxxxx] > > > Envoyé : vendredi 15 mars 2019 11:20 > > > À : BOUCADAIR Mohamed TGI/OLN; secdir@xxxxxxxx Cc : > > > draft-ietf-dots-signal-channel.all@xxxxxxxx; ietf@xxxxxxxx; > > > dots@xxxxxxxx Objet : Re: Secdir last call review of > > > draft-ietf-dots-signal-channel-30 > > > > > > > > > Hiya, > > > > > > On 15/03/2019 06:47, mohamed.boucadair@xxxxxxxxxx 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@xxxxxxxx > > https://www.ietf.org/mailman/listinfo/dots
