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

From: "Mirja Kuehlewind (IETF)" <[email-masked]>
Date: Tue, 5 Mar 2019 12:31:32 +0100

Hi Tiru,

thanks, the proposed text works well for me!

Mirja

> Am 21.02.2019 um 15:58 schrieb Konda, Tirumaleswar Reddy <[email-masked]>:
> 
>> -----Original Message-----
>> From: [email-masked] <[email-masked]>
>> Sent: Thursday, February 21, 2019 8:10 PM
>> To: Mirja Kuehlewind (IETF) <[email-masked]>
>> Cc: [email-masked]; [email-masked]; [email-masked]; The IESG
>> <[email-masked]>; [email-masked]
>> 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.
>> 
>> Re-,
>> 
>> My point is that combining RFC8085 and deployments where timers can be
>> controlled/discovered is sufficient to fulfill the requirement.
>> 
>> Of course, this does not guarantee that bindings are kept active if a NAT/FW
>> assigns timers of less than 15 seconds...which is fair. The requirement does not
>> ask for such guarantee.
> 
> Agreed, I propose the following update to capture the discussion and addresses the comment:
> 
> Channel Health Monitoring: DOTS agents MUST support exchange of heartbeat messages over the signal channel to monitor channel health. These keepalives serve the purpose to maintain any on-path NAT or Firewall bindings to avoid cryptographic handshake for new mitigation requests. The heartbeat interval during active mitigation could be negotiable based on NAT/Firewall characteristics. Absent information about the NAT/Firewall characteristics, DOTS agent needs to ensure its on-path NAT or Firewall bindings do not expire, by using the keep-alive frequency discussed in Section 3.5 of [RFC8085].
> 
> Cheers
> -Tiru
> 
>> 
>> Cheers,
>> Med
>> 
>>> -----Message d'origine-----
>>> De : Mirja Kuehlewind (IETF) [mailto:[email-masked]] Envoyé :
>>> jeudi 21 février 2019 14:46 À : BOUCADAIR Mohamed TGI/OLN Cc :
>>> [email-masked]; [email-masked]; [email-masked]; The
>>> IESG; [email-masked]
>>> Objet : Re: [Dots] Mirja Kühlewind's Discuss on
>>> draft-ietf-dots-requirements-
>>> 18: (with DISCUSS and COMMENT)
>>> 
>>> Hi Med,
>>> 
>>> please see below.
>>> 
>>>> Am 21.02.2019 um 13:17 schrieb [email-masked]:
>>>> 
>>>>>>> 2) Also on this text in SIG-004:
>>>>>>> "The heartbeat interval during active mitigation could be
>>>>>>>    negotiable, but MUST be frequent enough to maintain any on-path
>>>>>>>    NAT or Firewall bindings during mitigation.  When TCP is used as
>>>>>>>    transport, the DOTS signal channel heartbeat messages need to be
>>>>>>>    frequent enough to maintain the TCP connection state."
>>>>>>> 
>>>>>>> As Joe commented already, different heartbeats at different
>>>>>>> layers can
>>> be
>>>>>>> used
>>>>>>> at the same time for different purposes. You can use heartbeats
>>>>>>> at the application layer to check service availability while e.g.
>>>>>>> using a
>>> higher
>>>>>>> frequent heartbeat at the transport layer to maintain firewall
>>>>>>> and NAT
>>>>> state.
>>>>>> 
>>>>>> [Med] Please note that the text you quoted is about "during active
>>>>> mitigation". When no attack is ongoing, we do have the following
>>>>> behavior which covers your comment:
>>>>>> 
>>>>>>    When DOTS agents are exchanging heartbeats and no
>>>>>>    mitigation request is active, either agent MAY request changes to
>>>>>>    the heartbeat rate.  For example, a DOTS server might want to
>>>>>>                         ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>>>>>>    reduce heartbeat frequency or cease heartbeat exchanges when an
>>>>>> 
>> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>>>>>>    active DOTS client has not requested mitigation, in order to
>>>>>>    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>>>>>>    control load.
>>>>>> 
>>>>>>> The advantage to such an approach is that there is less
>>>>>>> application
>>> layer
>>>>>>> overhead/load e.g. in scenarios where it might be expensive to
>>>>>>> wake up
>>> the
>>>>>>> application or a server is already highly loaded. Also note that
>>>>>>> the
>>>>> time-
>>>>>>> outs
>>>>>>> values of NATs and firewalls on the path are usually unknown,
>>>>>>> therefore
>>> an
>>>>>>> application can never rely on heartbeats (no matter at which
>>>>>>> level) and
>>>>> must
>>>>>>> be
>>>>>>> prepared to try to reconnect on the application layer if the
>>>>>>> connection fails.
>>>>>>> Usually, the main reason for using heartbeats to maintain NAT or
>>> firewall
>>>>>>> state
>>>>>>> (vs. reconnect every time) in TCP is if the application is time-
>>> sensitive
>>>>> and
>>>>>>> a
>>>>>>> full TCP handshake takes too long for the desired service. I'm
>>>>>>> not sure
>>>>> that
>>>>>>> the case for DOTS, however, I understand it may be beneficial to
>>>>>>> have established state if an attack is on-going.
>>>>>> 
>>>>>> [Med] This is important to avoid new handshakes when the client
>>>>>> has to
>>>>> request a mitigation.
>>>>> 
>>>>> This is okay but could be spelled out more explicitly as a
>>>>> requirement, rather than taking about the details of sending heartbeats.
>>>>>> 
>>>>>>> 
>>>>>>> For UDP I guess it's more complicated in your case. Time-outs are
>>> usually
>>>>>>> very
>>>>>>> short, however, state is created with the first packet of a flow
>>>>>>> (as
>>> there
>>>>> is
>>>>>>> no handshake in UDP). As you don't see blocking if state is
>>>>>>> expired as
>>> new
>>>>>>> state is created immediately, it's kind of impossible to measure
>>>>>>> the configured time-out values. Only if the firewall is under
>>>>>>> attack it would start
>>>>> blocking
>>>>>>> UDP traffic that is has no state for yet. So I understand why it
>>>>>>> is
>>>>> desirable
>>>>>>> to maintain UDP state for you, however, I don't understand how
>>>>>>> you can
>>>>> know
>>>>>>> that your frequency is high enough to actually keep the state
>>>>>>> open. Note
>>>>> that
>>>>>>> TCP time-outs are usually in the order of hours, while UDP
>>>>>>> time-outs are usually in range of tens of seconds, and might
>>>>>>> expire even quicker if a system is under attack. If that is a
>>>>>>> scenario that is important for you, and assuming that not all
>>>>>>> time-outs values on the path can be known, I guess it would
>>>>> be
>>>>>>> recommendable to use TCP instead.
>>>>>>> 
>>>>>>> In any case this can not be a MUST requirement (as timers are
>>>>>>> usually
>>> not
>>>>>>> known). I would recommend to state something like:
>>>>>>> 
>>>>>>> "MAY be frequent enough to maintain NAT or firewall state, if
>>>>>>> timer
>>> values
>>>>>>> are
>>>>>>> known, or if TCP is used, SHOULD use in addition TCP heartbeats
>>>>>>> to
>>>>> maintain
>>>>>>> the TCP connection state and reconnect immediately if a failure
>>>>>>> is
>>>>> detected."
>>>>>>> 
>>>>>> 
>>>>>> [Med] The original wording is accurate and reflects the
>>>>>> requirement of
>>> the
>>>>> WG. How this will be enforced is part of the solution/specification space.
>>>>> 
>>>>> My hold point here is that
>>>>> 
>>>>> "MUST be frequent enough to maintain any on-path NAT or Firewall
>>>>> bindings during mitigation.“
>>>>> 
>>>>> cannot be a MUST requirement as the network time-out values are not
>>>>> known
>>> by
>>>>> the endpoints. Therefore it is impossible to fulfill this requirement.
>>>> 
>>>> [Med] Two comments here:
>>>> * The requirement can be fulfilled by relying RFC8085
>>>> recommendations. This
>>> is discussed in the spec documents.
>>> 
>>> RFC8085 provide recommended value and limits, however, this does not
>>> guarantee that the proposed values actually match the time-out values
>>> as deployed on the path.
>>> 
>>>> * there are deployments in which timers can be discovered (e.g., PCP
>>> (RFC6887)).
>>> 
>>> This does not work in all cases and the draft does not seem to require
>>> the usage of anything like this. If a requirement is that the timeout
>>> values MUST be known in the deployed scenario, then that should be
>>> spelled out, however, I assume that is not your intention because that
>>> would limit deployment heavily.
>>> 
>>> Mirja
>>> 
>

