Subject: [Dots] signal-channel: Conflict detection and notification

From: <[email-masked]>
Date: Fri, 24 Nov 2017 14:02:55 +0000

Hi all,

As discussed during the last IETF meeting, we are seeking for feedback from the WG about how to address this requirement:

=========
   SIG-009  Conflict Detection and Notification: Multiple DOTS clients
      controlled by a single administrative entity may send conflicting
      mitigation requests for pools of protected resources as a result
      of misconfiguration, operator error, or compromised DOTS clients.
      DOTS servers in the same administrative domain attempting to honor
      conflicting requests may flap network route or DNS information,
      degrading the networks attempting to participate in attack
      response with the DOTS clients.  DOTS servers in a single
      administrative domain SHALL detect such conflicting requests, and
      SHALL notify the DOTS clients in conflict.  The notification
      SHOULD indicate the nature and scope of the conflict, for example,
      the overlapping prefix range in a conflicting mitigation request.
========

For example, would it be OK if we leave implementation-specific the criteria upon which a dots server relies to consider two requests from two clients as conflicting, but draft-ietf-dots-signal defines only the procedure to notify clients when a conflict is detected?

Likewise, would it be OK if the document does not specify which of the conflicting actions is to be discarded (old, new, all) by the server, but draft-ietf-dots-signal defines how to inform clients about which action was enforced by the server?

Cheers,
Med

---

From: "Jon Shallow" <[email-masked]>
Date: Tue, 28 Nov 2017 11:19:36 -0000

Hi Med,

See inline

Regards

Jon

From: Dots [mailto: [email-masked]] On Behalf Of
[email-masked]
Sent: 24 November 2017 14:03
To: [email-masked]
Subject: [Dots] signal-channel: Conflict detection and notification

Hi all, 

As discussed during the last IETF meeting, we are seeking for feedback from
the WG about how to address this requirement:

=========

========

For example, would it be OK if we leave implementation-specific the criteria
upon which a dots server relies to consider two requests from two clients as
conflicting, but draft-ietf-dots-signal defines only the procedure to notify
clients when a conflict is detected? 

Jon> I agree that how this is done is implementation specific.  However
there is a scenario where Client-A initiates a mitigation requests which is
acted upon, Client-B does a conflicting mitigation request but the DOTS
Server decides that Client-B is the "more" valid mitigation request and
effectively de-activates Client-A's request.  Table 2:
draft-ietf-dots-signal-channel-09 therefore needs an additional status
parameter to indicate to client-A there is a conflict and hence Client-A is
being stood down while another client is controlling the mitigation.  A
suggestion would be 

7 | DOTS Server has detected conflicting mitigation requests from different
DOTS clients.  This mitigation request is currently inactive until the
conflicts are resolved. Another mitigation request is active.

Jon> The DOTS client can then elect to leave in the mitigation request (and
even refresh the PUT to refresh the timeout) or delete it.

Jon> I do not think it appropriate that an error message be sent back (e.g.
4.xx) if the DOTS server immediately decides there is a conflicting request
and closes down the new PUT request unless we come up with a specific error
code so the DOTS client can understand why the request is getting errored.

Likewise, would it be OK if the document does not specify which of the
conflicting actions is to be discarded (old, new, all) by the server, but
draft-ietf-dots-signal defines how to inform clients about which action was
enforced by the server? 

Jon> Again, I think that this would be implementation specific.  The
suggested Table 2: entry above would cover this as well.  The DOTS client
just needs to know it has been de-selected / discarded - I don't think the
DOTS client needs to know how / why the DOTS server chose that particular
DOTS client.

Cheers,

Med

---

From: "Konda, Tirumaleswar Reddy" <[email-masked]>
Date: Tue, 28 Nov 2017 11:42:05 +0000

Hi Jon,

What is the problem if the DOTS server returns 4.09 (conflict) error response for the conflicting mitigation request from Client-A ?
The above error code is already defined https://tools.ietf.org/html/rfc8132.

-Tiru

From: Dots [mailto:[email-masked]] On Behalf Of Jon Shallow
Sent: Tuesday, November 28, 2017 4:50 PM
To: [email-masked]; [email-masked]
Subject: Re: [Dots] signal-channel: Conflict detection and notification

Hi Med,

See inline

Regards

Jon

From: Dots [mailto: [email-masked]<mailto:[email-masked]>] On Behalf Of [email-masked]<mailto:[email-masked]>
Sent: 24 November 2017 14:03
To: [email-masked]<mailto:[email-masked]>
Subject: [Dots] signal-channel: Conflict detection and notification

Hi all,

=========

For example, would it be OK if we leave implementation-specific the criteria upon which a dots server relies to consider two requests from two clients as conflicting, but draft-ietf-dots-signal defines only the procedure to notify clients when a conflict is detected?
Jon> I agree that how this is done is implementation specific.  However there is a scenario where Client-A initiates a mitigation requests which is acted upon, Client-B does a conflicting mitigation request but the DOTS Server decides that Client-B is the "more" valid mitigation request and effectively de-activates Client-A's request.  Table 2: draft-ietf-dots-signal-channel-09 therefore needs an additional status parameter to indicate to client-A there is a conflict and hence Client-A is being stood down while another client is controlling the mitigation.  A suggestion would be

