Subject: [Dots] Signal Channel WGLC: Trigger-Mitigation

From: "Jon Shallow" <[email-masked]>
Date: Thu, 2 Aug 2018 15:32:31 +0100

Hi there

https://github.com/boucadair/draft-ietf-dots-signal-channel/blob/master/wdif
f%20draft-ietf-dots-signal-channel-21.txt%20draft-ietf-dots-signal-channel-2
2.pdf has the trigger-mitigation moved to mitigation configuration from the
channel configuration as discussed on the mailing list.

When doing a PUT mitigation refresh, 

4.4.1 Request Mitigation

.

For a mitigation request to continue beyond the initial negotiated lifetime,
the DOTS client has to refresh the current mitigation request by sending a
new PUT request. This PUT request MUST use the same 'mid' value, and MUST
repeat all the other parameters as sent in the original mitigation request
apart from a possible change to the lifetime parameter value.

4.4.2 Retrieve Information Related to a Mitigation

Are we allowed to change trigger-mitigation value for the refresh PUT?

- we allow for a change in lifetime

Also, when doing the efficacy update PUT do the same rules apply for
trigger-mitigation?

Is an efficacy update to be treated as a refresh as well - I think it is?

Regards

Jon

---

From: "Konda, Tirumaleswar Reddy" <[email-masked]>
Date: Thu, 2 Aug 2018 14:40:43 +0000

Please see inline [TR]

From: Dots <[email-masked]> On Behalf Of Jon Shallow
Sent: Thursday, August 2, 2018 8:03 PM
To: [email-masked]
Subject: [Dots] Signal Channel WGLC: Trigger-Mitigation

CAUTION: External email. Do not click links or open attachments unless you recognize the sender and know the content is safe.

________________________________
Hi there

https://github.com/boucadair/draft-ietf-dots-signal-channel/blob/master/wdiff%20draft-ietf-dots-signal-channel-21.txt%20draft-ietf-dots-signal-channel-22.pdf has the trigger-mitigation moved to mitigation configuration from the channel configuration as discussed on the mailing list.

4.4.1 Request Mitigation
…
For a mitigation request to continue beyond the initial negotiated lifetime, the DOTS client has to refresh the current mitigation request by sending a new PUT request. This PUT request MUST use the same 'mid' value, and MUST repeat all the other parameters as sent in the original mitigation request apart from a possible change to the lifetime parameter value.
4.4.2 Retrieve Information Related to a Mitigation

[TR] No.

Also, when doing the efficacy update PUT do the same rules apply for trigger-mitigation?

[TR] Yes.

Is an efficacy update to be treated as a refresh as well – I think it is?

[TR] Yup.

-Tiru

Regards

Jon

---

From: kaname nishizuka <[email-masked]>
Date: Fri, 3 Aug 2018 09:55:38 +0900

Hi,

I support the change of the trigger-mitigation to mitigation configuration from the channel configuration.
Then I'd like to add one question about the trigger-mitigation.

