Subject: [Dots] several comments on draft-ietf-dots-architecture-06:

From: "Xialiang (Frank, Network Integration Technology Research Dept)" <[email-masked]>
Date: Wed, 11 Jul 2018 09:32:54 +0000

Hi draft authors,
I have several comments of this draft as below for your consideration:

1.       Section 1.2, / "so that only authorized clients can invoke the DOTS service" / "so that only authorized clients/servers can invoke/honor the DOTS service";

2.       Section 2.2.2, / If a DOTS server refuses a DOTS client's request for mitigation, the DOTS server SHOULD include the refusal reason in the server signal sent to the client / If a DOTS server refuses a DOTS client's request for mitigation, the DOTS server MUST include the refusal reason in the server signal sent to the client;

3.       Section 3.2.3, / "End-customer with a single upstream transit provider offering DDoS mitigation services" described in [I-D.ietf-dots-use-cases] /  "Upstream DDoS Mitigation by an Upstream Internet Transit Provider" described in [I-D.ietf-dots-use-cases];

4.       Section 3.2.3, you say "For example, the recursing domain's mitigator should incorporate into mitigation status messages available metrics such as dropped packet or byte counts from the recursed mitigation.", but this is not described in current DOTS signal channel draft. What's your opinion about whether we should add the specified content into the signal channel draft?

5.       Section 3.3.3, by reviewing the DOTS signal channel draft, my take is a signal session (sid) can carry multiple mitigation-scope requesting conversations (cuid + mid + cdid (optional)), is it right? If so, by saying "a DOTS operator may configure the DOTS session to trigger mitigation when the DOTS server ceases receiving DOTS client signals (or vice versa) beyond the miss count or period permitted by the protocol.", which mitigation conversation do you mean to trigger, or all of them over the same signal session?

Thanks!

B.R.
Frank

---

From: "Konda, Tirumaleswar Reddy" <[email-masked]>
Date: Mon, 16 Jul 2018 07:40:21 +0000

Hi Frank,

Thanks for the review. Please see inline [TR]

From: Dots [mailto:[email-masked]] On Behalf Of Xialiang (Frank, Network Integration Technology Research Dept)
Sent: Wednesday, July 11, 2018 3:03 PM
To: [email-masked]
Cc: [email-masked]
Subject: [Dots] several comments on draft-ietf-dots-architecture-06:

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

________________________________
Hi draft authors,
I have several comments of this draft as below for your consideration:

1.       Section 1.2, / “so that only authorized clients can invoke the DOTS service” / “so that only authorized clients/servers can invoke/honor the DOTS service”;

[TR] DOTS client is both authenticated and authorized to invoke the DOTS service but the DOTS server is only authenticated by the DOTS client. I don’t see the need to add “server” and “honor” in the above line.

2.       Section 2.2.2, / If a DOTS server refuses a DOTS client’s request for mitigation, the DOTS server SHOULD include the refusal reason in the server signal sent to the client / If a DOTS server refuses a DOTS client’s request for mitigation, the DOTS server MUST include the refusal reason in the server signal sent to the client;

[TR] Agreed, we will update draft.

[TR] Okay, will fix.

4.       Section 3.2.3, you say “For example, the recursing domain’s mitigator should incorporate into mitigation status messages available metrics such as dropped packet or byte counts from the recursed mitigation.”, but this is not described in current DOTS signal channel draft. What’s your opinion about whether we should add the specified content into the signal channel draft?

[TR] DOTS client is conveyed the mitigation metrics (e.g. bytes-dropped, bps-dropped etc.) by the DOTS server. The DOTS client is opaque to the recursion of the originating mitigation request to the secondary DOTS server, hence the signal channel draft does not discuss recursive signaling but explains conveying the mitigation metrics to the DOTS client in Section 4.4.2.

5.       Section 3.3.3, by reviewing the DOTS signal channel draft, my take is a signal session (sid) can carry multiple mitigation-scope requesting conversations (cuid + mid + cdid (optional)), is it right? If so, by saying “a DOTS operator may configure the DOTS session to trigger mitigation when the DOTS server ceases receiving DOTS client signals (or vice versa) beyond the miss count or period permitted by the protocol.”, which mitigation conversation do you mean to trigger, or all of them over the same signal session?

[TR] If the DOTS server creases receiving DOTS client signal, mitigation will be triggered for all the mitigation requests signaled over the same DOTS signal channel session.

Cheers,

-Tiru

Thanks!

B.R.
Frank

---

From: "Xialiang (Frank, Network Integration Technology Research Dept)" <[email-masked]>
Date: Tue, 17 Jul 2018 19:09:21 +0000

Hi Tiru,
Please consider to add some text to clarify the 5th issue.

Thanks!

B.R.
Frank

发件人: Konda, Tirumaleswar Reddy [mailto:[email-masked]]
发送时间: 2018年7月16日 15:40
收件人: Xialiang (Frank, Network Integration Technology Research Dept) <[email-masked]>; [email-masked]
抄送: [email-masked]
主题: RE: several comments on draft-ietf-dots-architecture-06:

Hi Frank,

From: Dots [mailto:[email-masked]] On Behalf Of Xialiang (Frank, Network Integration Technology Research Dept)
Sent: Wednesday, July 11, 2018 3:03 PM
To: [email-masked]<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>
Subject: [Dots] several comments on draft-ietf-dots-architecture-06:

[TR] Okay, will fix.

Cheers,

-Tiru

Thanks!

B.R.
Frank

---

From: "Konda, Tirumaleswar Reddy" <[email-masked]>
Date: Wed, 18 Jul 2018 06:15:04 +0000

Sure, will do.

Thanks,
-TIru

From: Xialiang (Frank, Network Integration Technology Research Dept) [mailto:[email-masked]]
Sent: Wednesday, July 18, 2018 12:39 AM
To: Konda, Tirumaleswar Reddy <[email-masked]>; [email-masked]
Cc: [email-masked]
Subject: 答复: several comments on draft-ietf-dots-architecture-06:

Thanks!

B.R.
Frank

发件人: Konda, Tirumaleswar Reddy [mailto:[email-masked]]
发送时间: 2018年7月16日 15:40
收件人: Xialiang (Frank, Network Integration Technology Research Dept) <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
抄送: [email-masked]<mailto:[email-masked]>
主题: RE: several comments on draft-ietf-dots-architecture-06:

Hi Frank,

[TR] Okay, will fix.

Cheers,

-Tiru

Thanks!

B.R.
Frank

---

From: "Mortensen, Andrew" <[email-masked]>
Date: Thu, 19 Jul 2018 18:02:57 +0000

Hi Frank. I agree with Tiru, except on the discussion of your 5th question.

…snip...

I think the premise of this question is incorrect. The mitigation-on-loss-of-signal trigger is—at least as I conceived of it—meant to handle a situation where a DOTS client maintains a long-term signal channel, and the heartbeat is lost for a configurable period (missing-hb-allowed). In that case, a client operator should be allowed to trigger automatic mitigation for a preconfigured scope. After all, if one or more mitigations are active, it would not make sense for loss of signal to trigger mitigations: they’re already there.

Tiru, you seemed to be thinking along the same lines when you sent this back in October:

If the DOTS server does not receive any traffic from the DOTS client, then the
DOTS server sends heartbeat requests to the DOTS client and if "trigger-mitigation”
is set to "false", then trigger DDoS mitigation after maximum "missing-hb-allowed”
threshold is reached.
<https://mailarchive.ietf.org/arch/msg/dots/m-ROJTRQaICM3ybSPedohyULwf0>

Importantly, that’s not what ended up in the draft (added in -07, unchanged since, as far as I can tell). Here’s what actually made it into the draft:

If the DOTS server does not receive any traffic from the peer DOTS
client, then the DOTS server sends heartbeat requests to the DOTS
client and after maximum 'missing-hb-allowed' threshold is
reached, the DOTS server concludes the session is disconnected.

As specified, it appears the `trigger-mitigation` configuration option still depends on a client mitigation request:

   trigger-mitigation:   If the parameter value is set to 'false', then
      DDoS mitigation is triggered only when the DOTS signal channel
      session is lost.  Automated mitigation on loss of signal is
      discussed in Section 3.3.3 of [I-D.ietf-dots-architecture].

      If the DOTS client ceases to respond to heartbeat messages, the
      DOTS server can detect that the DOTS session is lost.

      The default value of the parameter is 'true’.

That description makes it sound as if, when `trigger-mitigation` is false, mitigation requests are *ignored* unless the signal channel over which those requests were made is lost.

I thought maybe in my ignorance I overlooked some special handling for this case, but I don’t see any explicit discussion of this in the signal channel draft at all. Is the implicit expectation here that with `trigger-mitigation` set to `false` in the signal channel configuration, a client can request a mitigation which won’t actually be active *until* heartbeats are lost? If so, we should make it clear, and (presumably) add a mitigation status type (“on-loss”?). If what we actually want is a preconfigured mitigation scope which is triggered on signal loss, we should discuss what changes that involves.