7 | DOTS Server has detected conflicting mitigation requests from different DOTS clients.  This mitigation request is currently inactive until the conflicts are resolved. Another mitigation request is active.

Jon> The DOTS client can then elect to leave in the mitigation request (and even refresh the PUT to refresh the timeout) or delete it.
Jon> I do not think it appropriate that an error message be sent back (e.g. 4.xx) if the DOTS server immediately decides there is a conflicting request and closes down the new PUT request unless we come up with a specific error code so the DOTS client can understand why the request is getting errored.

Jon> Again, I think that this would be implementation specific.  The suggested Table 2: entry above would cover this as well.  The DOTS client just needs to know it has been de-selected / discarded - I don't think the DOTS client needs to know how / why the DOTS server chose that particular DOTS client.

Cheers,
Med

---

From: "Jon Shallow" <[email-masked]>
Date: Tue, 28 Nov 2017 12:30:37 -0000

Hi Tiru,

If Client-A has invoked a mitigation, then Client-B requests a conflicting
mitigation, if the DOTS server is only allowing the first mitigation request
to be the valid one, then the DOTS server could send back a 4.09 to
Client-B.

However, if the DOTS server is allowed to choose the best mitigation
request, decides it is Client-B, there is no simple way of sending an
unsolicited 4.09 to client-A.  Hence suggestion for an additional status
message which can be sent to Client-A stating that Client-A has been
de-selected because of a mitigation request conflict.

It is also possible that a mitigation state is status 1 (parameter value -
Table 2)) and needs to transition to another state - at which point the
conflict is found - possibly by the DOTS mitigator - which then needs to be
relayed back through the DOTS server.

Regards

Jon

From: Konda, Tirumaleswar Reddy [mailto: [email-masked]]

Sent: 28 November 2017 11:42
To: Jon Shallow; [email-masked]; [email-masked]
Subject: RE: [Dots] signal-channel: Conflict detection and notification

Hi Jon,

What is the problem if the DOTS server returns 4.09 (conflict) error
response for the conflicting mitigation request from Client-A ?

The above error code is already defined
<https://tools.ietf.org/html/rfc8132> https://tools.ietf.org/html/rfc8132. 

-Tiru

Hi Med,

See inline

Regards

Jon

Hi all, 

=========

========

 

Cheers,

Med

---

From: <[email-masked]>
Date: Tue, 28 Nov 2017 13:28:34 +0000

Hi Jon, all,

Thank you for sharing your thoughts on this.

I tend to allow for both 4.09 code and new status values in the spec.

I see that you proposed this new value:
==
7 | DOTS Server has detected conflicting mitigation requests from different DOTS clients.  This mitigation request is currently inactive until the conflicts are resolved. Another mitigation request is active.
==

Please note that a server may be instructed to adopt a more strict behavior by deactivating all conflicting requests. Further, all DOTS clients which issued conflicting requests should be notified, not only the one for which a request is de-activated. As such, I'm afraid we will need more values, e.g.,

==
7 | DOTS Server has detected conflicting mitigation requests from different DOTS clients.  This mitigation request is currently inactive until the conflicts are resolved. Another mitigation request is active.
8 | DOTS Server has detected conflicting mitigation requests from different DOTS clients.  This mitigation request is currently active.
9 | DOTS Server has detected conflicting mitigation requests from different DOTS clients.  All conflicting mitigation requests are inactive.
==

For example:
* If the server decides to activate only one request, then 7 will be sent to all clients for which the request is de-activated and 8 to the client for which the request is maintained active.
* If the server decides to deactivate all requests, then 9 will be sent to all clients.

Cheers,
Med

De : Jon Shallow [mailto:[email-masked]]
Envoyé : mardi 28 novembre 2017 13:31
À : 'Konda, Tirumaleswar Reddy'; BOUCADAIR Mohamed IMT/OLN; [email-masked]
Objet : RE: [Dots] signal-channel: Conflict detection and notification

Hi Tiru,

If Client-A has invoked a mitigation, then Client-B requests a conflicting mitigation, if the DOTS server is only allowing the first mitigation request to be the valid one, then the DOTS server could send back a 4.09 to Client-B.

However, if the DOTS server is allowed to choose the best mitigation request, decides it is Client-B, there is no simple way of sending an unsolicited 4.09 to client-A.  Hence suggestion for an additional status message which can be sent to Client-A stating that Client-A has been de-selected because of a mitigation request conflict.

It is also possible that a mitigation state is status 1 (parameter value - Table 2)) and needs to transition to another state - at which point the conflict is found - possibly by the DOTS mitigator - which then needs to be relayed back through the DOTS server.

Regards

Jon

From: Konda, Tirumaleswar Reddy [mailto: [email-masked]<mailto:[email-masked]>]
Sent: 28 November 2017 11:42
To: Jon Shallow; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: RE: [Dots] signal-channel: Conflict detection and notification

Hi Jon,

-Tiru