A pre-configured scope would be like this (because it can't predict which IP address will be targeted).
"target-prefix": [ "192.0.2.0/24 ] "trigger-mitigation": false

When a DDoS attack happened to one of IP addresses, the client will do PUT with a higher "mid" value.
"target-prefix": [ "192.0.2.1/32 ] "trigger-mitigation": true

Will it take over the previous pre-configured scope?
If so, what status will be returned to the previous pre-configured mitigation request?
If not, which conflict-status will be returned to the current request?

regards,
Kaname

On 2018/08/02 23:40, Konda, Tirumaleswar Reddy wrote:
>
> Please see inline [TR]
>
> *From:*Dots <[email-masked]> *On Behalf Of *Jon Shallow
> *Sent:* Thursday, August 2, 2018 8:03 PM
> *To:* [email-masked]
> *Subject:* [Dots] Signal Channel WGLC: Trigger-Mitigation
>
> *CAUTION*:External email. Do not click links or open attachments unless you recognize the sender and know the content is safe.
>
> ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
>
> Hi there
>
> _______________________________________________
> Dots mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dots

---

From: <[email-masked]>
Date: Fri, 3 Aug 2018 05:51:41 +0000

Hi Kaname,

Please see inline.

Cheers,
Med

De : Dots [mailto:[email-masked]] De la part de kaname nishizuka
Envoyé : vendredi 3 août 2018 02:56
À : Konda, Tirumaleswar Reddy; Jon Shallow; [email-masked]
Objet : Re: [Dots] Signal Channel WGLC: Trigger-Mitigation

Hi,

When a DDoS attack happened to one of IP addresses, the client will do PUT with a higher "mid" value.
"target-prefix": [ "192.0.2.1/32 ] "trigger-mitigation": true
[Med] Or ‘trigger-mitigation’ may be omitted in the new request.

Will it take over the previous pre-configured scope?
[Med] Yes, because this text applies:

“If two
   mitigation requests have overlapping mitigation scopes, the
   mitigation request with the highest numeric 'mid' value will override

   the other mitigation request. Two mitigation requests from a DOTS
   client are overlapping if there is a common IP address, IP prefix,
   FQDN, URI, or alias-name.”

If so, what status will be returned to the previous pre-configured mitigation request?
[Med] The status is not a function of the mitigation type. 7 can be returned.
If not, which conflict-status will be returned to the current request?
[Med] conflict-status is used for handling conflicts among distinct DOTS clients.

regards,
Kaname

From: Dots <[email-masked]><mailto:[email-masked]> On Behalf Of Jon Shallow
Sent: Thursday, August 2, 2018 8:03 PM
To: [email-masked]<mailto:[email-masked]>
Subject: [Dots] Signal Channel WGLC: Trigger-Mitigation

4.4.1 Request Mitigation
…

[TR] No.

[TR] Yes.

[TR] Yup.

-Tiru

Regards

Jon

Dots mailing list

[email-masked]<mailto:[email-masked]>

---

From: "Konda, Tirumaleswar Reddy" <[email-masked]>
Date: Fri, 3 Aug 2018 06:16:43 +0000

Hi Kaname,

Please see inline [TR]

From: Dots <[email-masked]> On Behalf Of kaname nishizuka
Sent: Friday, August 3, 2018 6:26 AM
To: Konda, Tirumaleswar Reddy <[email-masked]>; Jon Shallow <[email-masked]>; [email-masked]
Subject: Re: [Dots] Signal Channel WGLC: Trigger-Mitigation

Will it take over the previous pre-configured scope?
[TR] Pre-configured scope will only be triggered when the DOTS signal channel session is lost.
If so, what status will be returned to the previous pre-configured mitigation request?
[TR] We have added mitigation status ‘8’ in the draft (https://github.com/boucadair/draft-ietf-dots-signal-channel/blob/master/wdiff%20draft-ietf-dots-signal-channel-21.txt%20draft-ietf-dots-signal-channel-22.pdf).
If not, which conflict-status will be returned to the current request?
[TR] "target-prefix": [ "192.0.2.1/32 ] will result in an immediate attack mitigation. When the DOTS signal channel is lost, mitigation for "target-prefix": [ "192.0.2.0/24 ] will be started and conflict-status code ‘1’ and 'status' code set to '7 (Attack mitigation is withdrawn)'  will be returned for the mitigation request with "target-prefix": [ "192.0.2.1/32 ].  We will have to update the draft to make it more clear.
-Tiru

regards,
Kaname

4.4.1 Request Mitigation
…

[TR] No.

[TR] Yes.

[TR] Yup.

-Tiru

Regards

Jon

Dots mailing list

---

From: "Konda, Tirumaleswar Reddy" <[email-masked]>
Date: Fri, 3 Aug 2018 06:31:54 +0000

Hi Med,

The pre-configured scope will typically have a larger scope (e.g.. "target-prefix": [ "192.0.2.0/24 ]) to protect the entire target network. When a DDoS attack is detected by the DOTS client, mitigation will be requested for the specific resource in the target network (e.g. target-prefix": [ "192.0.2.1/32 ]).  In this example the correct behavior would be, "target-prefix": [ "192.0.2.1/32 ] will result in an immediate attack mitigation and when the DOTS signal channel is lost, mitigation for pre-configured scope "target-prefix": [ "192.0.2.0/24 ] will be started and conflict-status code ‘1’ and 'status' code set to '7 (Attack mitigation is withdrawn)' will be returned for the mitigation request with "target-prefix": [ "192.0.2.1/32 ].

We may want to consider updating the draft to say conflict-status is also applicable for conflicts from the same client, and the higher numeric ‘mid’ will only over-ride the lower-numeric ‘mid’ only if both mitigation requests have the same ‘trigger-mitigation’ parameter value.

-Tiru

From: [email-masked] <[email-masked]>
Sent: Friday, August 3, 2018 11:22 AM
To: kaname nishizuka <[email-masked]>; Konda, Tirumaleswar Reddy <[email-masked]>; Jon Shallow <[email-masked]>; [email-masked]
Subject: RE: [Dots] Signal Channel WGLC: Trigger-Mitigation

Please see inline.

Cheers,
Med

De : Dots [mailto:[email-masked]] De la part de kaname nishizuka
Envoyé : vendredi 3 août 2018 02:56
À : Konda, Tirumaleswar Reddy; Jon Shallow; [email-masked]<mailto:[email-masked]>
Objet : Re: [Dots] Signal Channel WGLC: Trigger-Mitigation

Hi,

“If two

regards,
Kaname

4.4.1 Request Mitigation
…

[TR] No.

[TR] Yes.

[TR] Yup.

-Tiru

Regards

Jon

Dots mailing list

---

From: <[email-masked]>
Date: Fri, 3 Aug 2018 06:41:41 +0000

Tiru,

I’m for maintaining the sale rules without considering the type of the mitigation. As such, the same rule applies for handling requests with overlapping scope is this one:

“If two

In the example provided by Kaname, the client decides on purpose to adjust the scope once an attack is ongoing (while the client installed a pre-configured one). Applying the rule above would be straightforward.

If the client does want to maintain the one with the wider scope, then it has not to send the new one given that the pre-configured mitigation will be triggered when an attack is detected.

Likewise, a client can decide to increase the scope. The same rules apply as well.

Cheers,
Med

De : Konda, Tirumaleswar Reddy [mailto:[email-masked]]
Envoyé : vendredi 3 août 2018 08:32
À : BOUCADAIR Mohamed IMT/OLN; kaname nishizuka; Jon Shallow; [email-masked]
Objet : RE: [Dots] Signal Channel WGLC: Trigger-Mitigation

Hi Med,

-Tiru

Please see inline.

Cheers,
Med

Hi,

“If two

regards,
Kaname

4.4.1 Request Mitigation
…

[TR] No.

[TR] Yes.

[TR] Yup.

-Tiru

Regards

Jon

Dots mailing list

---

From: "Konda, Tirumaleswar Reddy" <[email-masked]>
Date: Fri, 3 Aug 2018 07:35:48 +0000

Hi Med,

Please see inline

From: [email-masked]<mailto:[email-masked]> <[email-masked]<mailto:[email-masked]>>
Sent: Friday, August 3, 2018 12:12 PM
To: Konda, Tirumaleswar Reddy <[email-masked]<mailto:[email-masked]>>; kaname nishizuka <[email-masked]<mailto:[email-masked]>>; Jon Shallow <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: RE: [Dots] Signal Channel WGLC: Trigger-Mitigation

“If two

[TR] The pre-configured mitigation scope will only be triggered when the DOTS signal channel session is lost. The problem is the pre-configured scope will be overridden by a specific scope during an attack, and if attack evolves to target other resources or the entire domain, and the signal channel session is connection is lost because of a volumetric attack, the DOTS client cannot convey the new target details, and the use of pre-configured scope is nullified.

-Tiru

Cheers,
Med

De : Konda, Tirumaleswar Reddy [mailto:[email-masked]]
Envoyé : vendredi 3 août 2018 08:32
À : BOUCADAIR Mohamed IMT/OLN; kaname nishizuka; Jon Shallow; [email-masked]<mailto:[email-masked]>
Objet : RE: [Dots] Signal Channel WGLC: Trigger-Mitigation

Hi Med,

-Tiru

From: [email-masked]<mailto:[email-masked]> <[email-masked]<mailto:[email-masked]>>
Sent: Friday, August 3, 2018 11:22 AM
To: kaname nishizuka <[email-masked]<mailto:[email-masked]>>; Konda, Tirumaleswar Reddy <[email-masked]<mailto:[email-masked]>>; Jon Shallow <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: RE: [Dots] Signal Channel WGLC: Trigger-Mitigation

Please see inline.

Cheers,
Med

Hi,

“If two

regards,
Kaname

4.4.1 Request Mitigation
…

[TR] No.

[TR] Yes.

[TR] Yup.

-Tiru

Regards

Jon

Dots mailing list

---

From: "Jon Shallow" <[email-masked]>
Date: Fri, 3 Aug 2018 08:39:24 +0100

For clarity, the text quoted by Med goes on to state

To avoid maintaining a long list of

   overlapping mitigation requests from a DOTS client and avoid error-

   prone provisioning of mitigation requests from a DOTS client, the

   overlapped lower numeric 'mid' MUST be automatically deleted and no

   longer available at the DOTS server.

So with the current draft’s definition, the [192.0.2.0/24] trigger-mitigation:false mitigation request will get deleted as Med indicates by the new [192.0.2.1/32]trigger-mitigation:true (higher mid) mitigation request.  Once [192.0.2.1/32] is removed, [192.0.2.0/24] will not be in place unless re-requested by the client.

However, the question posed by Tiru about the override (and hence delete) if trigger-mitigation is different is an interesting one and does make some usability/configurability sense to me – there is a back-stop mitigation, but it is easy to be more prescriptive if needed.

A suggested change

Old

Two mitigation requests from a DOTS

   FQDN, URI, or alias-name.  To avoid

New

Two mitigation requests from a DOTS

   FQDN, URI, or alias-name and the same trigger-mitigation type.  To avoid

Regards

Jon

From: Dots [mailto: [email-masked]] On Behalf Of [email-masked]
Sent: 03 August 2018 07:42
To: Konda, Tirumaleswar Reddy; kaname nishizuka; Jon Shallow; [email-masked]
Subject: Re: [Dots] Signal Channel WGLC: Trigger-Mitigation

Tiru,

“If two

Cheers,

Med

Hi Med,

-Tiru

  _____  

Hi Kaname,

Please see inline.

Cheers,

Med

Hi,

“If two

regards,
Kaname

Please see inline [TR]

From: Dots  <mailto:[email-masked]> <[email-masked]> On Behalf Of Jon Shallow
Sent: Thursday, August 2, 2018 8:03 PM
To: [email-masked]
Subject: [Dots] Signal Channel WGLC: Trigger-Mitigation

  _____  

Hi there

4.4.1 Request Mitigation

…

[TR] No. 

[TR] Yes.

[TR] Yup.

-Tiru

Regards

Jon

---

From: <[email-masked]>
Date: Fri, 3 Aug 2018 07:56:21 +0000

Re-,

We may adopt two approaches:

·         Apply the same rules for all mitigations (as it is currently in the draft): the new request will win and therefore the pre-configured one will be deleted. The client can reinstall a new request with the pre-configured scope later if it needs so. This one is simple and allows for a unified behavior at the server side. When an attack is ongoing, the type of the request does not matter that much.

·         Allow for a distinct behavior as a function of the mitigation type: this one requires a modification to the DOTS server. When an attack is ongoing, the server will maintain active two requests with overlapping scopes. It has to manage both of them simultaneously (state tracking, state change notifications, etc.). Is there any value in having this load compared to the previous one?

Cheers,
Med

De : Konda, Tirumaleswar Reddy [mailto:[email-masked]]
Envoyé : vendredi 3 août 2018 09:36
À : BOUCADAIR Mohamed IMT/OLN; kaname nishizuka; Jon Shallow; [email-masked]
Objet : RE: [Dots] Signal Channel WGLC: Trigger-Mitigation

Hi Med,

Please see inline

“If two

-Tiru

Cheers,
Med

Hi Med,

-Tiru

Please see inline.

Cheers,
Med

Hi,

“If two

regards,
Kaname

4.4.1 Request Mitigation
…

[TR] No.

[TR] Yes.

[TR] Yup.

-Tiru

Regards

Jon

Dots mailing list

---

From: <[email-masked]>
Date: Fri, 3 Aug 2018 08:07:19 +0000

Re-,

Inline.

Cheers,
Med

De : Jon Shallow [mailto:[email-masked]]
Envoyé : vendredi 3 août 2018 09:39
À : BOUCADAIR Mohamed IMT/OLN; Konda, Tirumaleswar Reddy; kaname nishizuka; [email-masked]
Objet : RE: [Dots] Signal Channel WGLC: Trigger-Mitigation

[Med] Exactly.

[Med] The question is whether there is a value in allowing for such extra load at the server side given that the current draft allows for the following:
* A client can always change the scope (restrict, increase) if needed.
* A client can decide to re-install a request with a pre-configured scope (identical or different compared to the old one).
* A client can maintain the same scope; that is only the request with a pre-configured scope is active during an attack.

A suggested change
Old

Regards

Jon

Tiru,

“If two

Cheers,
Med

Hi Med,

-Tiru

Please see inline.

Cheers,
Med

Hi,

“If two

regards,
Kaname

4.4.1 Request Mitigation
…

[TR] No.

[TR] Yes.

[TR] Yup.

-Tiru

Regards

Jon

Dots mailing list

---

From: "Jon Shallow" <[email-masked]>
Date: Fri, 3 Aug 2018 10:00:05 +0100

Hi,

See inline.

Regards

Jon

From: Dots [mailto: [email-masked]] On Behalf Of [email-masked]
Sent: 03 August 2018 08:56
To: Konda, Tirumaleswar Reddy; kaname nishizuka; Jon Shallow; [email-masked]
Subject: Re: [Dots] Signal Channel WGLC: Trigger-Mitigation

Re-,

Jon> If the attack is against [192.0.2.1/32], the client requests mitigate [192.0.2.1/32], [192.0.2.0/24] gets deleted and then the attack morphs to 192.0.2.2/32 which kills the pipe – then out of band to DOTS server provider communication is required – not so good. 

Jon> The DOTS server (and DOTS mitigator) implementation is pretty straight forward, as is the double accounting.  The client should not see double the mitigated traffic volumes as traffic will only be hitting one of the rules.

Jon> This extra loading will only happen if the [192.0.2.0/24] is invoked due to signal loss.

Jon> I think that I prefer that if [192.0.2.1/32] is requested, and this overlaps with an auto-invoked, currently active [192.0.2.0/24], that the specific [192.0.2.1/32] is mitigated, but [192.0.2.0/24] goes back to state 8 (waiting for signal channel loss) so that if the attack does morph to another IP and kills the signal channel, then [192.0.2.0/24] will again go active.

Jon> In other words, there is an extra reason to go to state 8 for [192.0.2.0/24] – namely there is a new overlapping PUT request that is trigger-mitigation:true.

~Jon

Cheers,

Med

Hi Med,

Please see inline

From: [email-masked] <[email-masked]> 
Sent: Friday, August 3, 2018 12:12 PM
To: Konda, Tirumaleswar Reddy <[email-masked]>; kaname nishizuka <[email-masked]>; Jon Shallow <[email-masked]>; [email-masked]
Subject: RE: [Dots] Signal Channel WGLC: Trigger-Mitigation

  _____  

Tiru,

“If two

-Tiru

Cheers,

Med

De : Konda, Tirumaleswar Reddy [ <mailto:[email-masked]> mailto:[email-masked]] 
Envoyé : vendredi 3 août 2018 08:32
À : BOUCADAIR Mohamed IMT/OLN; kaname nishizuka; Jon Shallow;  <mailto:[email-masked]> [email-masked]
Objet : RE: [Dots] Signal Channel WGLC: Trigger-Mitigation

Hi Med,

-Tiru

From:  <mailto:[email-masked]> [email-masked] < <mailto:[email-masked]> [email-masked]> 
Sent: Friday, August 3, 2018 11:22 AM
To: kaname nishizuka < <mailto:[email-masked]> [email-masked]>; Konda, Tirumaleswar Reddy < <mailto:[email-masked]> [email-masked]>; Jon Shallow < <mailto:[email-masked]> [email-masked]>;  <mailto:[email-masked]> [email-masked]
Subject: RE: [Dots] Signal Channel WGLC: Trigger-Mitigation

  _____  

Hi Kaname,

Please see inline.

Cheers,

Med

De : Dots [ <mailto:[email-masked]> mailto:[email-masked]] De la part de kaname nishizuka
Envoyé : vendredi 3 août 2018 02:56
À : Konda, Tirumaleswar Reddy; Jon Shallow;  <mailto:[email-masked]> [email-masked]
Objet : Re: [Dots] Signal Channel WGLC: Trigger-Mitigation

Hi,

“If two

regards,
Kaname

Please see inline [TR]

From: Dots  <mailto:[email-masked]> <[email-masked]> On Behalf Of Jon Shallow
Sent: Thursday, August 2, 2018 8:03 PM
To:  <mailto:[email-masked]> [email-masked]
Subject: [Dots] Signal Channel WGLC: Trigger-Mitigation

  _____  

Hi there

 <https://github.com/boucadair/draft-ietf-dots-signal-channel/blob/master/wdiff%20draft-ietf-dots-signal-channel-21.txt%20draft-ietf-dots-signal-channel-22.pdf> https://github.com/boucadair/draft-ietf-dots-signal-channel/blob/master/wdiff%20draft-ietf-dots-signal-channel-21.txt%20draft-ietf-dots-signal-channel-22.pdf has the trigger-mitigation moved to mitigation configuration from the channel configuration as discussed on the mailing list.

4.4.1 Request Mitigation

…

[TR] No. 

[TR] Yes.

[TR] Yup.

-Tiru

Regards

Jon

_______________________________________________
Dots mailing list
 <mailto:[email-masked]> [email-masked]
 <https://www.ietf.org/mailman/listinfo/dots> https://www.ietf.org/mailman/listinfo/dots

---

From: <[email-masked]>
Date: Fri, 3 Aug 2018 09:26:17 +0000

Re-,

Good point.

I made this change :

OLD:
   The relative order of two mitigation requests from a DOTS client is
   determined by comparing their respective 'mid' values.  If two
   mitigation requests have overlapping mitigation scopes, the
   mitigation request with the highest numeric 'mid' value will override
   the other mitigation request.  Two mitigation requests from a DOTS
   client are overlapping if there is a common IP address, IP prefix,
   FQDN, URI, or alias-name.  To avoid maintaining a long list of
   overlapping mitigation requests from a DOTS client and avoid error-
   prone provisioning of mitigation requests from a DOTS client, the
   overlapped lower numeric 'mid' MUST be automatically deleted and no
   longer available at the DOTS server.

NEW:
   The relative order of two mitigation requests from a DOTS client is
   determined by comparing their respective 'mid' values.  If two
   mitigation requests with the same 'trigger-mitigation' type have
                       ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
   overlapping mitigation scopes, the mitigation request with the
   highest numeric 'mid' value will override the other mitigation
   request.  Two mitigation requests from a DOTS client are overlapping
   if there is a common IP address, IP prefix, FQDN, URI, or alias-name
   and the same 'trigger-mitigation' type.  To avoid maintaining a long
   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
   list of overlapping mitigation requests from a DOTS client and avoid
   error-prone provisioning of mitigation requests from a DOTS client,
   the overlapped lower numeric 'mid' MUST be automatically deleted and
   no longer available at the DOTS server.

Do we need to say more?

Cheers,
Med

De : Jon Shallow [mailto:[email-masked]]
Envoyé : vendredi 3 août 2018 11:00
À : BOUCADAIR Mohamed IMT/OLN; Konda, Tirumaleswar Reddy; kaname nishizuka; [email-masked]
Objet : RE: [Dots] Signal Channel WGLC: Trigger-Mitigation

Hi,

See inline.

Regards

Jon

Re-,

~Jon

Cheers,
Med

Hi Med,

Please see inline

“If two

-Tiru

Cheers,
Med

Hi Med,

-Tiru

Please see inline.

Cheers,
Med

Hi,

“If two

regards,
Kaname

4.4.1 Request Mitigation
…

[TR] No.

[TR] Yes.

[TR] Yup.

-Tiru

Regards

Jon

Dots mailing list

---

From: "Konda, Tirumaleswar Reddy" <[email-masked]>
Date: Fri, 3 Aug 2018 09:34:55 +0000

Hi Med,

Looks good. We will also have to fix the text related to conflict (i.e. conflict information will be returned for mitigation requests with overlapping scope from the same DOTS client but with different ‘trigger-mitigation’ types).

-Tiru

From: [email-masked] <[email-masked]>
Sent: Friday, August 3, 2018 2:56 PM
To: Jon Shallow <[email-masked]>; Konda, Tirumaleswar Reddy <[email-masked]>; kaname nishizuka <[email-masked]>; [email-masked]
Subject: RE: [Dots] Signal Channel WGLC: Trigger-Mitigation

Good point.

I made this change :

OLD:

NEW:

Do we need to say more?

Cheers,
Med

De : Jon Shallow [mailto:[email-masked]]
Envoyé : vendredi 3 août 2018 11:00
À : BOUCADAIR Mohamed IMT/OLN; Konda, Tirumaleswar Reddy; kaname nishizuka; [email-masked]<mailto:[email-masked]>
Objet : RE: [Dots] Signal Channel WGLC: Trigger-Mitigation

Hi,

See inline.

Regards

Jon

From: Dots [mailto: [email-masked]<mailto:[email-masked]>] On Behalf Of [email-masked]<mailto:[email-masked]>
Sent: 03 August 2018 08:56
To: Konda, Tirumaleswar Reddy; kaname nishizuka; Jon Shallow; [email-masked]<mailto:[email-masked]>
Subject: Re: [Dots] Signal Channel WGLC: Trigger-Mitigation

Re-,

  *   Apply the same rules for all mitigations (as it is currently in the draft): the new request will win and therefore the pre-configured one will be deleted. The client can reinstall a new request with the pre-configured scope later if it needs so. This one is simple and allows for a unified behavior at the server side. When an attack is ongoing, the type of the request does not matter that much.
Jon> If the attack is against [192.0.2.1/32], the client requests mitigate [192.0.2.1/32], [192.0.2.0/24] gets deleted and then the attack morphs to 192.0.2.2/32 which kills the pipe – then out of band to DOTS server provider communication is required – not so good.

  *   Allow for a distinct behavior as a function of the mitigation type: this one requires a modification to the DOTS server. When an attack is ongoing, the server will maintain active two requests with overlapping scopes. It has to manage both of them simultaneously (state tracking, state change notifications, etc.). Is there any value in having this load compared to the previous one?
Jon> The DOTS server (and DOTS mitigator) implementation is pretty straight forward, as is the double accounting.  The client should not see double the mitigated traffic volumes as traffic will only be hitting one of the rules.
Jon> This extra loading will only happen if the [192.0.2.0/24] is invoked due to signal loss.

~Jon

Cheers,
Med

Hi Med,

Please see inline

“If two

-Tiru

Cheers,
Med

Hi Med,

-Tiru

Please see inline.

Cheers,
Med

Hi,

“If two

regards,
Kaname

4.4.1 Request Mitigation
…

[TR] No.

[TR] Yes.

[TR] Yup.

-Tiru

Regards

Jon

Dots mailing list

---

From: "Jon Shallow" <[email-masked]>
Date: Fri, 3 Aug 2018 10:53:27 +0100

Hi,

See inline responses to both Tiru and Med – Jon1>

Regards

Jon

From: Dots [mailto: [email-masked]] On Behalf Of Konda, Tirumaleswar Reddy
Sent: 03 August 2018 10:35
To: [email-masked]; Jon Shallow; kaname nishizuka; [email-masked]
Subject: Re: [Dots] Signal Channel WGLC: Trigger-Mitigation

Hi Med,

Jon1> Hmm – Conflict with new [192.0.2.1/32] with [192.0.2.0/24] which is currently not active – need an equivalent 2 conflict-status for the same client.  Is this really a conflict?

-Tiru

  _____  

Re-,

Good point. 

I made this change : 

OLD:

NEW:

Jon1> Not sure we need this change as well as the previous one.

Do we need to say more?

Jon1> I would like to see added:-

If the two mitigation requests are not the same ‘trigger-mitigation’ type, but are otherwise overlapping, then the mitigation request that has ‘trigger-mitigation’ set to false SHOULD be set back to state 8 if not already at state 8.

~Jon1

Cheers,

Med

Hi,

See inline.

Regards

Jon

Re-,

~Jon

Cheers,

Med

Hi Med,

Please see inline

  _____  

Tiru,

“If two

-Tiru

Cheers,

Med

Hi Med,

-Tiru

  _____  

Hi Kaname,

Please see inline.

Cheers,

Med

Hi,

“If two

regards,
Kaname

Please see inline [TR]

  _____  

Hi there

4.4.1 Request Mitigation

…

[TR] No. 

[TR] Yes.

[TR] Yup.

-Tiru

Regards

Jon

---

From: "Konda, Tirumaleswar Reddy" <[email-masked]>
Date: Fri, 3 Aug 2018 10:53:57 +0000

Hi Jon,

No, I meant "target-prefix": [ "192.0.2.1/32 ] will result in an immediate attack mitigation (no conflict is returned for "target-prefix": [ "192.0.2.0/24 ]) but when the DOTS signal channel is lost, mitigation for "target-prefix": [ "192.0.2.0/24 ] will be started and conflict-status code ‘1’ and 'status' code set to '7 (Attack mitigation is withdrawn)'  will be returned for the mitigation request with "target-prefix": [ "192.0.2.1/32 ].

-Tiru

From: Dots <[email-masked]> On Behalf Of Jon Shallow
Sent: Friday, August 3, 2018 3:23 PM
To: Konda, Tirumaleswar Reddy <[email-masked]>; [email-masked]; kaname nishizuka <[email-masked]>; [email-masked]
Subject: Re: [Dots] Signal Channel WGLC: Trigger-Mitigation

Regards

Jon

From: Dots [mailto: [email-masked]<mailto:[email-masked]>] On Behalf Of Konda, Tirumaleswar Reddy
Sent: 03 August 2018 10:35
To: [email-masked]<mailto:[email-masked]>; Jon Shallow; kaname nishizuka; [email-masked]<mailto:[email-masked]>
Subject: Re: [Dots] Signal Channel WGLC: Trigger-Mitigation

Hi Med,

-Tiru

From: [email-masked]<mailto:[email-masked]> <[email-masked]<mailto:[email-masked]>>
Sent: Friday, August 3, 2018 2:56 PM
To: Jon Shallow <[email-masked]<mailto:[email-masked]>>; Konda, Tirumaleswar Reddy <[email-masked]<mailto:[email-masked]>>; kaname nishizuka <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: RE: [Dots] Signal Channel WGLC: Trigger-Mitigation

Good point.

I made this change :

OLD:

NEW:

Do we need to say more?

Cheers,
Med

Hi,

See inline.

Regards

Jon

Re-,

~Jon

Cheers,
Med

Hi Med,

Please see inline

“If two

-Tiru

Cheers,
Med

Hi Med,

-Tiru

Please see inline.

Cheers,
Med

Hi,

“If two

regards,
Kaname

4.4.1 Request Mitigation
…

[TR] No.

[TR] Yes.

[TR] Yup.

-Tiru

Regards

Jon

Dots mailing list

---

From: "Konda, Tirumaleswar Reddy" <[email-masked]>
Date: Fri, 3 Aug 2018 11:31:12 +0000

Hi Jon,

The change proposed by Med is needed. Otherwise,  pre-configured scope from the DOTS client will be overridden by the immediate mitigation request.
NEW:
If two mitigation requests from the DOTS client with different 'trigger-mitigation' types have overlapping mitigation scopes, and if the mitigation request with 'trigger-mitigation' set to false is active, it will be withdrawn ('status' code is set to '7') and then the withdrawn mitigation request will transition to status '8'.

-Tiru

Regards

Jon

Hi Med,

-Tiru

Good point.

I made this change :

OLD:

NEW:

Do we need to say more?

Cheers,
Med

Hi,

See inline.

Regards

Jon

Re-,

~Jon

Cheers,
Med

Hi Med,

Please see inline

“If two

-Tiru

Cheers,
Med

Hi Med,

-Tiru

Please see inline.

Cheers,
Med

Hi,

“If two

regards,
Kaname

4.4.1 Request Mitigation
…

[TR] No.

[TR] Yes.

[TR] Yup.

-Tiru

Regards

Jon

Dots mailing list

---

From: <[email-masked]>
Date: Fri, 3 Aug 2018 11:34:32 +0000

Re-,

Please see inline.

Cheers,
Med

De : Jon Shallow [mailto:[email-masked]]
Envoyé : vendredi 3 août 2018 11:53
À : 'Konda, Tirumaleswar Reddy'; BOUCADAIR Mohamed IMT/OLN; kaname nishizuka; [email-masked]
Objet : RE: [Dots] Signal Channel WGLC: Trigger-Mitigation

Hi,

Regards

Jon

Hi Med,

Jon1> Hmm – Conflict with new [192.0.2.1/32] with [192.0.2.0/24] which is currently not active – need an equivalent 2 conflict-status for the same client.  Is this really a conflict?
[Med] I don’t this is a conflict.

-Tiru

Good point.

I made this change :

OLD:

NEW:
[Med] The first one is needed to make sure that we accept maintaining requests with # types even with overlapping scope. The second change is required to define the meaning of overlapping requests that is used in the next sentence.

Do we need to say more?
Jon1> I would like to see added:-
If the two mitigation requests are not the same ‘trigger-mitigation’ type
[Med] Do you mean: “If the two mitigation requests having different ‘trigger-mitigation’ types”

, but are otherwise overlapping, then the mitigation request that has ‘trigger-mitigation’ set to false SHOULD be set back to state 8 if not already at state 8.
[Med] You are trying to address the case where the pre-configured request was already triggered due to a loss of signal, but once recovered, the client succeeds to place another request with an immediate effect. The new one should win and the pre-configured one put back to 8. This is different, but good to record. I suggest the following:

   If the DOTS server receives a mitigation request which overlaps with
   an active mitigation request having a distinct 'trigger-mitigation'
   type, the DOTS server SHOULD deactivate the mitigation request with
   'trigger-mitigation' set to false (i.e., the state of that mitigation
   should transition to '8').

~Jon1

Cheers,
Med

Hi,

See inline.

Regards

Jon

Re-,

~Jon

Cheers,
Med

Hi Med,

Please see inline

“If two

-Tiru

Cheers,
Med

Hi Med,

-Tiru

Please see inline.

Cheers,
Med

Hi,

“If two

regards,
Kaname

4.4.1 Request Mitigation
…

[TR] No.

[TR] Yes.

[TR] Yup.

-Tiru

Regards

Jon

Dots mailing list

---

From: <[email-masked]>
Date: Fri, 3 Aug 2018 11:53:17 +0000

Re-,

Trying to reconcile both both text proposals:

   If the DOTS server receives a mitigation request which overlaps with
   an active mitigation request having a distinct 'trigger-mitigation'
   type, the DOTS server SHOULD deactivate the mitigation request with
   'trigger-mitigation' set to false.  Particularly, if the mitigation
   request with 'trigger-mitigation' set to false was active, the DOTS
   server withdraws the mitigation request (i.e., status code is set to
   '7' as defined in Table 2) and transitions the status of the
   mitigation request to '8'.

Added a pointer to Table 2 because “status” is not introduced yet.

Cheers,
Med

De : Konda, Tirumaleswar Reddy [mailto:[email-masked]]
Envoyé : vendredi 3 août 2018 13:31
À : Jon Shallow; BOUCADAIR Mohamed IMT/OLN; kaname nishizuka; [email-masked]
Objet : RE: [Dots] Signal Channel WGLC: Trigger-Mitigation

Hi Jon,

-Tiru

Regards

Jon

Hi Med,

-Tiru

Good point.

I made this change :

OLD:

NEW:

Do we need to say more?

Cheers,
Med

Hi,

See inline.

Regards

Jon

Re-,

~Jon

Cheers,
Med

Hi Med,

Please see inline

“If two

-Tiru

Cheers,
Med

Hi Med,

-Tiru

Please see inline.

Cheers,
Med

Hi,

“If two

regards,
Kaname

4.4.1 Request Mitigation
…

[TR] No.

[TR] Yes.

[TR] Yup.

-Tiru

Regards

Jon

Dots mailing list

---

From: "Jon Shallow" <[email-masked]>
Date: Fri, 3 Aug 2018 13:10:52 +0100

Hi Med,

Not entirely sure about the grammar (a distinct) – but like the general text - the following reads better to me

   an active mitigation request, but with both having distinct 'trigger-mitigation'

   types, the DOTS server SHOULD deactivate the mitigation request with

However, as this refers to overlaps, the second part of the overlapping definition no longer stands true in the previous paragraph as per this thread

NEW:

 

Regards

Jon

From: Dots [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: 03 August 2018 12:53
To: Konda, Tirumaleswar Reddy; Jon Shallow; kaname nishizuka; [email-masked]
Subject: Re: [Dots] Signal Channel WGLC: Trigger-Mitigation

Re-,

Cheers,

Med

Hi Jon,

NEW:

-Tiru

  _____  

Hi,

Regards

Jon

Hi Med,

-Tiru

  _____  

Re-,

Good point. 

I made this change : 

OLD:

NEW:

Do we need to say more?

~Jon1

Cheers,

Med

Hi,

See inline.

Regards

Jon

Re-,

~Jon

Cheers,

Med

Hi Med,

Please see inline

  _____  

Tiru,

“If two

-Tiru

Cheers,

Med

Hi Med,

-Tiru

  _____  

Hi Kaname,

Please see inline.

Cheers,

Med

Hi,

“If two

regards,
Kaname

Please see inline [TR]

  _____  

Hi there

4.4.1 Request Mitigation

…

[TR] No. 

[TR] Yes.

[TR] Yup.

-Tiru

Regards

Jon

---

From: <[email-masked]>
Date: Fri, 3 Aug 2018 12:30:17 +0000

Re-,

Please see inline.

Cheers,
Med

De : Jon Shallow [mailto:[email-masked]]
Envoyé : vendredi 3 août 2018 14:11
À : BOUCADAIR Mohamed IMT/OLN; Konda, Tirumaleswar Reddy; kaname nishizuka; [email-masked]
Objet : RE: [Dots] Signal Channel WGLC: Trigger-Mitigation

Hi Med,

[Med] Works for me.

However, as this refers to overlaps,
[Med] “overlap” is used in reference to “scope overlapping”, not “request overlapping”. “request overlapping” covers trigger-mitigation, while this is not the case for scope mitigation.

the second part of the overlapping definition no longer stands true in the previous paragraph as per this thread
[Med] I still don’t see an issue with the new text.

NEW:

Regards

Jon

Re-,

Cheers,
Med

Hi Jon,

-Tiru

Regards

Jon

Hi Med,

-Tiru

Good point.

I made this change :

OLD:

NEW:

Do we need to say more?

Cheers,
Med

Hi,

See inline.

Regards

Jon

Re-,

~Jon

Cheers,
Med

Hi Med,

Please see inline

“If two

-Tiru

Cheers,
Med

Hi Med,

-Tiru

Please see inline.

Cheers,
Med

Hi,

“If two

regards,
Kaname

4.4.1 Request Mitigation
…

[TR] No.

[TR] Yes.

[TR] Yup.

-Tiru

Regards

Jon

Dots mailing list

---

From: "Jon Shallow" <[email-masked]>
Date: Fri, 3 Aug 2018 13:53:47 +0100

Hi Med,

See inline Jon2>

Regards

Jon

From: Dots [mailto: [email-masked]] On Behalf Of [email-masked]
Sent: 03 August 2018 13:30
To: Jon Shallow; Konda, Tirumaleswar Reddy; kaname nishizuka; [email-masked]
Subject: Re: [Dots] Signal Channel WGLC: Trigger-Mitigation

Re-,

Please see inline. 

Cheers,

Med

Hi Med,

[Med] Works for me. 

Jon2> Good & thanks.

Jon> I don’t really follow your distinction here.  We have “mitigation-scope”s which may, or may not, have trigger-mitigation:false.  I read above text update/addition as an overlap of 2 mitigation-scopes as defined by

“Two mitigation requests from a DOTS client are overlapping

   if there is a common IP address, IP prefix, FQDN, URI, or alias-name.”

Jon2> OK. Hence the next comment below to try to help here.  Previous paragraph refers to the NEW text just below (I was assuming that “If the DOTS server receives a mitigation request…” new text would be following the NEW text below)

NEW:

Jon2> If we are to use this overlap definition as a general definition, then the “and the same 'trigger-mitigation' type” does not apply to the “If the DOTS server receives a mitigation request…” new text.  As we have clarity that this paragraph (by your first change) only refers to mitigation requests with the same ‘trigger-mitigation’ type, then the definition of ‘overlapping’ does not need to include the ‘same ‘trigger-mitigation’ type.

~Jon2

 

Regards

Jon

Re-,

Cheers,

Med

Hi Jon,

NEW:

-Tiru

  _____  

Hi,

Regards

Jon

Hi Med,

-Tiru

  _____  

Re-,

Good point. 

I made this change : 

OLD:

NEW:

Do we need to say more?

~Jon1

Cheers,

Med

Hi,

See inline.

Regards

Jon

Re-,

~Jon

Cheers,

Med

Hi Med,

Please see inline

  _____  

Tiru,

“If two

-Tiru

Cheers,

Med

Hi Med,

-Tiru

  _____  

Hi Kaname,

Please see inline.

Cheers,

Med

Hi,

“If two

regards,
Kaname

Please see inline [TR]

  _____  

Hi there

4.4.1 Request Mitigation

…

[TR] No. 

[TR] Yes.

[TR] Yup.

-Tiru

Regards

Jon

---

From: <[email-masked]>
Date: Fri, 3 Aug 2018 13:33:05 +0000

Re-,

Let’s test this updated version :

   The relative order of two mitigation requests, having the same
   'trigger-mitigation' type, from a DOTS client is determined by
   comparing their respective 'mid' values.  If two mitigation requests
   with the same 'trigger-mitigation' type have overlapping mitigation
   scopes, the mitigation request with the highest numeric 'mid' value
   will override the other mitigation request.  Two mitigation requests
   from a DOTS client have overlapping scopes if there is a common IP
   address, IP prefix, FQDN, URI, or alias-name.  To avoid maintaining a
   long list of overlapping mitigation requests (i.e., requests with the
   same 'trigger-mitigation' type and overlapping scopes) from a DOTS
   client and avoid error-prone provisioning of mitigation requests from
   a DOTS client, the overlapped lower numeric 'mid' MUST be
   automatically deleted and no longer available at the DOTS server.  If
   the DOTS server receives a mitigation request which overlaps with an
   active mitigation request, but both having distinct 'trigger-
   mitigation' types, the DOTS server SHOULD deactivate the mitigation
   request with 'trigger-mitigation' set to false.  Particularly, if the
   mitigation request with 'trigger-mitigation' set to false was active,
   the DOTS server withdraws the mitigation request (i.e., status code
   is set to '7' as defined in Table 2) and transitions the status of
   the mitigation request to '8'.

Better?

Cheers,
Med

De : Jon Shallow [mailto:[email-masked]]
Envoyé : vendredi 3 août 2018 14:54
À : BOUCADAIR Mohamed IMT/OLN; Konda, Tirumaleswar Reddy; kaname nishizuka; [email-masked]
Objet : RE: [Dots] Signal Channel WGLC: Trigger-Mitigation

Hi Med,

See inline Jon2>

Regards

Jon

Re-,

Please see inline.

Cheers,
Med

Hi Med,

[Med] Works for me.
Jon2> Good & thanks.

NEW:

~Jon2

Regards

Jon

Re-,

Cheers,
Med

Hi Jon,

-Tiru

Regards

Jon

Hi Med,

-Tiru

Good point.

I made this change :

OLD:

NEW:

Do we need to say more?

Cheers,
Med

Hi,

See inline.

Regards

Jon

Re-,

~Jon

Cheers,
Med

Hi Med,

Please see inline

“If two

-Tiru

Cheers,
Med

Hi Med,

-Tiru

Please see inline.

Cheers,
Med

Hi,

“If two

regards,
Kaname

4.4.1 Request Mitigation
…

[TR] No.

[TR] Yes.

[TR] Yup.

-Tiru

Regards

Jon

Dots mailing list

---

From: "Jon Shallow" <[email-masked]>
Date: Fri, 3 Aug 2018 15:01:23 +0100

Hi Med,

Yes, this is capturing the spirit of what we have been discussing – thanks.

It is a long paragraph and possibly could logically be broken just before

If

It has been brought up before but got lost on the way – what happens when “mid” wraps and 0 is supposed to be greater than 2**32-1 (0xffffffff) for systems that stay up for long long times?

“RFC793 TCP 3.3 Sequence numbers” has a way of handling this

  It is essential to remember that the actual sequence number space is

  finite, though very large.  This space ranges from 0 to 2**32 - 1.

  Since the space is finite, all arithmetic dealing with sequence

  numbers must be performed modulo 2**32.  This unsigned arithmetic

  preserves the relationship of sequence numbers as they cycle from

  2**32 - 1 to 0 again.  There are some subtleties to computer modulo

  arithmetic, so great care should be taken in programming the

  comparison of such values.  The symbol "=<" means "less than or equal"

  (modulo 2**32).

Regards

Jon

From: Dots [mailto: [email-masked]] On Behalf Of [email-masked]
Sent: 03 August 2018 14:33
To: Jon Shallow; Konda, Tirumaleswar Reddy; kaname nishizuka; [email-masked]
Subject: Re: [Dots] Signal Channel WGLC: Trigger-Mitigation

Re-,

Better?

Cheers,

Med

Hi Med,

See inline Jon2>

Regards

Jon

Re-,

Please see inline. 

Cheers,

Med

Hi Med,

[Med] Works for me. 

Jon2> Good & thanks.

 

 

NEW:

~Jon2

 

Regards

Jon

Re-,

Cheers,

Med

Hi Jon,

NEW:

-Tiru

  _____  

Hi,

Regards

Jon

Hi Med,

-Tiru

  _____  

Re-,

Good point. 

I made this change : 

OLD:

NEW:

Do we need to say more?

~Jon1

Cheers,

Med

Hi,

See inline.

Regards

Jon

Re-,

~Jon

Cheers,

Med

Hi Med,

Please see inline

  _____  

Tiru,

“If two

-Tiru

Cheers,

Med

Hi Med,

-Tiru

  _____  

Hi Kaname,

Please see inline.

Cheers,

Med

Hi,

“If two

regards,
Kaname

Please see inline [TR]

  _____  

Hi there

4.4.1 Request Mitigation

…

[TR] No. 

[TR] Yes.

[TR] Yup.

-Tiru

Regards

Jon

---

From: <[email-masked]>
Date: Fri, 3 Aug 2018 14:12:54 +0000

Re-,

Inline.

Cheers,
Med

De : Jon Shallow [mailto:[email-masked]]
Envoyé : vendredi 3 août 2018 16:01
À : BOUCADAIR Mohamed IMT/OLN; Konda, Tirumaleswar Reddy; kaname nishizuka; [email-masked]
Objet : RE: [Dots] Signal Channel WGLC: Trigger-Mitigation

Hi Med,

[Med] Happily.

It has been brought up before but got lost on the way – what happens when “mid” wraps and 0 is supposed to be greater than 2**32-1 (0xffffffff) for systems that stay up for long long times?
[Med] Will answer in a separate message.

Regards

Jon

Re-,

Better?

Cheers,
Med

Hi Med,

See inline Jon2>

Regards

Jon

Re-,

Please see inline.

Cheers,
Med

Hi Med,

[Med] Works for me.
Jon2> Good & thanks.

NEW:

~Jon2

Regards

Jon

Re-,

Cheers,
Med

Hi Jon,

-Tiru

Regards

Jon

Hi Med,

-Tiru

Good point.

I made this change :

OLD:

NEW:

Do we need to say more?

Cheers,
Med

Hi,

See inline.

Regards

Jon

Re-,

~Jon

Cheers,
Med

Hi Med,

Please see inline

“If two

-Tiru

Cheers,
Med

Hi Med,

-Tiru

Please see inline.

Cheers,
Med

Hi,

“If two

regards,
Kaname

4.4.1 Request Mitigation
…

[TR] No.

[TR] Yes.

[TR] Yup.

-Tiru

Regards

Jon

Dots mailing list

---

From: "Konda, Tirumaleswar Reddy" <[email-masked]>
Date: Fri, 3 Aug 2018 14:13:26 +0000

Please see inline [TR]

From: [email-masked] <[email-masked]>
Sent: Friday, August 3, 2018 7:03 PM
To: Jon Shallow <[email-masked]>; Konda, Tirumaleswar Reddy <[email-masked]>; kaname nishizuka <[email-masked]>; [email-masked]
Subject: RE: [Dots] Signal Channel WGLC: Trigger-Mitigation

[TR] Any  specific reason for choosing “SHOULD” (suggest replacing “SHOULD” with “MUST”) ?

[TR] replace “was” with “is”

[TR] We will also have to discuss the following scenario:
When the DOTS signal channel session is lost, active mitigation requests overlapping with the mitigation requests with pre-configured-scopes will be withdrawn, and DDoS mitigation will be triggered for the mitigation requests with pre-configured-scopes.

Better?

[TR] Yes ☺

-Tiru

Cheers,
Med

Hi Med,

See inline Jon2>

Regards

Jon

From: Dots [mailto: [email-masked]<mailto:[email-masked]>] On Behalf Of [email-masked]<mailto:[email-masked]>
Sent: 03 August 2018 13:30
To: Jon Shallow; Konda, Tirumaleswar Reddy; kaname nishizuka; [email-masked]<mailto:[email-masked]>
Subject: Re: [Dots] Signal Channel WGLC: Trigger-Mitigation

Re-,

Please see inline.

Cheers,
Med

Hi Med,

[Med] Works for me.
Jon2> Good & thanks.

NEW:

~Jon2

Regards

Jon

From: Dots [mailto:[email-masked]] On Behalf Of [email-masked]<mailto:[email-masked]>
Sent: 03 August 2018 12:53
To: Konda, Tirumaleswar Reddy; Jon Shallow; kaname nishizuka; [email-masked]<mailto:[email-masked]>
Subject: Re: [Dots] Signal Channel WGLC: Trigger-Mitigation

Re-,

Cheers,
Med

De : Konda, Tirumaleswar Reddy [mailto:[email-masked]]
Envoyé : vendredi 3 août 2018 13:31
À : Jon Shallow; BOUCADAIR Mohamed IMT/OLN; kaname nishizuka; [email-masked]<mailto:[email-masked]>
Objet : RE: [Dots] Signal Channel WGLC: Trigger-Mitigation

Hi Jon,

-Tiru

From: Dots <[email-masked]<mailto:[email-masked]>> On Behalf Of Jon Shallow
Sent: Friday, August 3, 2018 3:23 PM
To: Konda, Tirumaleswar Reddy <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; kaname nishizuka <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: Re: [Dots] Signal Channel WGLC: Trigger-Mitigation

Regards

Jon

Hi Med,

-Tiru

Good point.

I made this change :

OLD:

NEW:

Do we need to say more?

Cheers,
Med

Hi,

See inline.

Regards

Jon

Re-,

~Jon

Cheers,
Med

Hi Med,

Please see inline

“If two

-Tiru

Cheers,
Med

Hi Med,

-Tiru

Please see inline.

Cheers,
Med

Hi,

“If two

regards,
Kaname

4.4.1 Request Mitigation
…

[TR] No.

[TR] Yes.

[TR] Yup.

-Tiru

Regards

Jon

Dots mailing list

---

From: <[email-masked]>
Date: Fri, 3 Aug 2018 14:21:35 +0000

Re-,

Inline.

Cheers,
Med

De : Konda, Tirumaleswar Reddy [mailto:[email-masked]]
Envoyé : vendredi 3 août 2018 16:13
À : BOUCADAIR Mohamed IMT/OLN; Jon Shallow; kaname nishizuka; [email-masked]
Objet : RE: [Dots] Signal Channel WGLC: Trigger-Mitigation

Please see inline [TR]

[TR] Any  specific reason for choosing “SHOULD” (suggest replacing “SHOULD” with “MUST”) ?
[Med] Leave some “configuration”-based policy at the server side when a distinct behavior is agreed contractually between the client and ddos provider?

[Med] OK

[Med] including when the scope of the immediate request (received before the signal loss) is larger than the pre-configured scope?

Better?

[TR] Yes ☺

-Tiru

Cheers,
Med

Hi Med,

See inline Jon2>

Regards

Jon

Re-,

Please see inline.

Cheers,
Med

Hi Med,

[Med] Works for me.
Jon2> Good & thanks.

NEW:

~Jon2

Regards

Jon

Re-,

Cheers,
Med

Hi Jon,

-Tiru

Regards

Jon

Hi Med,

-Tiru

Good point.

I made this change :

OLD:

NEW:

Do we need to say more?

Cheers,
Med

Hi,

See inline.

Regards

Jon

Re-,

~Jon

Cheers,
Med

Hi Med,

Please see inline

“If two

-Tiru

Cheers,
Med

Hi Med,

-Tiru

Please see inline.

Cheers,
Med

Hi,

“If two

regards,
Kaname

4.4.1 Request Mitigation
…

[TR] No.

[TR] Yes.

[TR] Yup.

-Tiru

Regards

Jon

Dots mailing list

---

From: "Konda, Tirumaleswar Reddy" <[email-masked]>
Date: Fri, 3 Aug 2018 14:31:24 +0000

Please see inline [TR2]

From: [email-masked] <[email-masked]>
Sent: Friday, August 3, 2018 7:52 PM
To: Konda, Tirumaleswar Reddy <[email-masked]>; Jon Shallow <[email-masked]>; kaname nishizuka <[email-masked]>; [email-masked]
Subject: RE: [Dots] Signal Channel WGLC: Trigger-Mitigation

Inline.

Cheers,
Med

De : Konda, Tirumaleswar Reddy [mailto:[email-masked]]
Envoyé : vendredi 3 août 2018 16:13
À : BOUCADAIR Mohamed IMT/OLN; Jon Shallow; kaname nishizuka; [email-masked]<mailto:[email-masked]>
Objet : RE: [Dots] Signal Channel WGLC: Trigger-Mitigation

Please see inline [TR]

[TR2] Why would the client and DDoS mitigation provider go with  such a  policy to override the behavior defined in the spec ?

[TR2] No, the assumption is the pre-configured scope will be larger.

-Tiru

Better?

[TR] Yes ☺

-Tiru

Cheers,
Med

Hi Med,

See inline Jon2>

Regards

Jon

Re-,

Please see inline.

Cheers,
Med

Hi Med,

[Med] Works for me.
Jon2> Good & thanks.

NEW:

~Jon2

Regards

Jon

Re-,

Cheers,
Med

Hi Jon,

-Tiru

Regards

Jon

Hi Med,

-Tiru

Good point.

I made this change :

OLD:

NEW:

Do we need to say more?

Cheers,
Med

Hi,

See inline.

Regards

Jon

Re-,

~Jon

Cheers,
Med

Hi Med,

Please see inline

“If two

-Tiru

Cheers,
Med

Hi Med,

-Tiru

Please see inline.

Cheers,
Med

Hi,

“If two

regards,
Kaname

4.4.1 Request Mitigation
…

[TR] No.

[TR] Yes.

[TR] Yup.

-Tiru

Regards

Jon

Dots mailing list

---

From: <[email-masked]>
Date: Fri, 3 Aug 2018 14:44:23 +0000

Re-,

Inline.

Cheers,
Med

De : Konda, Tirumaleswar Reddy [mailto:[email-masked]]
Envoyé : vendredi 3 août 2018 16:31
À : BOUCADAIR Mohamed IMT/OLN; Jon Shallow; kaname nishizuka; [email-masked]
Objet : RE: [Dots] Signal Channel WGLC: Trigger-Mitigation

Please see inline [TR2]

Inline.

Cheers,
Med

Please see inline [TR]

[TR2] Why would the client and DDoS mitigation provider go with  such a  policy to override the behavior defined in the spec ?
[Med] they may believe that given that the pre-configured one was triggered is a sign that the attack is severe enough and that it is likely that the signal may be lost again so maintaining the preconfigured one would be fine.

[Med] Many cases then :)

-Tiru

Better?

[TR] Yes ☺

-Tiru

Cheers,
Med

Hi Med,

See inline Jon2>

Regards

Jon

Re-,

Please see inline.

Cheers,
Med

Hi Med,

[Med] Works for me.
Jon2> Good & thanks.

NEW:

~Jon2

Regards

Jon

Re-,

Cheers,
Med

Hi Jon,

-Tiru

Regards

Jon

Hi Med,

-Tiru

Good point.

I made this change :

OLD:

NEW:

Do we need to say more?

Cheers,
Med

Hi,

See inline.

Regards

Jon

Re-,

~Jon

Cheers,
Med

Hi Med,

Please see inline

“If two

-Tiru

Cheers,
Med

Hi Med,

-Tiru

Please see inline.

Cheers,
Med

Hi,

“If two

regards,
Kaname

4.4.1 Request Mitigation
…

[TR] No.

[TR] Yes.

[TR] Yup.

-Tiru

Regards

Jon

Dots mailing list

---

From: "Jon Shallow" <[email-masked]>
Date: Fri, 3 Aug 2018 15:59:33 +0100

See inline Jon3>

Some re – inline removed.

Regards

Jon

  _____  

Re-,

Jon3> I’m neutral on this one – however, if SHOULD, my DOTS client code will have to handle the 2 possibilities that 3rd party DOTS servers may take, but I don’t see that as an issue.

[Med] OK

[Med] Many cases then :)

Jon3> I do like Tiru’s concept, but it can only take place if the mitigation request with trigger-mitigation:true is entirely within the mitigation request with trigger-mitigation:false.  I.e. target-prefix[192.0.1.1,192.0.2.1] is not entirely within target-prefix[192.0.1.0/24], but does overlap.

~Jon3

-Tiru

Better?

[TR] Yes J

-Tiru

Cheers,

Med

Hi Med,

See inline Jon2>

Regards

Jon

Re-,

Please see inline. 

Cheers,

Med

Hi Med,

[Med] Works for me. 

Jon2> Good & thanks.

 

 

NEW:

~Jon2

 

Regards

Jon

Re-,

Cheers,

Med

Hi Jon,

NEW:

-Tiru

  _____  

Hi,

Regards

Jon

Hi Med,

-Tiru

  _____  

Re-,

Good point. 

I made this change : 

OLD:

NEW:

Do we need to say more?

~Jon1

Cheers,

Med

Hi,

See inline.

Regards

Jon

Re-,

~Jon

Cheers,

Med

Hi Med,

Please see inline

  _____  

Tiru,

“If two

-Tiru

Cheers,

Med

Hi Med,

-Tiru

  _____  

Hi Kaname,

Please see inline.

Cheers,

Med

Hi,

“If two

regards,
Kaname

Please see inline [TR]

  _____  

Hi there

4.4.1 Request Mitigation

…

[TR] No. 

[TR] Yes.

[TR] Yup.

-Tiru

Regards

Jon

---

From: Benjamin Kaduk <[email-masked]>
Date: Fri, 3 Aug 2018 20:04:10 -0500

> CAUTION: External email. Do not click links or open attachments unless you recognize the sender and know the content is safe.

I'll make a general note that it's often useful to include an example for
the countervailing case when SHOULD is used instead of MUST, to help the
reader know whether they fall into the normal case or the exception.  On
the other hand, sometimes it just makes already-long text longer, so such
clarification merely SHOULD be used :)

Another option would be "MUST deactivate (absent explicit
policy/configuration otherwise)".

-Ben

---

From: "Konda, Tirumaleswar Reddy" <[email-masked]>
Date: Sat, 4 Aug 2018 04:04:08 +0000

> -----Original Message-----
> From: Benjamin Kaduk <[email-masked]>
> Sent: Saturday, August 4, 2018 6:34 AM
> To: [email-masked]
> Cc: Konda, Tirumaleswar Reddy <[email-masked]>;
> Jon Shallow <[email-masked]>; kaname nishizuka
> <[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.
> 
> > To: Jon Shallow <[email-masked]>; Konda, Tirumaleswar Reddy
> > <[email-masked]>; kaname nishizuka
> > <[email-masked]>; [email-masked]
> > CAUTION: External email. Do not click links or open attachments unless you
> recognize the sender and know the content is safe.
> >
> >
> > [Med] Leave some “configuration”-based policy at the server side when a
> distinct behavior is agreed contractually between the client and ddos provider?
> 
> I'll make a general note that it's often useful to include an example for the
> countervailing case when SHOULD is used instead of MUST, to help the reader
> know whether they fall into the normal case or the exception.  On the other
> hand, sometimes it just makes already-long text longer, so such clarification
> merely SHOULD be used :)
> 
> Another option would be "MUST deactivate (absent explicit policy/configuration
> otherwise)".

I like the text proposed by Ben.

Thanks,
-Tiru

---

From: "Konda, Tirumaleswar Reddy" <[email-masked]>
Date: Sat, 4 Aug 2018 04:20:17 +0000

(Removing text related to resolved comments}

[TR3] Agreed. The mitigation with pre-configured scope is conveyed during the peace time, DOTS client will have to assume the entire domain can be potentially subjected to DDoS attack and pre-configure the scope, it does not make any sense to have a pre-configured scope smaller than the immediate mitigation request.  To avoid many cases, we should consider mandating the pre-configured scope to be a superset of immediate mitigation requests.

Cheers,
-Tiru

---

From: "Jon Shallow" <[email-masked]>
Date: Sat, 4 Aug 2018 11:23:28 +0100

Hi there,

See inline Jon4>

Regards

Jon

From: Dots [mailto: [email-masked]] On Behalf Of Konda, Tirumaleswar Reddy
Sent: 04 August 2018 05:20
To: Jon Shallow; [email-masked]; kaname nishizuka; [email-masked]
Subject: Re: [Dots] Signal Channel WGLC: Trigger-Mitigation

[Med] Many cases then :)

Jon4> This is too restrictive.  I can see a DOTS client being responsible for 2 subnets, one subnet is critical and has a requirement for trigger-mitigation:false (e.g. critical clients who are prepared to pay extra for DDoS mitigation), the other subnet is not so critical, so mitigation requested on a as needed basis makes more sense based on the upstream DOTS mitigator’s charging methods.

Jon4> Turning Tiru’s suggestion on its head, if there are one or more pre-configured scopes, then an immediate mitigation request that overlaps any of the pre-configured scopes MUST be a subset of that pre-configured scope.  If not then the request is rejected with 4.09 conflict with an appropriate conflict status.  Tiru’s scenario then works as expected.

Jon4> The conflicting information needs to be re-written to remove ‘different’ from ‘different DOTS client’ type expressions.  We may want to maintain different conflict-status for ‘different’ and ‘same’ DOTS clients.

Jon4>

“When the DOTS signal channel session is lost, active mitigation requests overlapping with the mitigation requests with pre-configured-scopes will be withdrawn,”

Does the active mitigation have an active-but-terminating period?

~Jon4

Cheers,

-Tiru

---

From: "Konda, Tirumaleswar Reddy" <[email-masked]>
Date: Sat, 4 Aug 2018 15:02:46 +0000

Please see inline [TR4]

From: Jon Shallow <[email-masked]>
Sent: Saturday, August 4, 2018 3:53 PM
To: Konda, Tirumaleswar Reddy <[email-masked]>; [email-masked]; kaname nishizuka <[email-masked]>; [email-masked]
Subject: RE: [Dots] Signal Channel WGLC: Trigger-Mitigation

See inline Jon4>

Regards

Jon

From: Dots [mailto: [email-masked]<mailto:[email-masked]>] On Behalf Of Konda, Tirumaleswar Reddy
Sent: 04 August 2018 05:20
To: Jon Shallow; [email-masked]<mailto:[email-masked]>; kaname nishizuka; [email-masked]<mailto:[email-masked]>
Subject: Re: [Dots] Signal Channel WGLC: Trigger-Mitigation

[TR4] Yes, works for me.

[TR4] Agreed.
Jon4>

[TR4] No, pre-configured scope will anyway mitigate the target conveyed in the active immediate mitigation request.

-Tiru

~Jon4

Cheers,
-Tiru

---

From: "Jon Shallow" <[email-masked]>
Date: Sat, 4 Aug 2018 16:20:07 +0100

Please see inline Jon5>

[Med] Many cases then :)

[TR4] Yes, works for me. 

[TR4] Agreed.

Jon4>

Jon5>  My thinking also.  Again, the active-but-mitigating text needs tightening up to either acknowledge this exclusion, or by defining the case when it is invoked.

~Jon5

-Tiru

~Jon4

Cheers,

-Tiru

---

From: "Konda, Tirumaleswar Reddy" <[email-masked]>
Date: Mon, 6 Aug 2018 02:47:29 +0000

Inline [TR5]

From: Jon Shallow <[email-masked]>
Sent: Saturday, August 4, 2018 8:50 PM
To: Konda, Tirumaleswar Reddy <[email-masked]>; [email-masked]; kaname nishizuka <[email-masked]>; [email-masked]
Subject: RE: [Dots] Signal Channel WGLC: Trigger-Mitigation

[TR4] Yes, works for me.

[TR4] Agreed.
Jon4>

[TR5] Sure, we will update draft to discuss the case when active-but-terminating period is involved.

-Tiru

~Jon5

-Tiru

~Jon4

Cheers,
-Tiru

---

From: <[email-masked]>
Date: Mon, 6 Aug 2018 06:05:15 +0000

Hi Benjamin, 

Thanks. 

I went with "MUST deactivate (absent explicit
policy/configuration otherwise)".