Either way, unless I’m totally overlooking some aspect of the signal draft covering this (not impossible), we’ll need to update the draft to address it.

andrew

---

From: "Konda, Tirumaleswar Reddy" <[email-masked]>
Date: Fri, 20 Jul 2018 07:16:06 +0000

Hi Andrew,

Your analysis is correct. If “trigger-mitigation” is set to false, all the mitigation requests sent in the DOTS signal channel will be considered as pre-configured scope and mitigation for these requests will only be triggered when the DOTS signal channel session is lost. In other words, the pre-configured scope is conveyed using the DOTS signal channel. In lieu of the proposed mechanism, pre-configured scope will have to be either configured manually or conveyed using a separate protocol which does not look desirable.

We can do the following changes to the draft to make it more clear:

1)
OLD:
session is lost.

NEW:
trigger-mitigation:   If the parameter value is set to 'false', DDoS mitigation will not be triggered for the mitigation requests conveyed using the DOTS signal channel session unless the DOTS signal channel session is lost.

2.
Add a new value to the mitigation ‘status’ parameter. In Table 2, “8 :  When the DDoS signal channel session is lost, DDoS mitigation will be triggered for the mitigation request”.
If mitigation status is set to 8, mitigation-start will not be returned in the response.

Cheers,
-Tiru

From: Dots [mailto:[email-masked]] On Behalf Of Mortensen, Andrew
Sent: Thursday, July 19, 2018 11:33 PM
To: Xialiang (Frank, Network Integration Technology Research Dept) <[email-masked]>
Cc: [email-masked]
Subject: [Dots] confusion about mitigation trigger on loss of signal (was: several comments on draft-ietf-dots-architecture-06)

…snip...

andrew

---

From: "Mortensen, Andrew" <[email-masked]>
Date: Fri, 20 Jul 2018 12:34:21 +0000

I’ve got a pull request to incorporate some minor changes to address issues 2, 3 and 5 below:

<https://github.com/dotswg/dots-architecture/pull/29>

Unless there are objections, I’ll merge and submit a new draft revision. The remaining barrier to initiating WGLC will then be the updated NAT considerations.

andrew

On Jul 16, 2018, at 3:40 AM, Konda, Tirumaleswar Reddy <[email-masked]<mailto:[email-masked]>> wrote:

[EXTERNAL EMAIL]
Hi Frank,

[TR] Okay, will fix.

Cheers,
-Tiru

Thanks!

B.R.
Frank

---

From: "Mortensen, Andrew" <[email-masked]>
Date: Fri, 20 Jul 2018 12:44:08 +0000

Hi Tiru. I think your proposed changes below will address the issue, thanks.

andrew

On Jul 20, 2018, at 3:16 AM, Konda, Tirumaleswar Reddy <[email-masked]<mailto:[email-masked]>> wrote:

[EXTERNAL EMAIL]
Hi Andrew,

1)
OLD:

NEW:

2.

Cheers,
-Tiru

To: Xialiang (Frank, Network Integration Technology Research Dept) <[email-masked]<mailto:[email-masked]>>

…snip...

andrew

---

From: "Jon Shallow" <[email-masked]>
Date: Mon, 23 Jul 2018 16:28:51 +0100

This does raise some implementation questions which may need to be covered off in the draft.

Signal channel is lost – mitigation kicks in – signal channel works again.

Does the DOTS server then immediately drop the mitigation?

- the signal channel could then disappear again causing an outage bounce….

Does the DOTS server drop the mitigation after the 120 second delay (active-but-terminating period)?

- This may cause a 120 second period networking outage bounce

Does the DOTS server wait for instructions from the DOTS client whilst keeping the mitigating going?

- triggered by an Observe response with status 8 – assuming Observe is active.

> “If mitigation status is set to 8, mitigation-start will not be returned in the response.“

I also do not understand why status 8 should not return mitigation-start.  After all the mitigation has started at X time.

Regards

Jon

From: Dots [mailto: [email-masked]] On Behalf Of Mortensen, Andrew
Sent: 20 July 2018 13:44
To: Konda, Tirumaleswar Reddy
Cc: Xialiang (Frank, Network Integration Technology Research Dept); [email-masked]
Subject: Re: [Dots] confusion about mitigation trigger on loss of signal (was: several comments on draft-ietf-dots-architecture-06)

andrew

On Jul 20, 2018, at 3:16 AM, Konda, Tirumaleswar Reddy <[email-masked]> wrote:

[EXTERNAL EMAIL]

Hi Andrew,

1)

OLD:

session is lost. 

NEW:

2. 

Cheers,

-Tiru

From: Dots [ <mailto:[email-masked]> mailto:[email-masked]] On Behalf Of Mortensen, Andrew
Sent: Thursday, July 19, 2018 11:33 PM
To: Xialiang (Frank, Network Integration Technology Research Dept) < <mailto:[email-masked]> [email-masked]>
Cc:  <mailto:[email-masked]> [email-masked]
Subject: [Dots] confusion about mitigation trigger on loss of signal (was: several comments on draft-ietf-dots-architecture-06)

  _____  

…snip...

threshold is reached.

< <https://mailarchive.ietf.org/arch/msg/dots/m-ROJTRQaICM3ybSPedohyULwf0> https://mailarchive.ietf.org/arch/msg/dots/m-ROJTRQaICM3ybSPedohyULwf0>

andrew

---

From: "Konda, Tirumaleswar Reddy" <[email-masked]>
Date: Tue, 24 Jul 2018 09:05:56 +0000

Hi Jon,

If the mitigation is stopped just because the signal channel is re-established, attacker can create a scenario to continuously start and stop the mitigation and thus the target network would continuously re-configure to re-direct the traffic and would make the target network unstable.
The mitigation should not be stopped even if the DOTS signal channel is re-established, if the client wishes it can explicitly request to withdraw the mitigation request.

Response to your other question, If “trigger-mitigation” is set to false, all the mitigation requests sent in the DOTS signal channel will be considered as pre-configured scope and mitigation for these requests will only be triggered when the DOTS signal channel session is lost, and so mitigation-start cannot return “start time” because the mitigation has not yet started.

Regards,
-Tiru

From: Jon Shallow [mailto:[email-masked]]
Sent: Monday, July 23, 2018 8:59 PM
To: 'Mortensen, Andrew' <[email-masked]>; Konda, Tirumaleswar Reddy <[email-masked]>; Xialiang (Frank) <[email-masked]>; [email-masked]
Subject: RE: [Dots] confusion about mitigation trigger on loss of signal (was: several comments on draft-ietf-dots-architecture-06)

Regards

Jon

andrew

[EXTERNAL EMAIL]
Hi Andrew,

1)
OLD:

NEW:

2.

Cheers,
-Tiru

…snip...

andrew

---

From: <[email-masked]>
Date: Tue, 24 Jul 2018 09:26:29 +0000

Hi Jon,

Please see inline.

Cheers,
Med

De : Dots [mailto:[email-masked]] De la part de Jon Shallow
Envoyé : lundi 23 juillet 2018 17:29
À : 'Mortensen, Andrew'; Konda, Tirumaleswar Reddy; Xialiang (Frank); [email-masked]
Objet : Re: [Dots] confusion about mitigation trigger on loss of signal (was: several comments on draft-ietf-dots-architecture-06)

Does the DOTS server then immediately drop the mitigation?
[Med] No. The same rules for dropping a mitigation would apply here: expiry of the lifetime or receipt of an explicit DELETE from the client.

[Med] Yes, indeed.

Does the DOTS server drop the mitigation after the 120 second delay (active-but-terminating period)?
[Med] The server proceeds with the same behaviour as it does for mitigation requests with an immediate effect. The active-but-terminating period will be observed only when an explicit DELETE is received from the client. Perhaps, we need to mention that for pre-installed mitigations, when an attack has stopped but no delete is received from the client and the lifetime is not expired, then a record of the mitigation request must be still maintained by the server (i.e., state will transition back to 8).

- This may cause a 120 second period networking outage bounce
Does the DOTS server wait for instructions from the DOTS client whilst keeping the mitigating going?
[Med] A DOTS server can expect instructions related to this request from a DOTS client in the same way it does for mitigation requests with an immediate effect.

Regards

Jon

andrew

[EXTERNAL EMAIL]
Hi Andrew,

1)
OLD:

NEW:

2.

Cheers,
-Tiru

…snip...

andrew

---

From: "Jon Shallow" <[email-masked]>
Date: Tue, 24 Jul 2018 10:26:30 +0100

Hi Tiru,

See inline.

Regards

Jon

From: Dots [mailto: [email-masked]] On Behalf Of Konda, Tirumaleswar Reddy
Sent: 24 July 2018 10:06
To: Jon Shallow; 'Mortensen, Andrew'; Xialiang (Frank); [email-masked]
Subject: Re: [Dots] confusion about mitigation trigger on loss of signal (was: several comments on draft-ietf-dots-architecture-06)

Hi Jon,