From: Dots [mailto:[email-masked]] On Behalf Of Jon Shallow
Sent: Tuesday, November 28, 2017 4:50 PM
To: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re: [Dots] signal-channel: Conflict detection and notification

Hi Med,

See inline

Regards

Jon

Hi all,

=========

Cheers,
Med

---

From: "Jon Shallow" <[email-masked]>
Date: Tue, 28 Nov 2017 14:15:03 -0000

Hi Med,

In principal I accept the concept of your 7, 8 & 9 status which in effect
are part of the mitigation state as in a state diagram.  However, having
issued a “8” status, this then needs to transition to another state which
reflects what is actually happening – e.g. “2”.

The actual state could immediately be sent following the reporting of “8”
(if Observe active), else it would need to wait until the next status GET.
It is possible that the “8” message gets lost, so relying on receiving the
“8” could be dangerous.

With a “9” response what then is the DOTS client allowed to do?

- A retry of the original mitigation request is likely to fail again

- If all the DOTS clients back off, then there will be no mitigation

- Should there be a random back-off time before retrying?

What is critical is that 

      response with the DOTS clients.

Should not be allowed to happen.

I also do not want to lose sight of 

The notification SHOULD indicate the nature and scope of the conflict,

for example, the overlapping prefix range in a conflicting mitigation
request.”

This potentially can be conveyed in the 4.09 message, or could be a new
mitigation status parameter such as "additional-info" with an appropriate
text value.  It could be that “status” stays with “1” through “6”, and
(possibly optional) “additional-status” has 

0 | This DOTS client mitigation request is being honoured

1 | DOTS Server has detected conflicting mitigation requests from different
DOTS clients.  This mitigation request is currently inactive until the
conflicts are resolved. Another mitigation request is active.

2 | DOTS Server has detected conflicting mitigation requests from different
DOTS clients.  This mitigation request is currently active. 

3 | DOTS Server has detected conflicting mitigation requests from different
DOTS clients.  All conflicting mitigation requests are inactive.

And “additional-info” reports on what the nature and scope of the conflict
is.

Regards

Jon

From: Dots [mailto: [email-masked]] On Behalf Of
[email-masked]
Sent: 28 November 2017 13:29
To: Jon Shallow; 'Konda, Tirumaleswar Reddy'; [email-masked]
Subject: Re: [Dots] signal-channel: Conflict detection and notification

Hi Jon, all,

==

==

Please note that a server may be instructed to adopt a more strict behavior
by deactivating all conflicting requests. Further, all DOTS clients which
issued conflicting requests should be notified, not only the one for which a
request is de-activated. As such, I’m afraid we will need more values, e.g.,

==

8 | DOTS Server has detected conflicting mitigation requests from different
DOTS clients.  This mitigation request is currently active. 

9 | DOTS Server has detected conflicting mitigation requests from different
DOTS clients.  All conflicting mitigation requests are inactive.

==

For example:

* If the server decides to activate only one request, then 7 will be sent to
all clients for which the request is de-activated and 8 to the client for
which the request is maintained active. 

* If the server decides to deactivate all requests, then 9 will be sent to
all clients.  

Cheers,

Med

Hi Tiru,

It is also possible that a mitigation state is status 1 (parameter value –
Table 2)) and needs to transition to another state – at which point the
conflict is found - possibly by the DOTS mitigator - which then needs to be
relayed back through the DOTS server.

Regards

Jon

Hi Jon,

-Tiru

Hi Med,

See inline

Regards

Jon

Hi all, 

=========

========

Jon> I agree that how this is done is implementation specific.  However
there is a scenario where Client-A initiates a mitigation requests which is
acted upon, Client-B does a conflicting mitigation request but the DOTS
Server decides that Client-B is the “more” valid mitigation request and
effectively de-activates Client-A’s request.  Table 2:
draft-ietf-dots-signal-channel-09 therefore needs an additional status
parameter to indicate to client-A there is a conflict and hence Client-A is
being stood down while another client is controlling the mitigation.  A
suggestion would be 

 

Jon> Again, I think that this would be implementation specific.  The
suggested Table 2: entry above would cover this as well.  The DOTS client
just needs to know it has been de-selected / discarded – I don’t think the
DOTS client needs to know how / why the DOTS server chose that particular
DOTS client.

Cheers,

Med

---

From: "Konda, Tirumaleswar Reddy" <[email-masked]>
Date: Tue, 28 Nov 2017 15:01:45 +0000

Within a administrative domain, there won't be many different DOTS clients raising conflicting mitigation requests for the same target, the conflict may arise between a DDoS Detector (or a on premise DDoS mitigation system) acting as DOTS clients and a web server with in-built DDoS detection capability.

Under what conditions does the DOTS server return "DOTS Server has detected conflicting mitigation requests from different DOTS clients.  All conflicting mitigation requests are inactive." ?

-Tiru

From: Jon Shallow [mailto:[email-masked]]
Sent: Tuesday, November 28, 2017 7:45 PM
To: [email-masked]; Konda, Tirumaleswar Reddy <[email-masked]>; [email-masked]
Subject: RE: [Dots] signal-channel: Conflict detection and notification

Hi Med,