Cheers,
Med

> -----Message d'origine-----
> De : Benjamin Kaduk [mailto:[email-masked]]
> Envoyé : samedi 4 août 2018 03:04
> À : BOUCADAIR Mohamed IMT/OLN
> Cc : Konda, Tirumaleswar Reddy; Jon Shallow; kaname nishizuka; [email-masked]
> <[email-masked]>; kaname nishizuka <[email-masked]>;
> [email-masked]

---

From: <[email-masked]>
Date: Mon, 6 Aug 2018 07:42:42 +0000

Re-,

Trying to conclude on this one.

I suggest to make this change:

NEW:
   Upon DOTS signal channel session loss with a peer DOTS client, the
   DOTS server MUST withdraw (absent explicit policy/configuration
   otherwise) any active mitigation requests overlapping with mitigation
   requests having 'trigger-mitigation' set to false from that DOTS
   client.  Note that active-but-terminating period is not observed for
   mitigations withdrawn at the initiative of the DOTS server.

I’m not comfortable with making deployment assumptions about pre-configured scopes.

Cheers,
Med

De : Konda, Tirumaleswar Reddy [mailto:[email-masked]]
Envoyé : lundi 6 août 2018 04:47
À : Jon Shallow; BOUCADAIR Mohamed IMT/OLN; kaname nishizuka; [email-masked]
Objet : RE: [Dots] Signal Channel WGLC: Trigger-Mitigation