Jon> Does it make more sense that trigger-mitigation is associated with the Mitigation Request as opposed to the Configuration request?

- What if I want some mitigations to be immediate, others to be started if there is a signal channel loss?

Jon> I think we need to add in some text along the lines of

trigger-mitigation:

…

If the mitigation is started due to signal channel loss, the DOTS server SHOULD NOT on re-establishment of the signal channel stop the mitigation.  Either the DOTS client should subsequently request the withdrawal of the mitigation request, or the DOTS server shut down the mitigation based on the lifetime.

Jon> Dooh – misread the status of 8 as being sent once the DOTS server detected the signal channel loss.  So, once the DOTS server initiates the mitigation, it will cycle through the status 1-7 as appropriate.  Got it.

~Jon

Regards,

-Tiru

  _____  

Regards

Jon

andrew

[EXTERNAL EMAIL]

Hi Andrew,

1)

OLD:

session is lost. 

NEW:

2. 

Cheers,

-Tiru

  _____  

…snip...

threshold is reached.

andrew

---

From: <[email-masked]>
Date: Tue, 24 Jul 2018 09:32:03 +0000

Re-,

Good to see that you raised this point :

“- What if I want some mitigations to be immediate, others to be started if there is a signal channel loss?”

FWIW, I have suggested to Andrew to add this clarification to the Architecture draft (see below):

====================
De : BOUCADAIR Mohamed IMT/OLN
Envoyé : vendredi 20 juillet 2018 16:04
À : 'Mortensen, Andrew'
Cc : Konda, Tirumaleswar Reddy ([email-masked])
Objet : RE: several comments on draft-ietf-dots-architecture-06:

Hi Andrew,

I’d like to double check the intended behavior:

“a DOTS operator may request one or more mitigations which are triggered only

when the DOTS server ceases receiving DOTS client heartbeats beyond the miss

count or interval permitted by the protocol.”

I’ d suggest the text is also clear that an hybrid mode,  in which some mitigations are triggered immediately but other on signal loss, is not required to be supported.
===================

Do we need to support such hybrid mode? If a client can reliably send mitigation requests, why should it install mitigations with pre-configured scopes?

Cheers,
Med

De : Dots [mailto:[email-masked]] De la part de Jon Shallow
Envoyé : mardi 24 juillet 2018 11:27
À : 'Konda, Tirumaleswar Reddy'; Xialiang (Frank); [email-masked]; Mortensen, Andrew
Objet : Re: [Dots] confusion about mitigation trigger on loss of signal (was: several comments on draft-ietf-dots-architecture-06)

Hi Tiru,

See inline.

Regards

Jon

Hi Jon,

~Jon

Regards,
-Tiru

Regards

Jon

andrew

[EXTERNAL EMAIL]
Hi Andrew,

1)
OLD:

NEW:

2.

Cheers,
-Tiru

…snip...

andrew

---

From: "Konda, Tirumaleswar Reddy" <[email-masked]>
Date: Tue, 24 Jul 2018 10:07:17 +0000

Hi Med,

Please see inline [TR]

From: [email-masked] [mailto:[email-masked]]
Sent: Tuesday, July 24, 2018 2:56 PM
To: Jon Shallow <[email-masked]>; 'Mortensen, Andrew' <[email-masked]>; Konda, Tirumaleswar Reddy <[email-masked]>; Xialiang (Frank) <[email-masked]>; [email-masked]
Subject: RE: [Dots] confusion about mitigation trigger on loss of signal (was: several comments on draft-ietf-dots-architecture-06)

Please see inline.

Cheers,
Med

De : Dots [mailto:[email-masked]] De la part de Jon Shallow
Envoyé : lundi 23 juillet 2018 17:29
À : 'Mortensen, Andrew'; Konda, Tirumaleswar Reddy; Xialiang (Frank); [email-masked]<mailto:[email-masked]>
Objet : Re: [Dots] confusion about mitigation trigger on loss of signal (was: several comments on draft-ietf-dots-architecture-06)

[TR] I don’t see the need to implicitly transition back to 8, the DOTS client should not lose the control to stop the mitigation (the client may have some valid reason to continue the mitigation till the lifetime expires).

-Tiru

Regards

Jon

From: Dots [mailto: [email-masked]<mailto:[email-masked]>] On Behalf Of Mortensen, Andrew
Sent: 20 July 2018 13:44
To: Konda, Tirumaleswar Reddy
Cc: Xialiang (Frank, Network Integration Technology Research Dept); [email-masked]<mailto:[email-masked]>
Subject: Re: [Dots] confusion about mitigation trigger on loss of signal (was: several comments on draft-ietf-dots-architecture-06)

andrew

[EXTERNAL EMAIL]
Hi Andrew,

1)
OLD:

NEW:

2.

Cheers,
-Tiru

…snip...

andrew

---

From: "Konda, Tirumaleswar Reddy" <[email-masked]>
Date: Tue, 24 Jul 2018 10:39:46 +0000

Hi Jon,

Please see inline [TR]

From: Jon Shallow [mailto:[email-masked]]
Sent: Tuesday, July 24, 2018 2:57 PM
To: Konda, Tirumaleswar Reddy <[email-masked]>; Xialiang (Frank) <[email-masked]>; [email-masked]; Mortensen, Andrew <[email-masked]>
Subject: RE: [Dots] confusion about mitigation trigger on loss of signal (was: several comments on draft-ietf-dots-architecture-06)

See inline.

Regards

Jon

From: Dots [mailto: [email-masked]<mailto:[email-masked]>] On Behalf Of Konda, Tirumaleswar Reddy
Sent: 24 July 2018 10:06
To: Jon Shallow; 'Mortensen, Andrew'; Xialiang (Frank); [email-masked]<mailto:[email-masked]>
Subject: Re: [Dots] confusion about mitigation trigger on loss of signal (was: several comments on draft-ietf-dots-architecture-06)

Hi Jon,

[TR] The client has to create two signal channels (one with ‘trigger-mitigation’ set to false and in the other channel set the parameter to true).

[TR] NEW:
If the mitigation is triggered due to signal channel loss and signal channel is re-established at a later point of time when the mitigation is active, the DOTS server MUST NOT stop the mitigation. The DOTS client can request the withdrawal of the  mitigation request, or the DOTS server will terminate the mitigation upon expiry of the lifetime.

-Tiru

~Jon

Regards,
-Tiru

From: Jon Shallow [mailto:[email-masked]]
Sent: Monday, July 23, 2018 8:59 PM
To: 'Mortensen, Andrew' <[email-masked]<mailto:[email-masked]>>; Konda, Tirumaleswar Reddy <[email-masked]<mailto:[email-masked]>>; Xialiang (Frank) <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: RE: [Dots] confusion about mitigation trigger on loss of signal (was: several comments on draft-ietf-dots-architecture-06)

Regards

Jon

andrew

[EXTERNAL EMAIL]
Hi Andrew,

1)
OLD:

NEW:

2.

Cheers,
-Tiru

…snip...

andrew

---

From: "Konda, Tirumaleswar Reddy" <[email-masked]>
Date: Tue, 24 Jul 2018 10:59:35 +0000

Hi Med,

Yes, hybrid mode should be supported.
The hybrid mode helps the client to setup the pre-configured scope during the peace time, and if the DOTS client cannot reach the DOTS server during a DDoS attack, it acts as a fail-safe method to trigger mitigation. If the client can send mitigation requests to the DOTS server, mitigation will not be started for the pre-configured scope (as the DOTS server is receiving traffic from the DOTS client).

Cheers,
-Tiru

From: [email-masked] [mailto:[email-masked]]
Sent: Tuesday, July 24, 2018 3:02 PM
To: Jon Shallow <[email-masked]>; Konda, Tirumaleswar Reddy <[email-masked]>; Xialiang (Frank) <[email-masked]>; [email-masked]; Mortensen, Andrew <[email-masked]>
Subject: RE: [Dots] confusion about mitigation trigger on loss of signal (was: several comments on draft-ietf-dots-architecture-06)

====================
De : BOUCADAIR Mohamed IMT/OLN
Envoyé : vendredi 20 juillet 2018 16:04
À : 'Mortensen, Andrew'
Cc : Konda, Tirumaleswar Reddy ([email-masked]<mailto:[email-masked]>)
Objet : RE: several comments on draft-ietf-dots-architecture-06:

Hi Andrew,

Cheers,
Med

De : Dots [mailto:[email-masked]] De la part de Jon Shallow
Envoyé : mardi 24 juillet 2018 11:27
À : 'Konda, Tirumaleswar Reddy'; Xialiang (Frank); [email-masked]<mailto:[email-masked]>; Mortensen, Andrew
Objet : Re: [Dots] confusion about mitigation trigger on loss of signal (was: several comments on draft-ietf-dots-architecture-06)

Hi Tiru,

See inline.

Regards

Jon

Hi Jon,

~Jon

Regards,
-Tiru

Regards

Jon

andrew

