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.