Inline [TR5]

[TR4] Yes, works for me.

[TR4] Agreed.
Jon4>

-Tiru

~Jon5

-Tiru

~Jon4

Cheers,
-Tiru

---

From: "Konda, Tirumaleswar Reddy" <[email-masked]>
Date: Mon, 6 Aug 2018 08:09:13 +0000

I don’t think the assumptions about pre-configured scope discussed below are deployment specific.

-Tiru

From: [email-masked] <[email-masked]>
Sent: Monday, August 6, 2018 1:13 PM
To: Konda, Tirumaleswar Reddy <[email-masked]>; Jon Shallow <[email-masked]>; kaname nishizuka <[email-masked]>; [email-masked]
Subject: RE: [Dots] Signal Channel WGLC: Trigger-Mitigation

NEW:

Cheers,
Med

Inline [TR5]

From: Jon Shallow <[email-masked]<mailto:[email-masked]>>
Sent: Saturday, August 4, 2018 8:50 PM
To: Konda, Tirumaleswar Reddy <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; kaname nishizuka <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: RE: [Dots] Signal Channel WGLC: Trigger-Mitigation

[TR4] Yes, works for me.

[TR4] Agreed.
Jon4>

-Tiru

~Jon5

-Tiru

~Jon4

Cheers,
-Tiru