[EXTERNAL EMAIL]
Hi Andrew,

1)
OLD:

NEW:

2.

Cheers,
-Tiru

…snip...

andrew

---

From: "Jon Shallow" <[email-masked]>
Date: Tue, 24 Jul 2018 12:03:27 +0100

Hi Tiru,

See inline Jon1.

Regards

Jon

Hi Jon,

Jon1> Possible, but I would prefer that we only kept one signal channel (after doing the happy-eyeballs stuff) between two adjacent DOTS agents for simplicity (For example, I can see confusion with 2 mitigation requests that overlap, but are on 2 different signal channels) and have the trigger-mitigation a part of the mitigation-request.

Jon1> We need clarity on what happens with DOTS gateways.  On the premise that a DOTS gateway is ‘transparently’ relaying mitigation requests etc. between origin DOTS clients and ultimate DOTS servers, they are unlikely to have intimate knowledge of mitigation requests (certainly would have trouble their knowledge re-syncing if a DOTS gateway was restarted).

Jon1> If trigger-mitigation  is a part of signal configuration, and the DOTS client signal channel to DOTS gateway fails, the DOTS server needs to somehow be told by the DOTS gateway to start mitigating.

Jon1> If trigger mitigation is a part of the mitigation request, there is the same issue if the DOTS client signal channel to DOTS gateway fails.  Hmm.

trigger-mitigation:

…

[TR] NEW:

Jon1> Good for me.

~Jon1

-Tiru

~Jon

Regards,

-Tiru

  _____  

Regards

Jon

andrew

[EXTERNAL EMAIL]

Hi Andrew,

1)

OLD:

session is lost. 

NEW:

2. 

Cheers,

-Tiru

  _____  

…snip...

threshold is reached.

andrew

---

From: <[email-masked]>
Date: Tue, 24 Jul 2018 11:06:29 +0000

Re-,

Please see inline.

Cheers,
Med

De : Konda, Tirumaleswar Reddy [mailto:[email-masked]]
Envoyé : mardi 24 juillet 2018 12:07
À : BOUCADAIR Mohamed IMT/OLN; Jon Shallow; 'Mortensen, Andrew'; Xialiang (Frank); [email-masked]
Objet : RE: [Dots] confusion about mitigation trigger on loss of signal (was: several comments on draft-ietf-dots-architecture-06)

Hi Med,

Please see inline [TR]

Please see inline.

Cheers,
Med

[TR] I don’t see the need to implicitly transition back to 8, the DOTS client should not lose the control to stop the mitigation (the client may have some valid reason to continue the mitigation till the lifetime expires).
[Med] I’m not sure to understand the comment because I was assuming “no delete is received from the client” + “lifetime is not expired” + “an attack has stopped”.

-Tiru

Regards

Jon

andrew

[EXTERNAL EMAIL]
Hi Andrew,

1)
OLD:

NEW:

2.

Cheers,
-Tiru

…snip...

andrew

---

From: <[email-masked]>
Date: Tue, 24 Jul 2018 11:10:07 +0000

Re-,

If the hybrid mode is to be supported, then the cleaner way to proceed is to define trigger-mitigation as a parameter of mitigation signals, not as a configuration parameter.

Cheers,
Med

De : Dots [mailto:[email-masked]] De la part de Konda, Tirumaleswar Reddy
Envoyé : mardi 24 juillet 2018 13:00
À : BOUCADAIR Mohamed IMT/OLN; Jon Shallow; Xialiang (Frank); [email-masked]; Mortensen, Andrew
Objet : Re: [Dots] confusion about mitigation trigger on loss of signal (was: several comments on draft-ietf-dots-architecture-06)

Hi Med,

Cheers,
-Tiru

====================

Hi Andrew,

Cheers,
Med

Hi Tiru,

See inline.

Regards

Jon

Hi Jon,

~Jon

Regards,
-Tiru

Regards

Jon

andrew

[EXTERNAL EMAIL]
Hi Andrew,

1)
OLD:

NEW:

2.

Cheers,
-Tiru

…snip...

andrew

---

From: "Konda, Tirumaleswar Reddy" <[email-masked]>
Date: Tue, 24 Jul 2018 11:11:51 +0000

Please see inline [TR2]

From: [email-masked] [mailto:[email-masked]]
Sent: Tuesday, July 24, 2018 4:36 PM
To: Konda, Tirumaleswar Reddy <[email-masked]>; Jon Shallow <[email-masked]>; 'Mortensen, Andrew' <[email-masked]>; Xialiang (Frank) <[email-masked]>; [email-masked]
Subject: RE: [Dots] confusion about mitigation trigger on loss of signal (was: several comments on draft-ietf-dots-architecture-06)

Please see inline.

Cheers,
Med

De : Konda, Tirumaleswar Reddy [mailto:[email-masked]]
Envoyé : mardi 24 juillet 2018 12:07
À : BOUCADAIR Mohamed IMT/OLN; Jon Shallow; 'Mortensen, Andrew'; Xialiang (Frank); [email-masked]<mailto:[email-masked]>
Objet : RE: [Dots] confusion about mitigation trigger on loss of signal (was: several comments on draft-ietf-dots-architecture-06)

Hi Med,

Please see inline [TR]

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]]
Sent: Tuesday, July 24, 2018 2:56 PM
To: Jon Shallow <[email-masked]<mailto:[email-masked]>>; 'Mortensen, Andrew' <[email-masked]<mailto:[email-masked]>>; Konda, Tirumaleswar Reddy <[email-masked]<mailto:[email-masked]>>; Xialiang (Frank) <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: RE: [Dots] confusion about mitigation trigger on loss of signal (was: several comments on draft-ietf-dots-architecture-06)

Please see inline.

Cheers,
Med

[TR2] The client may want the mitigation to continue till the lifetime expires, the DOTS server should not terminate the mitigation without the DOTS client consent.

-Tiru

Regards

Jon

andrew

[EXTERNAL EMAIL]
Hi Andrew,

1)
OLD:

NEW:

2.

Cheers,
-Tiru

…snip...

andrew

---

From: "Konda, Tirumaleswar Reddy" <[email-masked]>
Date: Tue, 24 Jul 2018 11:14:50 +0000

Agreed.

-Tiru

From: [email-masked] [mailto:[email-masked]]
Sent: Tuesday, July 24, 2018 4:40 PM
To: Konda, Tirumaleswar Reddy <[email-masked]>; Jon Shallow <[email-masked]>; Xialiang (Frank) <[email-masked]>; [email-masked]; Mortensen, Andrew <[email-masked]>
Subject: RE: [Dots] confusion about mitigation trigger on loss of signal (was: several comments on draft-ietf-dots-architecture-06)

Cheers,
Med

De : Dots [mailto:[email-masked]] De la part de Konda, Tirumaleswar Reddy
Envoyé : mardi 24 juillet 2018 13:00
À : BOUCADAIR Mohamed IMT/OLN; Jon Shallow; Xialiang (Frank); [email-masked]<mailto:[email-masked]>; Mortensen, Andrew
Objet : Re: [Dots] confusion about mitigation trigger on loss of signal (was: several comments on draft-ietf-dots-architecture-06)

Hi Med,

Cheers,
-Tiru

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]]
Sent: Tuesday, July 24, 2018 3:02 PM
To: Jon Shallow <[email-masked]<mailto:[email-masked]>>; Konda, Tirumaleswar Reddy <[email-masked]<mailto:[email-masked]>>; Xialiang (Frank) <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; Mortensen, Andrew <[email-masked]<mailto:[email-masked]>>
Subject: RE: [Dots] confusion about mitigation trigger on loss of signal (was: several comments on draft-ietf-dots-architecture-06)

====================

Hi Andrew,

Cheers,
Med

Hi Tiru,

See inline.

Regards

Jon

Hi Jon,

~Jon

Regards,
-Tiru

Regards

Jon

andrew

[EXTERNAL EMAIL]
Hi Andrew,

1)
OLD:

NEW:

2.

Cheers,
-Tiru

…snip...

andrew

---

From: <[email-masked]>
Date: Tue, 24 Jul 2018 11:17:09 +0000

Re-,

Please see inline.

Cheers,
Med

De : Konda, Tirumaleswar Reddy [mailto:[email-masked]]
Envoyé : mardi 24 juillet 2018 13:12
À : BOUCADAIR Mohamed IMT/OLN; Jon Shallow; 'Mortensen, Andrew'; Xialiang (Frank); [email-masked]
Objet : RE: [Dots] confusion about mitigation trigger on loss of signal (was: several comments on draft-ietf-dots-architecture-06)

Please see inline [TR2]

Please see inline.

Cheers,
Med

Hi Med,

Please see inline [TR]

Please see inline.

Cheers,
Med

[TR2] The client may want the mitigation to continue till the lifetime expires, the DOTS server should not terminate the mitigation without the DOTS client consent.
[Med] Yes, we are in agreement. I said it explicitly few lines above (in red) :) “The same rules for dropping a mitigation would apply here: expiry of the lifetime or receipt of an explicit DELETE from the client.”. The point about state transition is a distinct one: it is to make sure that a record with the appropriate state is maintained by a server even after mitigation an attack matching a pre-configured mitigation (when no action is received from the client + valid lifetime).