---

From: "Mirja Kuehlewind (IETF)" <[email-masked]>
Date: Tue, 5 Mar 2019 12:38:35 +0100

Hi Tiru, hi Med,

to catch up on this comment.

> Am 21.02.2019 um 15:23 schrieb Konda, Tirumaleswar Reddy <[email-masked]>:
> 
>>>> One editorial comment on SEC-002:
>>>> 
>>>> "A security mechanism at the network layer (e.g.,
>>>>     TLS) is thus adequate to provide hop-by-hop security.  In other
>>>>     words, end-to-end security is not required for DOTS protocols."
>>>> 
>>>> TLS is transport layer security (not network layer) and therefore
>>>> known as providing end-to-end security while the term hop-by-hop is used
>> for e.g.
>>>> IPSec.
>>>> 
>>>> I would recommend to change the wording here in order to avoid
>>>> confusion, e.g.
>>>> 
>>>> "A security mechanism at the transport layer (e.g.,
>>>>     TLS) is thus adequate to provide security between different DOTS
>>>> agents.
>>>>     In other words, a direct security association between the server and
>>>>     client, excluding any proxy, is not required for DOTS protocols."
>>>> 
>>> 
>>> [Med] I disagree with the last part of the proposed wording. The DOTS
>> architecture involves gateways, hence the hop-by-hop security model.
>> 
>> This is not a technical comment. The technical content is correct. However, as I
>> said above, the term hop-by-hop is associated by many people in the
>> community with something like IPSec, while application layer gateways are
>> rather considered as endpoints. All I'm requesting is to avoid the terms end-to-
>> end and hop-by-hop in this context as it might be confusing to others.
> 
> 
> SEC-002 is modified in version 18 to add more details to address the following comment from Robert Sparks (Genart review) :
> from Paragraph 3 of SEC-002: This paragraph doesn't read as sensibly when you have the pictures of aggregating gateways from the architecture document in mind.
> Does it constrain the types of connections that can be aggregated to those that share equivalent security properties? If so, it should be explicit.