---

From: <[email-masked]>
Date: Mon, 6 Aug 2018 08:26:34 +0000

Tiru,

I’m referring to this part from Jon :

‘if there are one or more pre-configured scopes, then an immediate mitigation request that overlaps any of the pre-configured scopes MUST be a subset of that pre-configured scope.  If not then the request is rejected with 4.09 conflict with an appropriate conflict status’

How scopes are defined is deployment-specific. We may do think about what is likely but I don’t think we can mandate it.

What is missing in the proposed text to cover your initial comment?

NEW:

Cheers,
Med

De : Konda, Tirumaleswar Reddy [mailto:[email-masked]]
Envoyé : lundi 6 août 2018 10:09
À : BOUCADAIR Mohamed IMT/OLN; Jon Shallow; kaname nishizuka; [email-masked]
Objet : RE: [Dots] Signal Channel WGLC: Trigger-Mitigation

-Tiru

NEW:

Cheers,
Med

Inline [TR5]

[TR4] Yes, works for me.

[TR4] Agreed.
Jon4>

-Tiru

~Jon5

-Tiru

~Jon4

Cheers,
-Tiru

---

From: "Jon Shallow" <[email-masked]>
Date: Mon, 6 Aug 2018 09:37:12 +0100

Hi Med,

See inline Jon6>