-Tiru

Regards

Jon

andrew

[EXTERNAL EMAIL]
Hi Andrew,

1)
OLD:

NEW:

2.

Cheers,
-Tiru

…snip...

andrew

---

From: "Konda, Tirumaleswar Reddy" <[email-masked]>
Date: Tue, 24 Jul 2018 11:20:10 +0000

Hi Jon,

If the DOTS signal channel b/w the DOTS client and gateway fails, the gateway can mimic the failure b/w the gateway and DOTS server to trigger the mitigation of the pre-configured request. I don’t have any objection to make the trigger-mitigation as a parameter of the mitigation request.

-Tiru

From: Jon Shallow [mailto:[email-masked]]
Sent: Tuesday, July 24, 2018 4:33 PM
To: Konda, Tirumaleswar Reddy <[email-masked]>; Xialiang (Frank) <[email-masked]>; [email-masked]; Mortensen, Andrew <[email-masked]>
Subject: RE: [Dots] confusion about mitigation trigger on loss of signal (was: several comments on draft-ietf-dots-architecture-06)

See inline Jon1.

Regards

Jon

Hi Jon,

[TR] NEW:

Jon1> Good for me.
~Jon1
-Tiru

~Jon

Regards,
-Tiru

Regards

Jon

andrew

[EXTERNAL EMAIL]
Hi Andrew,

1)
OLD:

NEW:

2.

Cheers,
-Tiru

…snip...

andrew

---

From: <[email-masked]>
Date: Tue, 24 Jul 2018 11:35:22 +0000

Tiru, Jon,

In order to avoid corner cases (lifetime expiry=signal channel recovery time, receipt of a delete request==signal channel recovery time), I suggest the following wording:

OLD:
“If the mitigation is triggered due to signal channel loss and signal channel is re-established at a later point of time when the mitigation is active, the DOTS server MUST NOT stop the mitigation. The DOTS client can request the withdrawal of the  mitigation request, or the DOTS server will terminate the mitigation upon expiry of the lifetime.”

NEW:
“If a mitigation is triggered due to a signal channel loss,  the DOTS server relies upon normal triggers to stop that mitigation (typically, receipt of a valid DELETE request, expiry of the mitigation lifetime, or local traffic observation). In particular, the DOTS server MUST NOT consider the signal channel recovery as a trigger to stop the mitigation.”

Cheers,
Med

De : Dots [mailto:[email-masked]] De la part de Jon Shallow
Envoyé : mardi 24 juillet 2018 13:03
À : 'Konda, Tirumaleswar Reddy'; Xialiang (Frank); [email-masked]; Mortensen, Andrew
Objet : Re: [Dots] confusion about mitigation trigger on loss of signal (was: several comments on draft-ietf-dots-architecture-06)

Hi Tiru,

See inline Jon1.

Regards

Jon

Hi Jon,

[TR] NEW:

Jon1> Good for me.
~Jon1
-Tiru

~Jon

Regards,
-Tiru

Regards

Jon

andrew

[EXTERNAL EMAIL]
Hi Andrew,

1)
OLD:

NEW:

2.

Cheers,
-Tiru

…snip...

andrew

---

From: "Jon Shallow" <[email-masked]>
Date: Tue, 24 Jul 2018 12:36:26 +0100

Hi Tiru,

I like the concept of link-fail pass-thru from the downstream to the upstream only.  Once downstream is re-established on the DOTS gateway, then upstream reconnects.

There does need to be the ability to test out each link, so the link-fail pass-thru option does need to be configurable.

Again, we need some words in the text to indicate this.

Regards

Jon

From: Dots [mailto: [email-masked]] On Behalf Of Konda, Tirumaleswar Reddy
Sent: 24 July 2018 12:20
To: Jon Shallow; Xialiang (Frank); [email-masked]; Mortensen, Andrew
Subject: Re: [Dots] confusion about mitigation trigger on loss of signal (was: several comments on draft-ietf-dots-architecture-06)

Hi Jon,

-Tiru

  _____  

Hi Tiru,

See inline Jon1.

Regards

Jon

Hi Jon,

 

trigger-mitigation:

…

[TR] NEW:

Jon1> Good for me.

~Jon1

-Tiru

~Jon

Regards,

-Tiru

  _____  

Regards

Jon

andrew

[EXTERNAL EMAIL]

Hi Andrew,

1)

OLD:

session is lost. 

NEW:

2. 

Cheers,

-Tiru

  _____  

…snip...

threshold is reached.

andrew

---

From: <[email-masked]>
Date: Tue, 24 Jul 2018 11:38:48 +0000

Re-,

Great!

The rationale for the hybrid mode should be discussed in the arch draft.

Cheers,
Med

De : Dots [mailto:[email-masked]] De la part de Konda, Tirumaleswar Reddy
Envoyé : mardi 24 juillet 2018 13:15
À : BOUCADAIR Mohamed IMT/OLN; Jon Shallow; Xialiang (Frank); [email-masked]; Mortensen, Andrew
Objet : Re: [Dots] confusion about mitigation trigger on loss of signal (was: several comments on draft-ietf-dots-architecture-06)

Agreed.

-Tiru

Cheers,
Med

Hi Med,

Cheers,
-Tiru

====================

Hi Andrew,

Cheers,
Med

Hi Tiru,

See inline.

Regards

Jon

Hi Jon,

~Jon

Regards,
-Tiru

Regards

Jon

andrew

[EXTERNAL EMAIL]
Hi Andrew,

1)
OLD:

NEW:

2.

Cheers,
-Tiru

…snip...

andrew

---

From: "Jon Shallow" <[email-masked]>
Date: Tue, 24 Jul 2018 13:05:55 +0100

Hi Med,

The NEW: text works for me – simple to implement with negligible code changes.

Regards

Jon

From: Dots [mailto: [email-masked]] On Behalf Of [email-masked]
Sent: 24 July 2018 12:35
To: Jon Shallow; 'Konda, Tirumaleswar Reddy'; Xialiang (Frank); [email-masked]; Mortensen, Andrew
Subject: Re: [Dots] confusion about mitigation trigger on loss of signal (was: several comments on draft-ietf-dots-architecture-06)

Tiru, Jon,

OLD: 

NEW:

Cheers,

Med

Hi Tiru,

See inline Jon1.

Regards

Jon

Hi Jon,

 

trigger-mitigation:

…

[TR] NEW:

Jon1> Good for me.

~Jon1

-Tiru

~Jon

Regards,

-Tiru

  _____  

Regards

Jon

andrew

[EXTERNAL EMAIL]

Hi Andrew,

1)

OLD:

session is lost. 

NEW:

2. 

Cheers,

-Tiru

  _____  

…snip...

threshold is reached.

andrew

---

From: <[email-masked]>
Date: Tue, 24 Jul 2018 12:21:16 +0000

Jon,

I’m hesitating to add text about the GW behavior as many cases can be considered (client-domain GW, server-domain GWs) and leave this implementation- and policy-based. For example:

·         a client-domain GW may have access to local information to determine whether the loss of a signal with a local client is due to an ongoing attack or to another cause. Emulating a failure with an upstream server or server-domain GW won’t be needed if a failure is not due to an attack. Emulating the signal loss will be even considered as a privacy concern as it reveals networking issues encountered in a client domain (that are not due to DDoS attacks).

·         a server-domain may be instructed to not relay requests with trigger-mitigation=false to the server but maintains a local copy of those requests. Once the signal is lost with a peer dots client, it triggers a signaling request with an immediate effect based on pre-configured requests it maintains for that client.

Cheers,
Med

De : Dots [mailto:[email-masked]] De la part de Jon Shallow
Envoyé : mardi 24 juillet 2018 13:36
À : 'Konda, Tirumaleswar Reddy'; Xialiang (Frank); [email-masked]; Mortensen, Andrew
Objet : Re: [Dots] confusion about mitigation trigger on loss of signal (was: several comments on draft-ietf-dots-architecture-06)

Hi Tiru,

Regards

Jon

Hi Jon,

-Tiru

See inline Jon1.

Regards

Jon

Hi Jon,

[TR] NEW:

Jon1> Good for me.
~Jon1
-Tiru

~Jon

Regards,
-Tiru

Regards

Jon

andrew

[EXTERNAL EMAIL]
Hi Andrew,

1)
OLD:

NEW:

2.

Cheers,
-Tiru

…snip...

andrew

---

From: "Konda, Tirumaleswar Reddy" <[email-masked]>
Date: Tue, 24 Jul 2018 13:34:21 +0000

Hi Med,

Please see inline [TR3]

