Re: [Dots] Mirja Kühlewind's Discuss on draft-ietf-dots-requirements-18: (with DISCUSS and COMMENT)

["Mirja Kuehlewind (IETF)" <[e-mail]>]

Hi Tiru,

please see below.

> Am 21.02.2019 um 15:02 schrieb Konda, Tirumaleswar Reddy <[e-mail]>:
> 
>> -----Original Message-----
>> From: Mirja Kuehlewind (IETF) <[e-mail]>
>> Sent: Thursday, February 21, 2019 7:10 PM
>> To: Konda, Tirumaleswar Reddy <[e-mail]>
>> Cc: [e-mail]; Teague, Nik <[e-mail]>;
>> [e-mail]; [e-mail]; [e-mail]; The IESG
>> <[e-mail]>; [e-mail]
>> Subject: Re: [Dots] Mirja Kühlewind's Discuss on draft-ietf-dots-requirements-
>> 18: (with DISCUSS and COMMENT)
>> 
>> 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.
>> 
>> Hi Tiru,
>> 
>> please see below.
>> 
>>> Am 21.02.2019 um 14:03 schrieb Konda, Tirumaleswar Reddy
>> <[e-mail]>:
>>> 
>>>> -----Original Message-----
>>>> From: [e-mail]
>> <[e-mail]>
>>>> Sent: Thursday, February 21, 2019 5:55 PM
>>>> To: Mirja Kuehlewind (IETF) <[e-mail]>; Teague, Nik
>>>> <[e-mail]>
>>>> Cc: [e-mail]; [e-mail]; [e-mail];
>>>> The IESG <[e-mail]>; [e-mail]
>>>> Subject: RE: Re: [Dots] Mirja Kühlewind's Discuss on draft-ietf-dots-
>>>> requirements-18: (with DISCUSS and COMMENT)
>>>> 
>>>> 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 : Mirja Kuehlewind (IETF) [mailto:[e-mail]] Envoyé :
>>>>> jeudi 21 février 2019 12:42 À : Teague, Nik Cc : BOUCADAIR Mohamed
>>>>> TGI/OLN; [e-mail]; [e-mail];
>>>>> [e-mail]; The IESG; draft-ietf-dots- [e-mail]
>>>>> Objet
>>>>> : Re: Re: [Dots] Mirja Kühlewind's Discuss on draft-ietf-dots-
>>>>> requirements-18: (with DISCUSS and COMMENT)
>>>>> 
>>>>> Hi,
>>>>> 
>>>>> please see below.
>>>>> 
>>>>>> Am 21.02.2019 um 12:18 schrieb Teague, Nik <[e-mail]>:
>>>>>> 
>>>>>> Hi,
>>>>>> 
>>>>>> 
>>>>>> On 21 Feb 2019, at 10:58, Mirja Kuehlewind (IETF)
>>>>>> <[e-mail]>
>>>>> wrote:
>>>>>> 
>>>>>>>>> 3) In SIG-006 you say:
>>>>>>>>> "      Due to the higher likelihood of packet loss during a DDoS attack,
>>>>>>>>>  DOTS servers MUST regularly send mitigation status to authorized
>>>>>>>>>  DOTS clients which have requested and been granted mitigation,
>>>>>>>>>  regardless of client requests for mitigation status."
>>>>>>>>> 
>>>>>>>>> Please note that this is only true if a not-reliable transport is used.
>>>>> If a
>>>>>>>>> reliable transport is used, data is received at the application
>>>>>>>>> level
>>>>> without
>>>>>>>>> loss (but maybe some delay) or the connection is terminated (if
>>>>>>>>> loss is
>>>>> too
>>>>>>>>> high to retransmit successfully).
>>>>>>>>> 
>>>>>>>> 
>>>>>>>> [Med] The requirement as worded is OK.
>>>>>>> 
>>>>>>> I disagree, because as I said if a reliable transport is used this
>>>>>>> is not
>>>>> true. Maybe you can adapt this sentence slightly to clarify that you
>>>>> probably had a scenario in mind where an unreliable transport is
>>>>> used
>>>>>> 
>>>>>> The key part here is ‘packet’ vs ‘data’ - packets will be lost on
>>>>>> congested
>>>>> links regardless of data integrity.  This may degrade connection re-
>>>>> establishment with tcp and cause data loss in an unreliable transport.
>>>>> 
>>>>> Yes, packet loss also occurs also with reliable transports and might
>>>>> lead to connection failure. However, I don’t this how this
>>>>> requirement is derived from that effect. If I use a reliable
>>>>> transport and my connection does not fail, I can be sure that the
>>>>> mitigation status information have been received correctly, so why
>>>>> do I need to re-send
>>>> frequently then?
>>>> 
>>>> [Med] The text you quoted is not about "frequent retransmission" but
>>>> about sending updates related to the status of a mitigation in
>>>> progress. The server has to send regular notifications to update the
>>>> client about the status of a mitigation.
>>> 
>>> I have modified the text as follows to address the comment:
>>> 
>>> DOTS server MUST regularly send mitigation status updates to authorized
>> DOTS clients which have requested and been granted mitigation. If unreliable
>> transport is used for the signal channel protocol, due to the higher likelihood of
>> packet loss during a DDoS attack, DOTS server MUST regularly retransmit
>> mitigation status.
>> 
>> Thanks! One wording comment, unless I misunderstood something, I don’t think
>> there is any kind of acknowledgment mechanism when unreliable transport is
>> used. There the use of the word „retransmit“ seems irritating here. Do you
>> maybe want to say something like this:
>> 
>> "DOTS server MUST regularly send mitigation status updates to authorized
>> DOTS clients which have requested and been granted mitigation. If unreliable
>> transport is used for the signal channel protocol, due to the higher likelihood of
>> packet loss during a DDoS attack, DOTS server SHOULD send mitigation status
>> updates more frequently.“
> 
> The updated mitigation status needs to be sent multiple times to increase the likeliness of the message reaching the client, and any specific reason for using SHOULD instead of MUST. I propose the following update: 
> DOTS server MUST regularly send mitigation status updates to authorized DOTS clients which have requested and been granted mitigation. If unreliable transport is used for the signal channel protocol, due to the higher likelihood of packet loss during a DDoS attack, DOTS server MUST send mitigation status multiple times at regular intervals following the data transmission guidelines discussed in Section 3.1.3 of [RFC8085].

I’m in general okay with this. The reason why I used SHOULD is because this requirement is quite „blurry“. You say " MUST send mitigation status multiple times at regular intervals“, however, how often is multiple time and which interval? If you say something like "MUST send mitigation status at least every 10 seconds for at least 3 minutes“ then a MUST would be appropriate, however, otherwise I would actually suggest to not use normative language in this sentence as all (as you already have a normative requirement in the first sentence and therefore this sentence is more additional explanation than a separate requirement). Please also note (again) that RFC8085 recommends to not send such messages more often than every 3 seconds as well as the implementation of exponential back-off.

Mirja



> 
> -Tiru
> 
>> 
>> ?
>> 
>> Mirja
>> 
>> 
>> 
>>> 
>>> -Tiru
>>> 
>>>> 
>>>>> 
>>>>> Mirja
>>>>> 
>>>>> 
>>>>> 
>>> 
>