Regards

Jon

From: Dots [mailto: [email-masked]] On Behalf Of [email-masked]
Sent: 06 August 2018 08:43
To: Konda, Tirumaleswar Reddy; Jon Shallow; kaname nishizuka; [email-masked]
Subject: Re: [Dots] Signal Channel WGLC: Trigger-Mitigation

Re-,

NEW:

Jon6> This looks good to me.

Jon6> OK

Cheers,

Med

Inline [TR5]

  _____  

Please see inline Jon5>

[Med] Many cases then :)

[TR4] Yes, works for me. 

[TR4] Agreed.

Jon4>

-Tiru

~Jon5

-Tiru

~Jon4

Cheers,

-Tiru

---

From: <[email-masked]>
Date: Mon, 6 Aug 2018 09:22:47 +0000

Re-,

Thanks, Jon.

FWIW, all changes can be tracked at:
https://github.com/boucadair/draft-ietf-dots-signal-channel/blob/master/wdiff%20draft-ietf-dots-signal-channel-21.txt%20draft-ietf-dots-signal-channel-22.pdf

Cheers,
Med

De : Jon Shallow [mailto:[email-masked]]
Envoyé : lundi 6 août 2018 10:37
À : BOUCADAIR Mohamed IMT/OLN; Konda, Tirumaleswar Reddy; kaname nishizuka; [email-masked]
Objet : RE: [Dots] Signal Channel WGLC: Trigger-Mitigation

