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

From: "Jon Shallow" <[email-masked]>
Date: Fri, 1 Dec 2017 14:17:11 -0000

Hi Tiru,

So would we therefore be looking at

   module: ietf-dots-signal

       +--rw mitigation-scope

          +--rw client-identifier*   binary

          +--rw scope* [mitigation-id]

             +--rw mitigation-id        int32

             +--rw target-ip*           inet:ip-address

             +--rw target-prefix*       inet:ip-prefix

             +--rw target-port-range* [lower-port upper-port]

             |  +--rw lower-port    inet:port-number

             |  +--rw upper-port?   inet:port-number

             +--rw target-protocol*     uint8

             +--rw target-fqdn*         inet:domain-name

             +--rw target-uri*          inet:uri

             +--rw alias-name*          string

             +--rw lifetime?            int32

             +--ro mitigation-start?    decimal64

             +--ro status?              int32

             +--ro bytes-dropped?       int32

             +--ro bps-dropped?         int32

             +--ro pkts-dropped?        int32

             +--ro pps-dropped?         int32

             +--ro conflict-information?

                +--ro conflict-status?     int32

                +--ro conflict-scope?

                   +--ro target-ip*           inet:ip-address

                   +--ro target-prefix*       inet:ip-prefix

                   +--ro target-port-range* [lower-port upper-port]

                   |  +--ro lower-port?   inet:port-number

                   |  +--ro upper-port?   inet:port-number

                   +--ro target-protocol*     uint8

                   +--ro target-fqdn*         inet:domain-name

                   +--ro target-uri*          inet:uri

                   +--ro alias-name*          string

Where conflict-scope ‘hints’ at what the conflicting item is?

- What happens when the conflict is caused by a filter/acl definition –
should this also be a conflict-scope definition?

Regards

Jon

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

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

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

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”?

[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]] 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

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, 

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

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:  

·       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,

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,

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 

      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.

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,

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

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

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]] 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:

=========

   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? 

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: <[email-masked]>
Date: Fri, 1 Dec 2017 15:06:21 +0000

Hi Jon,

Please see inline.

Cheers,
Med

De : Jon Shallow [mailto:[email-masked]]
Envoyé : vendredi 1 décembre 2017 15:17
À : 'Konda, Tirumaleswar Reddy'; BOUCADAIR Mohamed IMT/OLN; [email-masked]
Objet : RE: [Dots] signal-channel: Conflict detection and notification

Hi Tiru,

So would we therefore be looking at
[Med] Please check out -10.

   module: ietf-dots-signal
       +--rw mitigation-scope

[Med] -10 does not include the conflict scope (yet) but does include a conflict-cause. The reason for this is that the server may have more than two conflicting requests. So not sure what to return in the conflict-scope in such case.

[Med] Please note that -10 does not include conflict-code for address/uri/fqdn/ports because I'm not sure we can consider two mitigation requests coming from two dots clients as conflicting because each of them is indicating a distinct target fqdn/uri/port/address. Things are cleared for overlapping prefixes, but I think we need to think more about the other cases.

Where conflict-scope 'hints' at what the conflicting item is?
- What happens when the conflict is caused by a filter/acl definition - should this also be a conflict-scope definition?
[Med] There is one code for this in -10:

      conflict-cause:  Indicates the cause of the conflict.  The
         following values are defined:

         1:  Overlapping target prefixes

         2:  Conflicts with an existing white list

Are there any other codes that can be listed here?

Regards

Jon

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

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]> [mailto:[email-masked]]
Sent: Thursday, November 30, 2017 4:24 PM
To: Jon Shallow <[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

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]<mailto:[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

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]]
Sent: Thursday, November 30, 2017 3:56 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

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