So, there are to point here:

1) With the current text there is at least one mistake. It says

"A security mechanism at the network layer (e.g. TLS)…“

However, TLS is at actually at the application layer. So this needs rewording.

2) The other part of my comment was simply that the use of the term „end-to-end“ and "hop-by-hop“ could be confusing as currently used (without much explanation). I suggest initially to simply not use these term, however, you could also say something like „hop-by-hop between an DOTS gateway and a DOTS client or sever“ and end-to-end directly between the DOTS client and server“, just to be very clear about this.

Mirja

---

From: "Mirja Kuehlewind (IETF)" <[email-masked]>
Date: Tue, 5 Mar 2019 12:46:35 +0100

Hi Tiru,

please see below.

> Am 21.02.2019 um 15:02 schrieb Konda, Tirumaleswar Reddy <[email-masked]>:
> 
>> From: Mirja Kuehlewind (IETF) <[email-masked]>
>> Sent: Thursday, February 21, 2019 7:10 PM
>> To: Konda, Tirumaleswar Reddy <[email-masked]>
>> Cc: [email-masked]; Teague, Nik <[email-masked]>;
>> [email-masked]; [email-masked]; [email-masked]; The IESG
>> Subject: Re: [Dots] Mirja Kühlewind's Discuss on draft-ietf-dots-requirements-
>>> Am 21.02.2019 um 14:03 schrieb Konda, Tirumaleswar Reddy
>> <[email-masked]>:
>>> 
>>>> Sent: Thursday, February 21, 2019 5:55 PM
>>>> To: Mirja Kuehlewind (IETF) <[email-masked]>; Teague, Nik
>>>> <[email-masked]>
>>>> Cc: [email-masked]; [email-masked]; [email-masked];
>>>> The IESG <[email-masked]>; [email-masked]
>>>> 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
>>>> 
>>>>> jeudi 21 février 2019 12:42 À : Teague, Nik Cc : BOUCADAIR Mohamed
>>>>> TGI/OLN; [email-masked]; [email-masked];
>>>>> [email-masked]; The IESG; draft-ietf-dots- [email-masked]
>>>>> 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 <[email-masked]>:
>>>>>> 
>>>>>> Hi,
>>>>>> 
>>>>>> 
>>>>>> On 21 Feb 2019, at 10:58, Mirja Kuehlewind (IETF)
>>>>>> <[email-masked]>
>>>>> 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

>> ?

---

From: <[email-masked]>
Date: Tue, 5 Mar 2019 12:13:08 +0000

Hi Mirja, 

This was fixed in -19. The new text says the following: 

OLD:

A security mechanism at the network layer (e.g.,
      TLS) is thus adequate to provide hop-by-hop security.  In other
      words, end-to-end security is not required for DOTS protocols.

NEW:

A security mechanism at the
      transport layer (e.g., TLS) is thus adequate to provide security
      between peer DOTS agents.

Cheers,
Med