Hi Med,

See inline Jon6>

Regards

Jon

Re-,

NEW:

Cheers,
Med

Inline [TR5]

[TR4] Yes, works for me.

[TR4] Agreed.
Jon4>

-Tiru

~Jon5

-Tiru

~Jon4

Cheers,
-Tiru

---

From: "Konda, Tirumaleswar Reddy" <[email-masked]>
Date: Mon, 6 Aug 2018 14:39:42 +0000

Hi Med,

The problem with the below text is the DOTS client will not know the active mitigation request is withdrawn till the DOTS signal channel session is re-established. It adversely impacts the mitigation if let's say target-prefix={x} with trigger-mitigation=false and target-prefix={x, y} with
trigger-mitigation=true. When the DOTS signal channel session is lost, mitigation for target-prefix={'y'} will be withdrawn by the DOTS server. DOTS client will have re-establish the DOTS signal channel session, learn the mitigation status and send a new mitigation request for target-prefix={y}.

If immediate mitigation request that overlap any of the pre-configured scopes is a subset of that pre-configured scope, the DOTS client will not face the problems discussed above.

-Tiru

From: Konda, Tirumaleswar Reddy
Sent: Monday, August 6, 2018 1:39 PM
To: [email-masked]' <[email-masked]>; Jon Shallow <[email-masked]>; kaname nishizuka <[email-masked]>; [email-masked]
Subject: RE: [Dots] Signal Channel WGLC: Trigger-Mitigation

-Tiru