In principal I accept the concept of your 7, 8 & 9 status which in effect are part of the mitigation state as in a state diagram.  However, having issued a "8" status, this then needs to transition to another state which reflects what is actually happening - e.g. "2".

The actual state could immediately be sent following the reporting of "8" (if Observe active), else it would need to wait until the next status GET.  It is possible that the "8" message gets lost, so relying on receiving the "8" could be dangerous.

With a "9" response what then is the DOTS client allowed to do?
- A retry of the original mitigation request is likely to fail again
- If all the DOTS clients back off, then there will be no mitigation
- Should there be a random back-off time before retrying?

What is critical is that

I also do not want to lose sight of
The notification SHOULD indicate the nature and scope of the conflict,
for example, the overlapping prefix range in a conflicting mitigation request."
This potentially can be conveyed in the 4.09 message, or could be a new mitigation status parameter such as "additional-info" with an appropriate text value.  It could be that "status" stays with "1" through "6", and (possibly optional) "additional-status" has
0 | This DOTS client mitigation request is being honoured
1 | DOTS Server has detected conflicting mitigation requests from different DOTS clients.  This mitigation request is currently inactive until the conflicts are resolved. Another mitigation request is active.
2 | DOTS Server has detected conflicting mitigation requests from different DOTS clients.  This mitigation request is currently active.
3 | DOTS Server has detected conflicting mitigation requests from different DOTS clients.  All conflicting mitigation requests are inactive.
And "additional-info" reports on what the nature and scope of the conflict is.

Regards

Jon

From: Dots [mailto: [email-masked]<mailto:[email-masked]>] On Behalf Of [email-masked]<mailto:[email-masked]>
Sent: 28 November 2017 13:29
To: Jon Shallow; 'Konda, Tirumaleswar Reddy'; [email-masked]<mailto:[email-masked]>
Subject: Re: [Dots] signal-channel: Conflict detection and notification

Hi Jon, all,

==

For example:

Cheers,
Med

De : Jon Shallow [mailto:[email-masked]]
Envoyé : mardi 28 novembre 2017 13:31
À : 'Konda, Tirumaleswar Reddy'; BOUCADAIR Mohamed IMT/OLN; [email-masked]<mailto:[email-masked]>
Objet : RE: [Dots] signal-channel: Conflict detection and notification

Hi Tiru,

Regards

Jon

Hi Jon,

-Tiru

Hi Med,

See inline

Regards

Jon

Hi all,

=========

Cheers,
Med

---

From: <[email-masked]>
Date: Tue, 28 Nov 2017 15:17:27 +0000

Re-,

Please see inline.

Cheers,
Med

De : Jon Shallow [mailto:[email-masked]]
Envoyé : mardi 28 novembre 2017 15:15
À : BOUCADAIR Mohamed IMT/OLN; Konda, Tirumaleswar Reddy; [email-masked]
Objet : RE: [Dots] signal-channel: Conflict detection and notification

Hi Med,

In principal I accept the concept of your 7, 8 & 9 status which in effect are part of the mitigation state as in a state diagram.
[Med] Actually, my initial point is that one single additional status message is not sufficient. We need more granularly.

  However, having issued a "8" status, this then needs to transition to another state which reflects what is actually happening - e.g. "2".
[Med] Yes for that dots client.

The actual state could immediately be sent following the reporting of "8" (if Observe active), else it would need to wait until the next status GET.
[Med] Yes.

  It is possible that the "8" message gets lost, so relying on receiving the "8" could be dangerous.

With a "9" response what then is the DOTS client allowed to do?
[Med] The rationale for enforcing this policy is that the server "believes" there is a misconfiguration at the client side and fixes are need at that front before soliciting the server. At least, clients should log that information and should not renew the request immediately.

- A retry of the original mitigation request is likely to fail again
[Med] Exact.
- If all the DOTS clients back off, then there will be no mitigation
[Med] Exact, but mitigation may not be required to start with. Please remember what happened with Stanislav Petrov, despite a very distinct area.

- Should there be a random back-off time before retrying?
[Med] The server will maintain the state for a given timer and then will remove stale entries. Requests received before that timers will be rejected.

What is critical is that

Regards

Jon

Hi Jon, all,

==

For example:

Cheers,
Med

Hi Tiru,

Regards

Jon

Hi Jon,

-Tiru

Hi Med,

See inline

Regards

Jon

Hi all,

=========

Cheers,
Med

---

From: <[email-masked]>
Date: Tue, 28 Nov 2017 15:24:40 +0000

Tiru,

Please see inline.

Cheers,
Med

De : Dots [mailto:[email-masked]] De la part de Konda, Tirumaleswar Reddy
Envoyé : mardi 28 novembre 2017 16:02
À : Jon Shallow; BOUCADAIR Mohamed IMT/OLN; [email-masked]
Objet : Re: [Dots] signal-channel: Conflict detection and notification

Within a administrative domain, there won't be many different DOTS clients raising conflicting mitigation requests for the same target, the conflict may arise between a DDoS Detector (or a on premise DDoS mitigation system) acting as DOTS clients and a web server with in-built DDoS detection capability.
[Med] I don't think that we can speculate about the nature of the conflicts that may happen. Misconfigured and corrupted software instances may happen.