From: [email-masked] [mailto:[email-masked]]
Sent: Tuesday, July 24, 2018 4:47 PM
To: Konda, Tirumaleswar Reddy <[email-masked]>; Jon Shallow <[email-masked]>; 'Mortensen, Andrew' <[email-masked]>; Xialiang (Frank) <[email-masked]>; [email-masked]
Subject: RE: [Dots] confusion about mitigation trigger on loss of signal (was: several comments on draft-ietf-dots-architecture-06)

Please see inline.

Cheers,
Med

Please see inline [TR2]

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]]
Sent: Tuesday, July 24, 2018 4:36 PM
To: Konda, Tirumaleswar Reddy <[email-masked]<mailto:[email-masked]>>; Jon Shallow <[email-masked]<mailto:[email-masked]>>; 'Mortensen, Andrew' <[email-masked]<mailto:[email-masked]>>; Xialiang (Frank) <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: RE: [Dots] confusion about mitigation trigger on loss of signal (was: several comments on draft-ietf-dots-architecture-06)

Please see inline.

Cheers,
Med

Hi Med,

Please see inline [TR]

Please see inline.

Cheers,
Med

[TR3] Thanks for the clarification. In this case, the appropriate state to transition after the attack has stopped and the client has not withdrawn the mitigation request and the lifetime is valid is 3 (i.e. Attack has stopped and the DOTS client can withdraw the mitigation request), the status parameter will be modified to ‘8’ after the expiry of the lifetime.

-Tiru

Regards

Jon

andrew

[EXTERNAL EMAIL]
Hi Andrew,

1)
OLD:

NEW:

2.

Cheers,
-Tiru

…snip...

andrew

---

From: "Konda, Tirumaleswar Reddy" <[email-masked]>
Date: Tue, 24 Jul 2018 13:42:23 +0000

I don’t think “local traffic observation” will cause the mitigation to terminate, the mitigator will continue to scrub the traffic (though the attack has stopped, but the client has not withdrawn the mitigation and the lifetime is valid).

-Tiru

From: [email-masked] [mailto:[email-masked]]
Sent: Tuesday, July 24, 2018 5:05 PM
To: Jon Shallow <[email-masked]>; Konda, Tirumaleswar Reddy <[email-masked]>; Xialiang (Frank) <[email-masked]>; [email-masked]; Mortensen, Andrew <[email-masked]>
Subject: RE: [Dots] confusion about mitigation trigger on loss of signal (was: several comments on draft-ietf-dots-architecture-06)

OLD:

NEW:

Cheers,
Med

Hi Tiru,

See inline Jon1.

Regards

Jon

Hi Jon,

[TR] NEW:

Jon1> Good for me.
~Jon1
-Tiru

~Jon

Regards,
-Tiru

Regards

Jon

andrew

[EXTERNAL EMAIL]
Hi Andrew,

1)
OLD:

NEW:

2.

Cheers,
-Tiru

…snip...

andrew

---

From: <[email-masked]>
Date: Tue, 24 Jul 2018 13:55:30 +0000

Re-,

I suspect the disconnect is that you are assuming that the lifetime is the one of the ** actual attack mitigation **, while I assume it is the one on ** the preconfigured mitigation request**. With my assumption, “local traffic observation” makes sense, otherwise the traffic will be scrubbed even if the attack has ceased.

Does this clarify your concern?

Cheers,
Med

De : Konda, Tirumaleswar Reddy [mailto:[email-masked]]
Envoyé : mardi 24 juillet 2018 15:42
À : BOUCADAIR Mohamed IMT/OLN; Jon Shallow; Xialiang (Frank); [email-masked]; Mortensen, Andrew
Objet : RE: [Dots] confusion about mitigation trigger on loss of signal (was: several comments on draft-ietf-dots-architecture-06)

-Tiru

OLD:

NEW:

Cheers,
Med

Hi Tiru,

See inline Jon1.

Regards

Jon

Hi Jon,

[TR] NEW:

Jon1> Good for me.
~Jon1
-Tiru

~Jon

Regards,
-Tiru

Regards

Jon

andrew

[EXTERNAL EMAIL]
Hi Andrew,

1)
OLD:

NEW:

2.

Cheers,
-Tiru

…snip...

andrew

---

From: <[email-masked]>
Date: Tue, 24 Jul 2018 14:03:41 +0000

Re-,

==
==

If the lifetime expires, the pre-configured request will be removed from the server’s table.

If we assume that a pre-configured request can be maintained by the server independently of the duration and number of active attacks matching that request, the nominal state would be to transition back to 8 after an attack is mitigated and the lifetime is still valid.

Cheers,
Med

De : Konda, Tirumaleswar Reddy [mailto:[email-masked]]
Envoyé : mardi 24 juillet 2018 15:34
À : BOUCADAIR Mohamed IMT/OLN; Jon Shallow; 'Mortensen, Andrew'; Xialiang (Frank); [email-masked]
Objet : RE: [Dots] confusion about mitigation trigger on loss of signal (was: several comments on draft-ietf-dots-architecture-06)

Hi Med,

Please see inline [TR3]

Please see inline.

Cheers,
Med

Please see inline [TR2]

Please see inline.

Cheers,
Med

Hi Med,

Please see inline [TR]

Please see inline.

Cheers,
Med

-Tiru

Regards

Jon

andrew

[EXTERNAL EMAIL]
Hi Andrew,

1)
OLD:

NEW:

2.

Cheers,
-Tiru

…snip...

andrew

---

From: "Konda, Tirumaleswar Reddy" <[email-masked]>
Date: Tue, 24 Jul 2018 14:04:52 +0000

Yes, we should probably add a line to avoid the confusion.

-Tiru

From: [email-masked] [mailto:[email-masked]]
Sent: Tuesday, July 24, 2018 7:26 PM
To: Konda, Tirumaleswar Reddy <[email-masked]>; Jon Shallow <[email-masked]>; Xialiang (Frank) <[email-masked]>; [email-masked]; Mortensen, Andrew <[email-masked]>
Subject: RE: [Dots] confusion about mitigation trigger on loss of signal (was: several comments on draft-ietf-dots-architecture-06)

Cheers,
Med

-Tiru

OLD:

NEW:

Cheers,
Med

Hi Tiru,

See inline Jon1.

Regards

Jon

Hi Jon,

[TR] NEW:

Jon1> Good for me.
~Jon1
-Tiru

~Jon

Regards,
-Tiru

Regards

Jon

andrew

[EXTERNAL EMAIL]
Hi Andrew,

1)
OLD:

NEW:

2.

Cheers,
-Tiru

…snip...

andrew

---

From: "Konda, Tirumaleswar Reddy" <[email-masked]>
Date: Tue, 24 Jul 2018 14:18:20 +0000

The problem with direct transition from 2 to 8 means DOTS client will never learn the DDoS attack details (e.g. “attack has stopped” and the attack metrics).
The DOTS server should first transmit status 3 and then transition to 8.

-Tiru

From: [email-masked] [mailto:[email-masked]]
Sent: Tuesday, July 24, 2018 7:34 PM
To: Konda, Tirumaleswar Reddy <[email-masked]>; Jon Shallow <[email-masked]>; 'Mortensen, Andrew' <[email-masked]>; Xialiang (Frank) <[email-masked]>; [email-masked]
Subject: RE: [Dots] confusion about mitigation trigger on loss of signal (was: several comments on draft-ietf-dots-architecture-06)

==

Cheers,
Med

Hi Med,

Please see inline [TR3]

Please see inline.

Cheers,
Med

Please see inline [TR2]

Please see inline.

Cheers,
Med

Hi Med,

Please see inline [TR]

Please see inline.

Cheers,
Med

-Tiru

Regards

Jon

andrew

[EXTERNAL EMAIL]
Hi Andrew,

1)
OLD:

NEW:

2.

Cheers,
-Tiru

…snip...

andrew

---

From: <[email-masked]>
Date: Tue, 24 Jul 2018 14:26:46 +0000

Re-,

Yes, you are right.

Actually, I was silent about intermediate transitions as those must be similar for both immediate and preconfigured requests.

Cheers,
Med

De : Konda, Tirumaleswar Reddy [mailto:[email-masked]]
Envoyé : mardi 24 juillet 2018 16:18
À : BOUCADAIR Mohamed IMT/OLN; Jon Shallow; 'Mortensen, Andrew'; Xialiang (Frank); [email-masked]
Objet : RE: [Dots] confusion about mitigation trigger on loss of signal (was: several comments on draft-ietf-dots-architecture-06)

-Tiru

==

Cheers,
Med

Hi Med,

Please see inline [TR3]

Please see inline.

Cheers,
Med

Please see inline [TR2]

Please see inline.

Cheers,
Med

Hi Med,

Please see inline [TR]

Please see inline.

Cheers,
Med

-Tiru

Regards

Jon

andrew

[EXTERNAL EMAIL]
Hi Andrew,

1)
OLD:

NEW:

2.

Cheers,
-Tiru

…snip...

andrew

---

From: <[email-masked]>
Date: Tue, 24 Jul 2018 14:29:26 +0000

Re-

Great to see that we converged.