From: [email-masked]<mailto:[email-masked]> <[email-masked]<mailto:[email-masked]>>
Sent: Monday, August 6, 2018 1:13 PM
To: Konda, Tirumaleswar Reddy <[email-masked]<mailto:[email-masked]>>; Jon Shallow <[email-masked]<mailto:[email-masked]>>; kaname nishizuka <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: RE: [Dots] Signal Channel WGLC: Trigger-Mitigation

NEW:

Cheers,
Med

Inline [TR5]

[TR4] Yes, works for me.

[TR4] Agreed.
Jon4>

-Tiru

~Jon5

-Tiru

~Jon4

Cheers,
-Tiru

---

From: "Konda, Tirumaleswar Reddy" <[email-masked]>
Date: Mon, 6 Aug 2018 14:40:50 +0000

When the mitigation request with 'trigger-mitigation=false' is withdrawn
because of an overlapping immediate mitigation request, attack status 7 needs
to be sent 4 times for the mitigation request with 'trigger-mitigation=false' and then
transition to '8'.

Table 2 needs to be updated.

-Tiru

From: Dots <[email-masked]> On Behalf Of [email-masked]
Sent: Monday, August 6, 2018 2:53 PM
To: Jon Shallow <[email-masked]>; Konda, Tirumaleswar Reddy <[email-masked]>; kaname nishizuka <[email-masked]>; [email-masked]
Subject: Re: [Dots] Signal Channel WGLC: Trigger-Mitigation

Thanks, Jon.

Cheers,
Med

Hi Med,

See inline Jon6>

Regards

Jon

Re-,

NEW:

Cheers,
Med

Inline [TR5]

[TR4] Yes, works for me.

[TR4] Agreed.
Jon4>

-Tiru

~Jon5

-Tiru

~Jon4

Cheers,
-Tiru

---

From: <[email-masked]>
Date: Mon, 6 Aug 2018 14:52:13 +0000

Re-,

Please see inline.

Cheers,
Med

De : Konda, Tirumaleswar Reddy [mailto:[email-masked]]
Envoyé : lundi 6 août 2018 16:40
À : BOUCADAIR Mohamed IMT/OLN; Jon Shallow; kaname nishizuka; [email-masked]
Objet : RE: [Dots] Signal Channel WGLC: Trigger-Mitigation

Hi Med,

The problem with the below text is the DOTS client will not know the active mitigation request is withdrawn till the DOTS signal channel session is re-established.
[Med] A client is supposed to be aware of the (default) behavior when overlaps are detected by the server. How it needs to adjust the scope in case of signal loss is deployment-specific.

It adversely impacts the mitigation if let's say target-prefix={x} with trigger-mitigation=false and target-prefix={x, y} with
trigger-mitigation=true. When the DOTS signal channel session is lost, mitigation for target-prefix={'y'} will be withdrawn by the DOTS server.
[Med] Yes… if the default behavior is followed. When the behavior is relaxed by policy, a DOTS server may decide to maintain all requests active.

DOTS client will have re-establish the DOTS signal channel session, learn the mitigation status and send a new mitigation request for target-prefix={y}.
[Med] Typically.

If immediate mitigation request that overlap any of the pre-configured scopes is a subset of that pre-configured scope, the DOTS client will not face the problems discussed above.
[Med] Agree. But, this is a deployment recommendation. Absent any agreement between the client/provider, a DOTS client is likely to define the pre-configured scopes so that it includes the scope of any immediate request. We don’t need to mandate that in the spec.

-Tiru

-Tiru

NEW:

Cheers,
Med

Inline [TR5]

[TR4] Yes, works for me.

[TR4] Agreed.
Jon4>

-Tiru

~Jon5

-Tiru

~Jon4

Cheers,
-Tiru

---

From: <[email-masked]>
Date: Mon, 6 Aug 2018 15:03:24 +0000

Re-,

Works for me.

We do already have text about that state transition in the core text, but it does not harm to include this NEW text. Thanks.

Cheers,
Med

De : Konda, Tirumaleswar Reddy [mailto:[email-masked]]
Envoyé : lundi 6 août 2018 16:41
À : BOUCADAIR Mohamed IMT/OLN; Jon Shallow; kaname nishizuka; [email-masked]
Objet : RE: [Dots] Signal Channel WGLC: Trigger-Mitigation

-Tiru

Thanks, Jon.

Cheers,
Med

Hi Med,

See inline Jon6>

Regards

Jon

Re-,

NEW:

Cheers,
Med

Inline [TR5]

[TR4] Yes, works for me.

[TR4] Agreed.
Jon4>

-Tiru

~Jon5

-Tiru

~Jon4

Cheers,
-Tiru

---

From: "Konda, Tirumaleswar Reddy" <[email-masked]>
Date: Mon, 6 Aug 2018 15:07:46 +0000

Please see inline [TR]

From: [email-masked] <[email-masked]>
Sent: Monday, August 6, 2018 8:22 PM
To: Konda, Tirumaleswar Reddy <[email-masked]>; Jon Shallow <[email-masked]>; kaname nishizuka <[email-masked]>; [email-masked]
Subject: RE: [Dots] Signal Channel WGLC: Trigger-Mitigation

Please see inline.

Cheers,
Med

Hi Med,

[TR] we don’t have to mandate, recommendation should suffice.

-Tiru

From: Konda, Tirumaleswar Reddy
Sent: Monday, August 6, 2018 1:39 PM
To: [email-masked]' <[email-masked]<mailto:[email-masked]>>; Jon Shallow <[email-masked]<mailto:[email-masked]>>; kaname nishizuka <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: RE: [Dots] Signal Channel WGLC: Trigger-Mitigation

-Tiru

NEW:

Cheers,
Med

Inline [TR5]

[TR4] Yes, works for me.

[TR4] Agreed.
Jon4>

-Tiru

~Jon5

-Tiru

~Jon4

Cheers,
-Tiru

---

From: "Konda, Tirumaleswar Reddy" <[email-masked]>
Date: Tue, 7 Aug 2018 03:30:26 +0000

I suggest we add the following line to help implementors tune the immediate mitigation requests:

If the immediate mitigation request overlaps any of the pre-configured scopes, it is recommended that its scope is a subset of pre-configured scopes. This prevents the non-overlapping scopes in the immediate mitigation request to be withdrawn initiatively by the DOTS server when the DOTS signal channel session is lost.

-Tiru

From: Konda, Tirumaleswar Reddy
Sent: Monday, August 6, 2018 8:38 PM
To: [email-masked]' <[email-masked]>; Jon Shallow <[email-masked]>; kaname nishizuka <[email-masked]>; [email-masked]
Subject: RE: [Dots] Signal Channel WGLC: Trigger-Mitigation

Please see inline [TR]

Please see inline.

Cheers,
Med

Hi Med,

-Tiru

-Tiru

NEW:

Cheers,
Med

Inline [TR5]

[TR4] Yes, works for me.

[TR4] Agreed.
Jon4>

-Tiru

~Jon5

-Tiru

~Jon4

Cheers,
-Tiru

---

From: <[email-masked]>
Date: Tue, 7 Aug 2018 06:13:47 +0000

Hi Tiru,

OK, let’s see which text to include while keeping this deployment/implementation-specific.

What about?

   DOTS clients may adopt various strategies for setting the scopes of
   immediate and pre-configured mitigation requests to avoid potential
   conflicts.  For example, a DOTS client may tweak pre-configured
   scopes so that the scope of any overlapping immediate mitigation
   request will be a subset of the pre-configured scopes. Also, if an
   immediate mitigation request overlaps with any of the pre-configured
   scopes, the DOTS client sets the scope of the immediate mitigation
   request to be a subset of the pre-configured scopes.

Justification:

·         Conflicts can be anticipated by installing pre-configured scopes that will cover any forthcoming immediate request.

·         Conflicts are managed during the placement of the immediate request. The text is silent about whether one or multiple mitigation requests will be needed to signal the non-overlapping scopes.

Cheers,
Med

De : Konda, Tirumaleswar Reddy [mailto:[email-masked]]
Envoyé : mardi 7 août 2018 05:30
À : BOUCADAIR Mohamed IMT/OLN; Jon Shallow; kaname nishizuka; [email-masked]
Objet : RE: [Dots] Signal Channel WGLC: Trigger-Mitigation

-Tiru

Please see inline [TR]

Please see inline.

Cheers,
Med

Hi Med,

-Tiru

-Tiru

NEW:

Cheers,
Med

Inline [TR5]

[TR4] Yes, works for me.

[TR4] Agreed.
Jon4>

-Tiru

~Jon5

-Tiru

~Jon4

Cheers,
-Tiru

---

From: "Konda, Tirumaleswar Reddy" <[email-masked]>
Date: Tue, 7 Aug 2018 06:29:18 +0000

Nice, I like the proposed text ☺

Thanks,
-Tiru

From: [email-masked] <[email-masked]>
Sent: Tuesday, August 7, 2018 11:44 AM
To: Konda, Tirumaleswar Reddy <[email-masked]>; [email-masked]
Subject: RE: [Dots] Signal Channel WGLC: Trigger-Mitigation

What about?

   request will be a subset of the pre-configured scopes.
   Also, if an

Justification:

  *   Conflicts can be anticipated by installing pre-configured scopes that will cover any forthcoming immediate request.
  *   Conflicts are managed during the placement of the immediate request. The text is silent about whether one or multiple mitigation requests will be needed to signal the non-overlapping scopes.

Cheers,
Med

-Tiru

Please see inline [TR]

Please see inline.

Cheers,
Med

Hi Med,

-Tiru

-Tiru

NEW:

Cheers,
Med

Inline [TR5]

[TR4] Yes, works for me.

[TR4] Agreed.
Jon4>

-Tiru

~Jon5

-Tiru

~Jon4

Cheers,
-Tiru

---

From: <[email-masked]>
Date: Tue, 7 Aug 2018 06:34:20 +0000

Great !

Thank you, Tiru.

Cheers,
Med

De : Konda, Tirumaleswar Reddy [mailto:[email-masked]]
Envoyé : mardi 7 août 2018 08:29
À : BOUCADAIR Mohamed IMT/OLN; [email-masked]
Objet : RE: [Dots] Signal Channel WGLC: Trigger-Mitigation

Thanks,
-Tiru

What about?

Justification:

Cheers,
Med

-Tiru

Please see inline [TR]

Please see inline.

Cheers,
Med

Hi Med,

-Tiru

-Tiru

NEW:

Cheers,
Med

Inline [TR5]

[TR4] Yes, works for me.

[TR4] Agreed.
Jon4>

-Tiru

~Jon5

-Tiru

~Jon4

Cheers,
-Tiru