Under what conditions does the DOTS server return "DOTS Server has detected conflicting mitigation requests from different DOTS clients.  All conflicting mitigation requests are inactive." ?
[Med] A dots server can be typically instructed by a policy to discard conflicting requests. The rationale is that the provider thinks that the clients are misconfigured and something is needed to be fixed before solicited the server. The signal-channel does not need to call for a favorite action when conflicts; that is implementation- and deployment-specific.

-Tiru

From: Jon Shallow [mailto:[email-masked]]
Sent: Tuesday, November 28, 2017 7:45 PM
To: [email-masked]<mailto:[email-masked]>; Konda, Tirumaleswar Reddy <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: RE: [Dots] signal-channel: Conflict detection and notification

Hi Med,

What is critical is that

Regards

Jon

Hi Jon, all,

==

For example:

Cheers,
Med

Hi Tiru,

Regards

Jon

Hi Jon,

-Tiru

Hi Med,

See inline

Regards

Jon

Hi all,

=========

Cheers,
Med

---

From: "Konda, Tirumaleswar Reddy" <[email-masked]>
Date: Wed, 29 Nov 2017 05:39:02 +0000

Hi Med,

In a deployment scenario with a DDoS Detector (or a on premise DDoS mitigation system) acting as DOTS clients and a web server with in-built DDoS detection capability. The web server may not have as much visibility into the extent of the DDoS attack as the DDoS Detector (or IDMS) and there will be conflicting mitigation requests from different DOTS clients, discarding all the mitigation requests from different clients will make the mechanism not useful.

-Tiru

From: [email-masked] [mailto:[email-masked]]
Sent: Tuesday, November 28, 2017 8:55 PM
To: Konda, Tirumaleswar Reddy <[email-masked]>; Jon Shallow <[email-masked]>; [email-masked]
Subject: RE: [Dots] signal-channel: Conflict detection and notification

Tiru,

Please see inline.

Cheers,
Med

De : Dots [mailto:[email-masked]] De la part de Konda, Tirumaleswar Reddy
Envoyé : mardi 28 novembre 2017 16:02
À : Jon Shallow; BOUCADAIR Mohamed IMT/OLN; [email-masked]<mailto:[email-masked]>
Objet : Re: [Dots] signal-channel: Conflict detection and notification

-Tiru

Hi Med,

What is critical is that

Regards

Jon

Hi Jon, all,

==

For example:

Cheers,
Med

Hi Tiru,

Regards

Jon

Hi Jon,

-Tiru

Hi Med,

See inline

Regards

Jon

Hi all,

=========

Cheers,
Med

---

From: <[email-masked]>
Date: Wed, 29 Nov 2017 06:32:19 +0000

Hi Tiru,

I agree with you that discarding all conflicting requests may not be helpful in some cases. In the same way that someone can argue that selecting only one request among conflicting ones may not be useful because the server picked the wrong one.

I do prefer to leave this to implementation/deployment as a policy to be supplied. That policy will instruct the dots server about the behavior to follow based one specific information that is available for a given deployment:

·         Pick one and deactivate all the others based on some criteria

·         Activate all of them

·         De-activate all of them

Cheers,
Med

De : Dots [mailto:[email-masked]] De la part de Konda, Tirumaleswar Reddy
Envoyé : mercredi 29 novembre 2017 06:39
À : BOUCADAIR Mohamed IMT/OLN; Jon Shallow; [email-masked]
Objet : Re: [Dots] signal-channel: Conflict detection and notification

Hi Med,

-Tiru

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]]
Sent: Tuesday, November 28, 2017 8:55 PM
To: 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: Conflict detection and notification

Tiru,

Please see inline.

Cheers,
Med

-Tiru

Hi Med,

What is critical is that

Regards

Jon

Hi Jon, all,

==

For example:

Cheers,
Med

Hi Tiru,

Regards

Jon

Hi Jon,

-Tiru

Hi Med,

See inline

Regards

Jon

Hi all,

=========

Cheers,
Med

---

From: "Konda, Tirumaleswar Reddy" <[email-masked]>
Date: Thu, 30 Nov 2017 09:41:15 +0000

The proposal works for me, is the plan to add 7, 8 and 9 status or add a new "additional-status" parameter ?

-Tiru

From: [email-masked] [mailto:[email-masked]]
Sent: Wednesday, November 29, 2017 12:02 PM
To: Konda, Tirumaleswar Reddy <[email-masked]>; Jon Shallow <[email-masked]>; [email-masked]
Subject: RE: [Dots] signal-channel: Conflict detection and notification

Hi Tiru,

·       Activate all of them

Cheers,
Med

De : Dots [mailto:[email-masked]] De la part de Konda, Tirumaleswar Reddy
Envoyé : mercredi 29 novembre 2017 06:39
À : BOUCADAIR Mohamed IMT/OLN; Jon Shallow; [email-masked]<mailto:[email-masked]>
Objet : Re: [Dots] signal-channel: Conflict detection and notification

Hi Med,

-Tiru

Tiru,

Please see inline.

Cheers,
Med