I double checked the text. IMHO, the text is clear about the definition of the lifetime (which applies for both immediate and preconfigured ones):

   lifetime:   Lifetime of the mitigation request in seconds.  The
      RECOMMENDED lifetime of a mitigation request is 3600 seconds --
      this value was chosen to be long enough so that refreshing is not
      typically a burden on the DOTS client, while expiring the request
      where the client has unexpectedly quit in a timely manner.  DOTS
      clients MUST include this parameter in their mitigation requests.
      Upon the expiry of this lifetime, and if the request is not
      refreshed, the mitigation request is removed.

I don’t think a change is required.

Cheers,
Med

De : Konda, Tirumaleswar Reddy [mailto:[email-masked]]
Envoyé : mardi 24 juillet 2018 16:05
À : BOUCADAIR Mohamed IMT/OLN; Jon Shallow; Xialiang (Frank); [email-masked]; Mortensen, Andrew
Objet : RE: [Dots] confusion about mitigation trigger on loss of signal (was: several comments on draft-ietf-dots-architecture-06)

-Tiru

Cheers,
Med

-Tiru

OLD:

NEW:

Cheers,
Med

Hi Tiru,

See inline Jon1.

Regards

Jon

Hi Jon,

[TR] NEW:

Jon1> Good for me.
~Jon1
-Tiru

~Jon

Regards,
-Tiru

Regards

Jon

andrew

[EXTERNAL EMAIL]
Hi Andrew,

1)
OLD:

NEW:

2.

Cheers,
-Tiru

…snip...

andrew

---

From: "Konda, Tirumaleswar Reddy" <[email-masked]>
Date: Tue, 24 Jul 2018 14:46:29 +0000

We may want to say for pre-configured request status ‘3’ will be transmitted few times, and then status 8 will be transmitted till the mitigation is withdrawn or lifetime expires. But for immediate requests status ‘3’ will be transmitted till the mitigation is withdrawn or lifetime expires.

-Tiru

From: [email-masked] [mailto:[email-masked]]
Sent: Tuesday, July 24, 2018 7:57 PM
To: Konda, Tirumaleswar Reddy <[email-masked]>; Jon Shallow <[email-masked]>; 'Mortensen, Andrew' <[email-masked]>; Xialiang (Frank) <[email-masked]>; [email-masked]
Subject: RE: [Dots] confusion about mitigation trigger on loss of signal (was: several comments on draft-ietf-dots-architecture-06)

Yes, you are right.

Cheers,
Med

-Tiru

==

Cheers,
Med

Hi Med,

Please see inline [TR3]

Please see inline.

Cheers,
Med

Please see inline [TR2]

Please see inline.

Cheers,
Med

Hi Med,

Please see inline [TR]

Please see inline.

Cheers,
Med

-Tiru

Regards

Jon

andrew

[EXTERNAL EMAIL]
Hi Andrew,

1)
OLD:

NEW:

2.

Cheers,
-Tiru

…snip...

andrew

---

From: "Konda, Tirumaleswar Reddy" <[email-masked]>
Date: Tue, 24 Jul 2018 14:53:14 +0000

Yup, thanks for checking.

-Tiru

From: [email-masked] [mailto:[email-masked]]
Sent: Tuesday, July 24, 2018 7:59 PM
To: Konda, Tirumaleswar Reddy <[email-masked]>; Jon Shallow <[email-masked]>; Xialiang (Frank) <[email-masked]>; [email-masked]; Mortensen, Andrew <[email-masked]>
Subject: RE: [Dots] confusion about mitigation trigger on loss of signal (was: several comments on draft-ietf-dots-architecture-06)

Cheers,
Med

-Tiru

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]]
Sent: Tuesday, July 24, 2018 7:26 PM
To: Konda, Tirumaleswar Reddy <[email-masked]<mailto:[email-masked]>>; Jon Shallow <[email-masked]<mailto:[email-masked]>>; Xialiang (Frank) <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; Mortensen, Andrew <[email-masked]<mailto:[email-masked]>>
Subject: RE: [Dots] confusion about mitigation trigger on loss of signal (was: several comments on draft-ietf-dots-architecture-06)

Cheers,
Med

-Tiru

OLD:

NEW:

Cheers,
Med

Hi Tiru,

See inline Jon1.

Regards

Jon

Hi Jon,

[TR] NEW:

Jon1> Good for me.
~Jon1
-Tiru

~Jon

Regards,
-Tiru

Regards

Jon

andrew

[EXTERNAL EMAIL]
Hi Andrew,

1)
OLD:

NEW:

2.

Cheers,
-Tiru

…snip...

andrew

---

From: <[email-masked]>
Date: Tue, 24 Jul 2018 15:03:44 +0000

Re-,

Agree. You may find the proposed changes 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 : Konda, Tirumaleswar Reddy [mailto:[email-masked]]
Envoyé : mardi 24 juillet 2018 16:46
À : BOUCADAIR Mohamed IMT/OLN; Jon Shallow; 'Mortensen, Andrew'; Xialiang (Frank); [email-masked]
Objet : RE: [Dots] confusion about mitigation trigger on loss of signal (was: several comments on draft-ietf-dots-architecture-06)

-Tiru

Yes, you are right.

Cheers,
Med

-Tiru

==

Cheers,
Med

Hi Med,

Please see inline [TR3]

Please see inline.

Cheers,
Med

Please see inline [TR2]

Please see inline.

Cheers,
Med

Hi Med,

Please see inline [TR]

Please see inline.

Cheers,
Med

-Tiru

Regards

Jon

andrew

[EXTERNAL EMAIL]
Hi Andrew,

1)
OLD:

NEW:

2.

Cheers,
-Tiru

…snip...

andrew

---

From: "Konda, Tirumaleswar Reddy" <[email-masked]>
Date: Wed, 25 Jul 2018 09:05:22 +0000

Hi Med,

Update look good. Nits listed below:

1.
OLD:
This is a mandatory attribute except for mitigations with 'status" code set to 8.
NEW:
This is a mandatory attribute except for mitigation with 'status" code set to 8.

2. For status code 3, instead of saying "few times" we may want to be specific and instead say "MAX_RETRANSMIT times"

3. Replace "local traffic observation" with "observation of traffic to the attack target".

Cheers,
-Tiru

From: [email-masked] [mailto:[email-masked]]
Sent: Tuesday, July 24, 2018 8:34 PM
To: Konda, Tirumaleswar Reddy <[email-masked]>; Jon Shallow <[email-masked]>; 'Mortensen, Andrew' <[email-masked]>; Xialiang (Frank) <[email-masked]>; [email-masked]
Subject: RE: [Dots] confusion about mitigation trigger on loss of signal (was: several comments on draft-ietf-dots-architecture-06)

Cheers,
Med

-Tiru

Yes, you are right.

Cheers,
Med

-Tiru

==

Cheers,
Med

Hi Med,

Please see inline [TR3]

Please see inline.

Cheers,
Med

Please see inline [TR2]

Please see inline.

Cheers,
Med

Hi Med,

Please see inline [TR]

Please see inline.

Cheers,
Med

-Tiru

Regards

Jon

andrew

[EXTERNAL EMAIL]
Hi Andrew,

1)
OLD:

NEW:

2.

Cheers,
-Tiru

…snip...

andrew

---

From: <[email-masked]>
Date: Wed, 25 Jul 2018 09:23:22 +0000

Hi Tiru,

Thanks for the comments. Please see inline.

Cheers,
Med

De : Konda, Tirumaleswar Reddy [mailto:[email-masked]]
Envoyé : mercredi 25 juillet 2018 11:05
À : BOUCADAIR Mohamed IMT/OLN; Jon Shallow; 'Mortensen, Andrew'; Xialiang (Frank); [email-masked]
Objet : RE: [Dots] confusion about mitigation trigger on loss of signal (was: several comments on draft-ietf-dots-architecture-06)

Hi Med,

1.
OLD:

[Med] I changed the text to:

“This is a mandatory attribute except for a mitigation with 'status’ code set to 8.”

[Med] OK, but I prefer to not mix the behavior with retransmission specific parameters. I made this change: s/few times/3 times.

[Med] Fixed. Thanks.

Cheers,
-Tiru

Cheers,
Med

-Tiru

Yes, you are right.

Cheers,
Med

-Tiru

==

Cheers,
Med

Hi Med,

Please see inline [TR3]

Please see inline.

Cheers,
Med

Please see inline [TR2]

Please see inline.

Cheers,
Med

Hi Med,

Please see inline [TR]

Please see inline.

Cheers,
Med

-Tiru

Regards

Jon

andrew

[EXTERNAL EMAIL]
Hi Andrew,

1)
OLD:

NEW:

2.

Cheers,
-Tiru

…snip...

andrew

---

From: "Konda, Tirumaleswar Reddy" <[email-masked]>
Date: Wed, 25 Jul 2018 09:32:09 +0000

We should probably say “Tc times. Tc SHOULD be configurable and SHOULD have a default of 4.”