De : Konda, Tirumaleswar Reddy [mailto:[email-masked]]
Envoyé : jeudi 30 novembre 2017 10:41
À : BOUCADAIR Mohamed IMT/OLN; Jon Shallow; [email-masked]<mailto:[email-masked]>
Objet : 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]> [mailto:[email-masked]]
Sent: Wednesday, November 29, 2017 12:02 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

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]<mailto:[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]> [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

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

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,

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,

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]<mailto:[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,

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]<mailto:[email-masked]>; [email-masked]<mailto:[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,

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: Fri, 1 Dec 2017 15:36:21 +0000

We may want to further discuss the following points:

1.       I don't see a conflict between a white-listed ACL and mitigation request. When DDoS attack is in progress, white-listed traffic (white-list ACL created using DOTS data channel) will be forwarded to the target network without any processing by the mitigator, rest all other traffic will be scrubbed to detect and drop attack traffic.

2.       Though the conflicting mitigation request is withdrawn or rejected, it is still maintained by the DOTS server.  The DOTS client should use GET (with or without Observe option) to learn if the conflict is resolved. Is "retry-timer" really required ?

3.       Conflicting mitigation scopes could mean client-A signals a target IP address X but client-B signals multiple target IP addresses including X. Client-B could be DDoS detector having higher visibility into the DDoS attack than a Web server (Client-A). Client-B will have higher precedence than Client-A.

-Tiru
From: [email-masked] [mailto:[email-masked]]
Sent: Friday, December 1, 2017 8:36 PM
To: Jon Shallow <[email-masked]>; Konda, Tirumaleswar Reddy <[email-masked]>; [email-masked]
Subject: RE: [Dots] signal-channel: Conflict detection and notification

Hi Jon,

Please see inline.

Cheers,
Med

Hi Tiru,

   module: ietf-dots-signal
       +--rw mitigation-scope

Regards

Jon

Hi Med,

-Tiru

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

---

From: <[email-masked]>
Date: Mon, 4 Dec 2017 07:17:53 +0000

Hi Tiru,

Thank you for summarizing the pending points for discussion.

Please see inline.

Cheers,
Med

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

1.       I don't see a conflict between a white-listed ACL and mitigation request. When DDoS attack is in progress, white-listed traffic (white-list ACL created using DOTS data channel) will be forwarded to the target network without any processing by the mitigator, rest all other traffic will be scrubbed to detect and drop attack traffic.
[Med] Agree with the description.. but when the whitelisted traffic includes DDoS traffic there is "something" to be fixed. Consider that in a deployment scenario the mitigator is also aware of the ACLs, but receives a signal message for a resource that is whitelisted, those are two conflicting information that are available to the mitigator. Having a code signal this conflict wouldn't be appropriate here? Of course, we should not assume that all mitigators are aware of ACLs, but if this the case, the DOTS server should be able to do so.

2.       Though the conflicting mitigation request is withdrawn or rejected, it is still maintained by the DOTS server.  The DOTS client should use GET (with or without Observe option) to learn if the conflict is resolved. Is "retry-timer" really required ?
[Med] The state is maintained for a given duration. So, sending GET messages when that state is still alive, won't be helpful. Providing a hint to the client to guide when it can place future requests for the same resource is an optimization. It has also the side effect to prevent overloading the server.

When no "retry-timer" is returned, the client will behave as you described.

[Med] Thanks.

-Tiru

Hi Jon,

Please see inline.

Cheers,
Med

Hi Tiru,

   module: ietf-dots-signal
       +--rw mitigation-scope

Regards

Jon

Hi Med,

-Tiru

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

---

From: "Konda, Tirumaleswar Reddy" <[email-masked]>
Date: Mon, 4 Dec 2017 08:20:49 +0000

Hi Med,

Please see inline [TR]

From: [email-masked] [mailto:[email-masked]]
Sent: Monday, December 4, 2017 12:48 PM
To: Konda, Tirumaleswar Reddy <[email-masked]>; Jon Shallow <[email-masked]>; [email-masked]
Subject: RE: [Dots] signal-channel: Conflict detection and notification

Hi Tiru,

Please see inline.

Cheers,
Med

1.       I don't see a conflict between a white-listed ACL and mitigation request. When DDoS attack is in progress, white-listed traffic (white-list ACL created using DOTS data channel) will be forwarded to the target network without any processing by the mitigator, rest all other traffic will be scrubbed to detect and drop attack traffic.
[Med] Agree with the description.. but when the whitelisted traffic includes DDoS traffic there is "something" to be fixed. Consider that in a deployment scenario the mitigator is also aware of the ACLs, but receives a signal message for a resource that is whitelisted,

[TR] Source addresses are white-listed to a resource (or target) but the target will not be white-listed to receive traffic from any source.  Mitigation request will only carry the target addresses/prefixes and not the attacker prefixes/addresses. I don't see a conflict.

those are two conflicting information that are available to the mitigator. Having a code signal this conflict wouldn't be appropriate here? Of course, we should not assume that all mitigators are aware of ACLs, but if this the case, the DOTS server should be able to do so.

2.       Though the conflicting mitigation request is withdrawn or rejected, it is still maintained by the DOTS server.  The DOTS client should use GET (with or without Observe option) to learn if the conflict is resolved. Is "retry-timer" really required ?
[Med] The state is maintained for a given duration. So, sending GET messages when that state is still alive, won't be helpful. Providing a hint to the client to guide when it can place future requests for the same resource is an optimization.

[TR] How will the DOTS server know ahead of time when the conflict will be resolved to suggest a hint to the client ?

-Tiru

It has also the side effect to prevent overloading the server.

-Tiru

Hi Jon,

Please see inline.

Cheers,
Med

Hi Tiru,

   module: ietf-dots-signal
       +--rw mitigation-scope

Regards

Jon

Hi Med,

-Tiru

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

---

From: <[email-masked]>
Date: Mon, 4 Dec 2017 09:05:09 +0000

Re-,

Please see inline.

Cheers,
Med

De : Dots [mailto:[email-masked]] De la part de Konda, Tirumaleswar Reddy
Envoyé : lundi 4 décembre 2017 09:21
À : BOUCADAIR Mohamed IMT/OLN; Jon Shallow; [email-masked]
Objet : Re: [Dots] signal-channel: Conflict detection and notification

Hi Med,

Please see inline [TR]

Hi Tiru,

Please see inline.

Cheers,
Med

[TR] Source addresses are white-listed to a resource (or target) but the target will not be white-listed to receive traffic from any source.
[Med] The example is as follows:

-    Accept all incoming traffic from this particular source (S1) to this target.

-    It happens that source (S1) is the origin of a DDoS

 Mitigation request will only carry the target addresses/prefixes and not the attacker prefixes/addresses. I don't see a conflict.
[Med] The conflict is not included in the mitigation request, but it is determined as a result of processing the request. In reference to the example above, the server/mitigator will determine that the target is getting DDoSed by S1. So the conflict is between allowing all the traffic from S1 to the target (ACL) or filter the traffic from S1 (mitigation request).

[TR] How will the DOTS server know ahead of time when the conflict will be resolved to suggest a hint to the client ?
[Med] It can rely on the pending mitigation lifetime.

-Tiru

-Tiru

Hi Jon,

Please see inline.

Cheers,
Med

Hi Tiru,

   module: ietf-dots-signal
       +--rw mitigation-scope

Regards

Jon

Hi Med,

-Tiru

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

---

From: "Konda, Tirumaleswar Reddy" <[email-masked]>
Date: Mon, 4 Dec 2017 09:25:40 +0000

Hi Med,

Please see inline [TR2]

From: [email-masked] [mailto:[email-masked]]
Sent: Monday, December 4, 2017 2:35 PM
To: Konda, Tirumaleswar Reddy <[email-masked]>; Jon Shallow <[email-masked]>; [email-masked]
Subject: RE: [Dots] signal-channel: Conflict detection and notification

Re-,

Please see inline.

Cheers,
Med

Hi Med,

Please see inline [TR]

Hi Tiru,

Please see inline.

Cheers,
Med

[TR2] Got it, thanks. We should add a line to clarify; the DDoS mitigation detects source addresses/prefixes in the white-listed ACLs are attacking the target.

[TR2] If the server response is lost, the client will re-send the mitigation request before the "retry-timer" expires but the server will discard the request. The client will never receive a response, especially with long mitigation lifetime (the recommended default value is 60 minutes).

-Tiru

-Tiru

Hi Jon,

Please see inline.

Cheers,
Med

Hi Tiru,

   module: ietf-dots-signal
       +--rw mitigation-scope

Regards

Jon

Hi Med,

-Tiru

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

---

From: <[email-masked]>
Date: Mon, 4 Dec 2017 09:41:11 +0000

Re-,

OK to add a line to clarify the DDoS mitigation detects source addresses/prefixes in the white-listed ACLs are attacking the target. I will make a proposal.

You said:
==

Good point. I guess you are referring to "Any retransmission of the same mitigation request before the expiry of this timer will be discarded by the DOTS server." Please note that the text does not say "silently discarded". What about?

OLD:
Any retransmission of the same mitigation request before the expiry of this timer will be discarded by the DOTS server.

NEW:
Any retransmission of the same mitigation request before the expiry of this timer is likely to be rejected by the DOTS server for the same reasons.

Cheers,
Med

De : Konda, Tirumaleswar Reddy [mailto:[email-masked]]
Envoyé : lundi 4 décembre 2017 10:26
À : BOUCADAIR Mohamed IMT/OLN; Jon Shallow; [email-masked]
Objet : RE: [Dots] signal-channel: Conflict detection and notification

Hi Med,

Please see inline [TR2]

Re-,

Please see inline.

Cheers,
Med

Hi Med,

Please see inline [TR]

Hi Tiru,

Please see inline.

Cheers,
Med

-Tiru

-Tiru

Hi Jon,

Please see inline.

Cheers,
Med

Hi Tiru,

   module: ietf-dots-signal
       +--rw mitigation-scope

Regards

Jon

Hi Med,

-Tiru

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