-Tiru

Hi Med,

What is critical is that

Regards

Jon

Hi Jon, all,

==

For example:

Cheers,
Med

Hi Tiru,

Regards

Jon

Hi Jon,

-Tiru

Hi Med,

See inline

Regards

Jon

Hi all,

=========

Cheers,
Med

---

From: <[email-masked]>
Date: Thu, 30 Nov 2017 10:26:21 +0000

Hi Tiru,

With the "additional-status" parameter, and given the current values defined in Table 2, I don't see which status code to return when "additional-status" is set to "3 | DOTS Server has detected conflicting mitigation requests from different DOTS clients.  All conflicting mitigation requests are inactive". I'm afraid new status codes should be defined for this to work (e.g., "X: Attack mitigation is withdrawn", "Y: Attack mitigation is rejected").

Note that in both approaches, we will need to supply additional information to characterize the conflict (conflict-information). This information should be returned to all clients.

So, what about considering this direction?

-    Update the status table with these NEW codes:

o    7: Attack mitigation is withdrawn

o    8: Attack mitigation is rejected

-    Allow for including 'additional-status'. Define 'conflict-information' under that parent; 'conflict-information' can include the following sub-parameters:

o    conflict-status: three codes

§  1 | DOTS Server has detected conflicting mitigation requests from different DOTS clients.  This mitigation request is currently inactive until the conflicts are resolved. Another mitigation request is active.

§  2 | DOTS Server has detected conflicting mitigation requests from different DOTS clients.  This mitigation request is currently active.

§  3 | DOTS Server has detected conflicting mitigation requests from different DOTS clients.  All conflicting mitigation requests are inactive.

o    conflict-scope: same structure as "scope"
Cheers,
Med

De : Konda, Tirumaleswar Reddy [mailto:[email-masked]]
Envoyé : jeudi 30 novembre 2017 10:41
À : BOUCADAIR Mohamed IMT/OLN; Jon Shallow; [email-masked]
Objet : RE: [Dots] signal-channel: Conflict detection and notification

-Tiru

Hi Tiru,

*       Pick one and deactivate all the others based on some criteria

*       Activate all of them

*       De-activate all of them

Cheers,
Med

Hi Med,

-Tiru

Tiru,

Please see inline.

Cheers,
Med

-Tiru

Hi Med,

What is critical is that

Regards

Jon

Hi Jon, all,

==

For example:

Cheers,
Med

Hi Tiru,

Regards

Jon

Hi Jon,

-Tiru

Hi Med,

See inline

Regards

Jon

Hi all,

=========

Cheers,
Med

---

From: "Jon Shallow" <[email-masked]>
Date: Thu, 30 Nov 2017 10:33:42 -0000

Hi Tiru et al,

I have been having a think about this one, and do not know (from a DOTS
client coding perspective) what to do if using 7, 8 and 9 method – in
particular 8 (DOTS Server has detected conflicting mitigation requests from
different DOTS clients.  This mitigation request is currently active.).
“currently active” could be one of status 1 through 5.  

An answer could be to have 7, 8 becomes 8-12 (to mirror the 1-5 status) and
9 becomes 13 as an alternative to “additional-status”.  I am agnostic here
as to which way, but do need to know the fact that the original 8 has a
status subtype of 1-5, or that 1-5 have a conflict status sub-type.

The use of 4.09 as an immediate response to a mitigation request should be
documented as a valid response (as only few people are SME on all the other
RFCs!).  7, 8 & 9 (or the alternatives) are for after the mitigation request
has been accepted.

At any point the DOTS server can elect to change the status on detection of
a conflict (which could be after a DOTS mitigator detects a conflict –
possibly from 2 different DOTS servers and reports it back to DOTS server
(how – out of scope)).  The mitigation request will, from the DOTS client
perspective, remain in that conflict state (status) until either the
conflict is resolved (e.g. another DOTS client backs off), or the DOTS
client issues a DELETE.

The DOTS client can monitor the status using Observe.

If the DOTS client is intelligent enough (assume in the general case
unlikely), there is nothing stopping it DELETE current mitigation request
and issue a new one with the conflict potentially resolved.

For reporting the conflict as per

I would suggest an additional (optional) “additional-info” reports on what
the nature and scope of the conflict is.  This conflict report cannot be too
wordy due to packet MTU limitations.  It may be that we define different
conflict codes, in which case “additional-info” could be “conflict-code”.

Regards

Jon

From: Dots [mailto: [email-masked]] On Behalf Of Konda, Tirumaleswar
Reddy
Sent: 30 November 2017 09:41
To: [email-masked]; Jon Shallow; [email-masked]
Subject: Re: [Dots] signal-channel: Conflict detection and notification

The proposal works for me, is the plan to add 7, 8 and 9 status or add a new
“additional-status” parameter ?

-Tiru

From: [email-masked] [mailto:[email-masked]] 
Sent: Wednesday, November 29, 2017 12:02 PM
To: Konda, Tirumaleswar Reddy <[email-masked]>; Jon
Shallow <[email-masked]>; [email-masked]
Subject: RE: [Dots] signal-channel: Conflict detection and notification