> De : Mirja Kuehlewind (IETF) [mailto:[email-masked]]
> Envoyé : mardi 5 mars 2019 12:39
> À : Konda, Tirumaleswar Reddy
> Cc : BOUCADAIR Mohamed TGI/OLN; [email-masked];
> [email-masked]; [email-masked]; The IESG; draft-ietf-dots-
> [email-masked]
> Objet : Re: [Dots] Mirja Kühlewind's Discuss on draft-ietf-dots-requirements-
> > SEC-002 is modified in version 18 to add more details to address the
> following comment from Robert Sparks (Genart review) :
> > from Paragraph 3 of SEC-002: This paragraph doesn't read as sensibly when
> you have the pictures of aggregating gateways from the architecture document
> in mind.
> > Does it constrain the types of connections that can be aggregated to those
> that share equivalent security properties? If so, it should be explicit.
> 
> 
> 2) The other part of my comment was simply that the use of the term „end-to-
> end“ and "hop-by-hop“ could be confusing as currently used (without much
> explanation). I suggest initially to simply not use these term, however, you
> could also say something like „hop-by-hop between an DOTS gateway and a DOTS
> client or sever“ and end-to-end directly between the DOTS client and server“,
> just to be very clear about this.
> 
> Mirja
>

---

From: "Konda, Tirumaleswar Reddy" <[email-masked]>
Date: Tue, 5 Mar 2019 12:46:59 +0000

> Sent: Tuesday, March 5, 2019 5:02 PM
> Cc: [email-masked]; [email-masked];
> [email-masked]; [email-masked];
> [email-masked]; The IESG <[email-masked]>

Updated draft is published addressing the DISCUSS and comments from ISEG members.

Cheers,
-Tiru

> >> My point is that combining RFC8085 and deployments where timers can
> >> be controlled/discovered is sufficient to fulfill the requirement.
> >>
> >> Of course, this does not guarantee that bindings are kept active if a
> >> NAT/FW assigns timers of less than 15 seconds...which is fair. The
> >> requirement does not ask for such guarantee.
> >
> > Channel Health Monitoring: DOTS agents MUST support exchange of
> heartbeat messages over the signal channel to monitor channel health. These
> keepalives serve the purpose to maintain any on-path NAT or Firewall bindings
> to avoid cryptographic handshake for new mitigation requests. The heartbeat
> interval during active mitigation could be negotiable based on NAT/Firewall
> characteristics. Absent information about the NAT/Firewall characteristics,
> DOTS agent needs to ensure its on-path NAT or Firewall bindings do not expire,
> by using the keep-alive frequency discussed in Section 3.5 of [RFC8085].
> >
> > Cheers
> > -Tiru
> >
> >>
> >> Cheers,
> >> Med
> >>
> >>>>> cannot be a MUST requirement as the network time-out values are
> >>>>> not known
> >>> by
> >>> guarantee that the proposed values actually match the time-out
> >>> values as deployed on the path.
> >>>
> >>> This does not work in all cases and the draft does not seem to
> >>> require the usage of anything like this. If a requirement is that
> >>> the timeout values MUST be known in the deployed scenario, then that
> >>> should be spelled out, however, I assume that is not your intention
> >>> because that would limit deployment heavily.
> >>>
> >>> Mirja
> >>>
> >

---

From: "Konda, Tirumaleswar Reddy" <[email-masked]>
Date: Tue, 5 Mar 2019 13:14:35 +0000

> Sent: Tuesday, March 5, 2019 5:17 PM
> Cc: [email-masked]; Teague, Nik <[email-masked]>;
> [email-masked]; The IESG <[email-masked]>; [email-masked];
> [email-masked]; [email-masked]
> >> IESG <[email-masked]>; [email-masked]
> >>>> 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
> >>>>
> >>>>>>>>>  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."
> >>>>>>>>>
> >>>>>>>>> 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
> >>>>>>> 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
> >>>>>>
> >>>>> 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
> >>>> [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.
> >>>
> >> 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:
> 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,

The transmission behavior is discussed in detail in the signal channel draft, it follows the recommendations in RFC8085. 

> 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.

I have already published revised draft using the above text. If you insist, I can update the draft to say:

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 needs to send mitigation status
 multiple times at regular intervals following the data transmission guidelines
 discussed in Section 3.1.3 of [RFC8085].

Cheers,
-Tiru

---

From: "Mirja Kuehlewind (IETF)" <[email-masked]>
Date: Tue, 5 Mar 2019 15:33:29 +0100

Thanks!

> Am 05.03.2019 um 13:13 schrieb <[email-masked]> <[email-masked]>:
> 
> Hi Mirja, 
>