Re: [Dots] clarification questions from the hackathon

[kaname nishizuka <[e-mail]>]

Hi,

please see inline.

regards,
Kaname

On 2019/03/29 4:28, [e-mail] wrote:
> Re-,
>
> Please see inline.
>
> Cheers,
> Med
>
>> -----Message d'origine-----
>> De : Jon Shallow [mailto:[e-mail]]
>> Envoyé : jeudi 28 mars 2019 18:05
>> À : BOUCADAIR Mohamed TGI/OLN; kaname nishizuka; [e-mail]
>> Objet : RE: [Dots] clarification questions from the hackathon
>>
>> Hi All,
>>
>> See inline
>>
>> Regards
>>
>> Jon
>>
>>> -----Original Message-----
>>> From: Dots [mailto: [e-mail]] On Behalf Of ietf-
>>> [e-mail]
>>> Sent: 28 March 2019 13:39
>>> To: kaname nishizuka; [e-mail]
>>> Subject: Re: [Dots] clarification questions from the hackathon
>>>
>>> Re-,
>>>
>>> Please see inline.
>>>
>>> Cheers,
>>> Med
>>>
>>>> -----Message d'origine-----
>>>> De : Dots [mailto:[e-mail]] De la part de kaname nishizuka
>>>> Envoyé : jeudi 28 mars 2019 11:38
>>>> À : [e-mail]
>>>> Objet : [Dots] clarification questions from the hackathon
>>>>
>>>> Hi,
>>>>
>>>> I'd like to continue discussion of these topics in the ML.
>>>>
>>>> #1: Questions about signal-control-filtering
>>>>    1. Should a mitigation request create a mitigation before doing a PUT +
>>>> acl-list [{acl-name, activation-type}] against the active mitigation, or
>> is a
>>>> ‘PUT + acl-list [{acl-name, activation-type}]’ allowed to create a new
>>>> mitigation?
>>> [Med] Both are currently allowed in the draft. I don't still a valid reason
>> to
>>> restrict this.
>> [Jon] As per draft
>>     A DOTS client MUST NOT use the filtering control over DOTS signal
>>     channel if no attack (mitigation) is active;
>>
> [Med] What is meant actually is:
>
>     A DOTS client MUST NOT use the filtering control over DOTS signal
>     channel in 'idle' time;
>
> Will update the text.
>
[kaname]
in order to make what I and Jon raised clearer,

    A DOTS client MUST NOT use the filtering control over DOTS signal
    channel in 'idle' time.
    If a mitigation request which includes both valid mitigation scope and acl-*
    for the first time in idle time, it should be treated as it's already in attack time.

Or, simply I'm wondering if it is possible to drop the sentence because acl-* is always accompany with a mitigation scope so there is no way to enable it by itself in idle time?


>> [Jon] then needs to be reworded as there is no active mitigation until the
>> PUT is done...
>> I believe that both cases should be supported.
>>>>    2. Should the response to a GET (or Observed GET) include the acl-list
>>>> [{acl-name, activation-type}] if the PUT included it?
>>> [Med] The current spec says "no". That's said, what would be the value in
>>> returning it? Then, why not allowing to return the references to all ACLs
>> that
>>> are enabled during the mitigation time?
>>>
>> [Jon] When observing the mitigation request, if the activation-type is
>> changed externally, the client will then know about the change. Assuming the
>> response got back to the client, this is effectively an ACK to the fact that
>> the ACL change got through.
> [Med] The observe case makes sense, indeed.
>
>> Interesting concept about knowing about all the relevant ACLs as returned
>> over the signal channel.  More work for the server to do in determining which
>> ACLs are valid for, say, a specific IP address that is being mitigated.  Not
>> entirely convinced of the benefit of this as this generally is available over
>> the data channel.
>>
> [Med] I'm not convinced, either.
>
> _______________________________________________
> Dots mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dots