Hi Tiru, 

I agree with you that discarding all conflicting requests may not be helpful
in some cases. In the same way that someone can argue that selecting only
one request among conflicting ones may not be useful because the server
picked the wrong one.   

I do prefer to leave this to implementation/deployment as a policy to be
supplied. That policy will instruct the dots server about the behavior to
follow based one specific information that is available for a given
deployment:  

·       Activate all of them

Cheers,

Med 

De : Dots [mailto:[email-masked]] De la part de Konda, Tirumaleswar
Reddy
Envoyé : mercredi 29 novembre 2017 06:39
À : BOUCADAIR Mohamed IMT/OLN; Jon Shallow; [email-masked]
Objet : Re: [Dots] signal-channel: Conflict detection and notification

Hi Med,

In a deployment scenario with a DDoS Detector (or a on premise DDoS
mitigation system) acting as DOTS clients and a web server with in-built
DDoS detection capability. The web server may not have as much visibility
into the extent of the DDoS attack as the DDoS Detector (or IDMS) and there
will be conflicting mitigation requests from different DOTS clients,
discarding all the mitigation requests from different clients will make the
mechanism not useful.

-Tiru

From: [email-masked] [mailto:[email-masked]] 
Sent: Tuesday, November 28, 2017 8:55 PM
To: Konda, Tirumaleswar Reddy <[email-masked]>; Jon
Shallow <[email-masked]>; [email-masked]
Subject: RE: [Dots] signal-channel: Conflict detection and notification

Tiru, 

Please see inline. 

Cheers,

Med

De : Dots [mailto:[email-masked]] De la part de Konda, Tirumaleswar
Reddy
Envoyé : mardi 28 novembre 2017 16:02
À : Jon Shallow; BOUCADAIR Mohamed IMT/OLN; [email-masked]
Objet : Re: [Dots] signal-channel: Conflict detection and notification

Within a administrative domain, there won’t be many different DOTS clients
raising conflicting mitigation requests for the same target, the conflict
may arise between a DDoS Detector (or a on premise DDoS mitigation system)
acting as DOTS clients and a web server with in-built DDoS detection
capability.  

[Med] I don’t think that we can speculate about the nature of the conflicts
that may happen. Misconfigured and corrupted software instances may happen. 

Under what conditions does the DOTS server return “DOTS Server has detected
conflicting mitigation requests from different DOTS clients.  All
conflicting mitigation requests are inactive.” ?

[Med] A dots server can be typically instructed by a policy to discard
conflicting requests. The rationale is that the provider thinks that the
clients are misconfigured and something is needed to be fixed before
solicited the server. The signal-channel does not need to call for a
favorite action when conflicts; that is implementation- and
deployment-specific.  

-Tiru

From: Jon Shallow [mailto:[email-masked]] 
Sent: Tuesday, November 28, 2017 7:45 PM
To: [email-masked]; Konda, Tirumaleswar Reddy
<[email-masked]>; [email-masked]
Subject: RE: [Dots] signal-channel: Conflict detection and notification

Hi Med,

What is critical is that 

Regards

Jon

Hi Jon, all,

==

==

==

==

For example:

Cheers,

Med

Hi Tiru,

Regards

Jon

Hi Jon,

-Tiru

Hi Med,

See inline

Regards

Jon

Hi all, 

=========

========

 

Cheers,

Med

---

From: "Konda, Tirumaleswar Reddy" <[email-masked]>
Date: Thu, 30 Nov 2017 10:41:45 +0000

Looks good to me.

-Tiru

From: [email-masked] [mailto:[email-masked]]
Sent: Thursday, November 30, 2017 3:56 PM
To: Konda, Tirumaleswar Reddy <[email-masked]>; Jon Shallow <[email-masked]>; [email-masked]
Subject: RE: [Dots] signal-channel: Conflict detection and notification

Hi Tiru,

-Tiru

Hi Tiru,

*       Activate all of them

Cheers,
Med

Hi Med,

-Tiru

Tiru,

Please see inline.

Cheers,
Med

-Tiru

Hi Med,

What is critical is that

Regards

Jon

Hi Jon, all,

==

For example:

Cheers,
Med

Hi Tiru,

Regards

Jon

Hi Jon,

-Tiru

Hi Med,

See inline

Regards

Jon

Hi all,

=========

Cheers,
Med

---

From: "Jon Shallow" <[email-masked]>
Date: Thu, 30 Nov 2017 10:51:08 -0000

This also looks good to me in principal.

I do not think we need the “additional-status” layer – why not just go
straight to “conflict-information”?

I would like to see added “conflict-reason” with some defined conflict codes
under “conflict-information”.

However, none of this status (including bytes-dropped etc.) is defined in
the yang module: ietf-dots-signal as ro entities.

Regards

Jon

From: Dots [mailto: [email-masked]] On Behalf Of Konda, Tirumaleswar
Reddy
Sent: 30 November 2017 10:42
To: [email-masked]; Jon Shallow; [email-masked]
Subject: Re: [Dots] signal-channel: Conflict detection and notification

Looks good to me.

-Tiru

Hi Tiru, 