-Tiru

From: [email-masked] [mailto:[email-masked]]
Sent: Wednesday, July 25, 2018 2:53 PM
To: Konda, Tirumaleswar Reddy <[email-masked]>; Jon Shallow <[email-masked]>; 'Mortensen, Andrew' <[email-masked]>; Xialiang (Frank) <[email-masked]>; [email-masked]
Subject: RE: [Dots] confusion about mitigation trigger on loss of signal (was: several comments on draft-ietf-dots-architecture-06)

Cheers,
Med

Hi Med,

1.
OLD:

Cheers,
-Tiru

Cheers,
Med

-Tiru

Yes, you are right.

Cheers,
Med

-Tiru

==

Cheers,
Med

Hi Med,

Please see inline [TR3]

Please see inline.

Cheers,
Med

Please see inline [TR2]

Please see inline.

Cheers,
Med

Hi Med,

Please see inline [TR]

Please see inline.

Cheers,
Med

-Tiru

Regards

Jon

andrew

[EXTERNAL EMAIL]
Hi Andrew,

1)
OLD:

NEW:

2.

Cheers,
-Tiru

…snip...

andrew

---

From: <[email-masked]>
Date: Wed, 25 Jul 2018 11:05:58 +0000

Re-,

I’m hesitating to add another yet configuration parameter.

Is there any particular reason to pick 4 as instead of 3 (which is the default value of MAX_RETRANSMIT you initially proposed)?

Cheers,
Med

De : Konda, Tirumaleswar Reddy [mailto:[email-masked]]
Envoyé : mercredi 25 juillet 2018 11:32
À : BOUCADAIR Mohamed IMT/OLN; Jon Shallow; 'Mortensen, Andrew'; Xialiang (Frank); [email-masked]
Objet : RE: [Dots] confusion about mitigation trigger on loss of signal (was: several comments on draft-ietf-dots-architecture-06)

-Tiru

Cheers,
Med

Hi Med,

1.
OLD:

Cheers,
-Tiru

Cheers,
Med

-Tiru

Yes, you are right.

Cheers,
Med

-Tiru

==

Cheers,
Med

Hi Med,

Please see inline [TR3]

Please see inline.

Cheers,
Med

Please see inline [TR2]

Please see inline.

Cheers,
Med

Hi Med,

Please see inline [TR]

Please see inline.

Cheers,
Med

-Tiru

Regards

Jon

andrew

[EXTERNAL EMAIL]
Hi Andrew,

1)
OLD:

NEW:

2.

Cheers,
-Tiru

…snip...

andrew

---

From: "Konda, Tirumaleswar Reddy" <[email-masked]>
Date: Wed, 25 Jul 2018 11:09:13 +0000

The default value of max transmissions to handle packet loss is 7 in STUN and 4 in CoAP (3 looks more aggressive).

-Tiru

From: Dots [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Wednesday, July 25, 2018 4:36 PM
To: Konda, Tirumaleswar Reddy <[email-masked]>; Jon Shallow <[email-masked]>; 'Mortensen, Andrew' <[email-masked]>; Xialiang (Frank) <[email-masked]>; [email-masked]
Subject: Re: [Dots] confusion about mitigation trigger on loss of signal (was: several comments on draft-ietf-dots-architecture-06)

Cheers,
Med

-Tiru

Cheers,
Med

Hi Med,

1.
OLD:

Cheers,
-Tiru

Cheers,
Med

-Tiru

Yes, you are right.

Cheers,
Med

-Tiru

==

Cheers,
Med

Hi Med,

Please see inline [TR3]

Please see inline.

Cheers,
Med

Please see inline [TR2]

Please see inline.

Cheers,
Med

Hi Med,

Please see inline [TR]

Please see inline.

Cheers,
Med

-Tiru

Regards

Jon

andrew

[EXTERNAL EMAIL]
Hi Andrew,

1)
OLD:

NEW:

2.

Cheers,
-Tiru

…snip...

andrew

---

From: <[email-masked]>
Date: Thu, 26 Jul 2018 06:10:51 +0000

Hi Tiru,

You are right about the default max-retransmit value in CoAP… but I was referring to the recommended max-retransmit value we are using for the signal channel, which is 3.

As both values are guesstimate and very close, I went with 4.

The updated files (including the diff) are available at: https://github.com/boucadair/draft-ietf-dots-signal-channel

Cheers,

Med

De : Konda, Tirumaleswar Reddy [mailto:[email-masked]]
Envoyé : mercredi 25 juillet 2018 13:09
À : BOUCADAIR Mohamed IMT/OLN; Jon Shallow; 'Mortensen, Andrew'; Xialiang (Frank); [email-masked]
Objet : RE: [Dots] confusion about mitigation trigger on loss of signal (was: several comments on draft-ietf-dots-architecture-06)

-Tiru

Cheers,
Med

-Tiru

Cheers,
Med

Hi Med,

1.
OLD:

Cheers,
-Tiru

Cheers,
Med

-Tiru

Yes, you are right.

Cheers,
Med

-Tiru

==

Cheers,
Med

Hi Med,

Please see inline [TR3]

Please see inline.

Cheers,
Med

Please see inline [TR2]

Please see inline.

Cheers,
Med

Hi Med,

Please see inline [TR]

Please see inline.

Cheers,
Med

-Tiru

Regards

Jon

andrew

[EXTERNAL EMAIL]
Hi Andrew,

1)
OLD:

NEW:

2.

Cheers,
-Tiru

…snip...

andrew

---

From: "Konda, Tirumaleswar Reddy" <[email-masked]>
Date: Thu, 26 Jul 2018 10:02:37 +0000

Update looks good, replace "DOTS requests" with "mitigation requests" throughout the doc.

-Tiru

From: [email-masked] <[email-masked]>
Sent: Thursday, July 26, 2018 11:41 AM
To: Konda, Tirumaleswar Reddy <[email-masked]>; Jon Shallow <[email-masked]>; 'Mortensen, Andrew' <[email-masked]>; Xialiang (Frank) <[email-masked]>; [email-masked]
Subject: RE: [Dots] confusion about mitigation trigger on loss of signal (was: several comments on draft-ietf-dots-architecture-06)

Cheers,

Med

-Tiru

From: Dots [mailto:[email-masked]] On Behalf Of [email-masked]<mailto:[email-masked]>
Sent: Wednesday, July 25, 2018 4:36 PM
To: Konda, Tirumaleswar Reddy <[email-masked]<mailto:[email-masked]>>; Jon Shallow <[email-masked]<mailto:[email-masked]>>; 'Mortensen, Andrew' <[email-masked]<mailto:[email-masked]>>; Xialiang (Frank) <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: Re: [Dots] confusion about mitigation trigger on loss of signal (was: several comments on draft-ietf-dots-architecture-06)

Cheers,
Med

-Tiru

Cheers,
Med

Hi Med,

1.
OLD:

Cheers,
-Tiru

Cheers,
Med

-Tiru

Yes, you are right.

Cheers,
Med

-Tiru

==

Cheers,
Med

Hi Med,

Please see inline [TR3]

Please see inline.

Cheers,
Med

Please see inline [TR2]

Please see inline.

Cheers,
Med

Hi Med,

Please see inline [TR]

Please see inline.

Cheers,
Med

-Tiru

Regards

Jon

andrew

[EXTERNAL EMAIL]
Hi Andrew,

1)
OLD:

NEW:

2.

Cheers,
-Tiru

…snip...

andrew

---

From: <[email-masked]>
Date: Thu, 26 Jul 2018 11:33:10 +0000

Re-,

OK.

I went through the document to find where it makes sense to replace “DOTS requests” as you suggested, but concluded that al occurrences are correct. Corresponding statements apply to any DOTS requests type (including, mitigation request, mitigation withdrawal, …). Will leave the text as it is. Thanks.

Cheers,
Med

De : Konda, Tirumaleswar Reddy [mailto:[email-masked]]
Envoyé : jeudi 26 juillet 2018 12:03
À : BOUCADAIR Mohamed IMT/OLN; Jon Shallow; 'Mortensen, Andrew'; Xialiang (Frank); [email-masked]
Objet : RE: [Dots] confusion about mitigation trigger on loss of signal (was: several comments on draft-ietf-dots-architecture-06)

-Tiru

Cheers,

Med

-Tiru

Cheers,
Med

-Tiru

Cheers,
Med

Hi Med,

1.
OLD:

Cheers,
-Tiru

Cheers,
Med

-Tiru

Yes, you are right.

Cheers,
Med

-Tiru

==

Cheers,
Med

Hi Med,

Please see inline [TR3]

Please see inline.

Cheers,
Med

Please see inline [TR2]

Please see inline.

Cheers,
Med

Hi Med,

Please see inline [TR]

Please see inline.

Cheers,
Med

-Tiru

Regards

Jon

andrew

[EXTERNAL EMAIL]
Hi Andrew,

1)
OLD:

NEW:

2.

Cheers,
-Tiru

…snip...

andrew