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

[<[e-mail]>]

Re-,

Please see inline. 

Cheers,
Med

> -----Message d'origine-----
> De : Stephen Farrell [mailto:[e-mail]]
> Envoyé : vendredi 15 mars 2019 11:20
> À : BOUCADAIR Mohamed TGI/OLN; [e-mail]
> Cc : [e-mail]; [e-mail];
> [e-mail]
> Objet : Re: Secdir last call review of draft-ietf-dots-signal-channel-30
> 
> 
> Hiya,
> 
> On 15/03/2019 06:47, [e-mail] 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.