With the “additional-status” parameter, and given the current values defined
in Table 2, I don’t see which status code to return when “additional-status”
is set to “3 | DOTS Server has detected conflicting mitigation requests from
different DOTS clients.  All conflicting mitigation requests are inactive”.
I’m afraid new status codes should be defined for this to work (e.g., “X:
Attack mitigation is withdrawn”, “Y: Attack mitigation is rejected”). 

Note that in both approaches, we will need to supply additional information
to characterize the conflict (conflict-information). This information should
be returned to all clients.

-   Allow for including ‘additional-status’. Define ‘conflict-information’
under that parent; ‘conflict-information’ can include the following
sub-parameters:

§  1 | DOTS Server has detected conflicting mitigation requests from
different DOTS clients.  This mitigation request is currently inactive until
the conflicts are resolved. Another mitigation request is active.

§  2 | DOTS Server has detected conflicting mitigation requests from
different DOTS clients.  This mitigation request is currently active. 

§  3 | DOTS Server has detected conflicting mitigation requests from
different DOTS clients.  All conflicting mitigation requests are inactive.

o   conflict-scope: same structure as “scope”

Cheers,

Med

-Tiru

Hi Tiru, 

·       Activate all of them

Cheers,

Med 

Hi Med,

-Tiru

Tiru, 

Please see inline. 

Cheers,

Med

-Tiru

Hi Med,

What is critical is that 

Regards

Jon

Hi Jon, all,

==

==

==

==

For example:

Cheers,

Med

Hi Tiru,

Regards

Jon

Hi Jon,

-Tiru

Hi Med,

See inline

Regards

Jon

Hi all, 

=========

========

 

Cheers,

Med

---

From: <[email-masked]>
Date: Thu, 30 Nov 2017 10:54:13 +0000

Re-,

Please see inline.

Cheers,
Med

De : Jon Shallow [mailto:[email-masked]]
Envoyé : jeudi 30 novembre 2017 11:51
À : 'Konda, Tirumaleswar Reddy'; BOUCADAIR Mohamed IMT/OLN; [email-masked]
Objet : RE: [Dots] signal-channel: Conflict detection and notification

I do not think we need the "additional-status" layer - why not just go straight to "conflict-information"?
[Med] This is to leave it extensible if we need in the future to supply more information for other purposes than conflicts. Does it make sense?

I would like to see added "conflict-reason" with some defined conflict codes under "conflict-information".

However, none of this status (including bytes-dropped etc.) is defined in the yang module: ietf-dots-signal as ro entities.

Regards

Jon

From: Dots [mailto: [email-masked]<mailto:[email-masked]>] On Behalf Of Konda, Tirumaleswar Reddy
Sent: 30 November 2017 10:42
To: [email-masked]<mailto:[email-masked]>; Jon Shallow; [email-masked]<mailto:[email-masked]>
Subject: Re: [Dots] signal-channel: Conflict detection and notification

Looks good to me.

-Tiru

Hi Tiru,

*  1 | DOTS Server has detected conflicting mitigation requests from different DOTS clients.  This mitigation request is currently inactive until the conflicts are resolved. Another mitigation request is active.

*  2 | DOTS Server has detected conflicting mitigation requests from different DOTS clients.  This mitigation request is currently active.

*  3 | DOTS Server has detected conflicting mitigation requests from different DOTS clients.  All conflicting mitigation requests are inactive.

-Tiru

Hi Tiru,

*       Activate all of them

Cheers,
Med

Hi Med,

-Tiru

Tiru,

Please see inline.

Cheers,
Med

-Tiru

Hi Med,

What is critical is that

Regards

Jon

Hi Jon, all,

==

For example:

Cheers,
Med

Hi Tiru,

Regards

Jon

Hi Jon,

-Tiru

Hi Med,

See inline

Regards

Jon

Hi all,

=========

Cheers,
Med

---

From: "Konda, Tirumaleswar Reddy" <[email-masked]>
Date: Thu, 30 Nov 2017 11:13:31 +0000

Hi Med,

If required "additional-status" can be added in future specifications; As you already know, DOTS protocol is extensible to define new standard and vendor-specific parameters.
@Jon - Yes, ietf-dots-signal needs to be modified to include the mitigation status parameters.

-Tiru

From: [email-masked] [mailto:[email-masked]]
Sent: Thursday, November 30, 2017 4:24 PM
To: Jon Shallow <[email-masked]>; Konda, Tirumaleswar Reddy <[email-masked]>; [email-masked]
Subject: RE: [Dots] signal-channel: Conflict detection and notification

Re-,

Please see inline.

Cheers,
Med

Regards

Jon

Looks good to me.

-Tiru

Hi Tiru,

-Tiru

Hi Tiru,

*       Activate all of them

Cheers,
Med

Hi Med,

-Tiru

Tiru,

Please see inline.

Cheers,
Med

-Tiru

Hi Med,

What is critical is that

Regards

Jon

Hi Jon, all,

==

For example:

Cheers,
Med

Hi Tiru,

Regards

Jon

Hi Jon,

-Tiru

Hi Med,

See inline

Regards

Jon

Hi all,

=========

Cheers,
Med