Subject: [Dots] Workflow question about draft-h-dots-mitigation-offload-expansion-00

From: Roman Danyliw <[email-masked]>
Date: Sat, 3 Nov 2018 02:14:40 +0000

Hello!
(chair hat off)

In reviewing draft-h-dots-mitigation-offload-expansion-00, I had a few questions about the sequence of events described in Figure #2.  For simplicity, I've numbered each of the steps in Figure 2 as follows:

(1) [telemetry system]->[orchestrator]: DOTS Mitigation Request
(2) [network admin]->[orchestrator]: DOTS Mitigation Request
(3) [orchestrator]->[routers/switch]: BGP redirect mitigation
(4) [DMS]->[orchestrator]: DOTS Mitigation Request
(5) [orchestrator]->[routers/switch]: BGP redirect mitigation

** After the telemetry system makes the mitigation request in (1), will the orchestrator block on a response awaiting for action from the network administrator (as the text notes that the 'network administrator' will confirm the request)? 

** Is there an implicit out-of-band channel between the orchestrator and network admins to enable (2)?  Why does the network admin have to be a DOTS client rather than a function in the orchestrator (out of scope for DOTS)?

** Will the mitigation status requests back to the telemetry system and network admins in (1) and (2) be the same?

** Is the traffic examined by the DMS the same as seen by the telemetry systems?  How was the DMS tasked to examine the traffic -- was that an implicit communication channel from the orchestrator?

** If the orchestrator tasked the routers/switches per (3) to handle the attack traffic, how did the DMS get involved in the mitigation?  What's the difference between the attack traffic handled by (3) and the DMS?  How is that coordination happening? 

Roman

---

From: Töma Gavrichenkov <[email-masked]>
Date: Sat, 3 Nov 2018 07:57:21 +0400

Hello all,

On Sat, Nov 3, 2018 at 6:15 AM Roman Danyliw <[email-masked]> wrote:
> [..]
> ** If the orchestrator tasked the routers/switches per (3) to handle
> the attack traffic, how did the DMS get involved in the mitigation?
> What's the difference between the attack traffic handled by (3)
> and the DMS?  How is that coordination happening?

1) I'm not the author of the draft, but as far as I understand it the
use case is as follows (and you might want to take that with a grain
of salt):

Actually, the orchestrator doesn't ask for handling the *attack*
traffic during the step 3. At this point, routers still have no clue
about what's the attack traffic is (they only know who's the target,
as reported by the telemetry system), so they just start routing *all*
of the inbound traffic (including legitimate one) coming towards the
target IP address or IP prefix, via the DMS.

2) Going through the same paragraph, I'm a little bit concerned about
the "top-talker" part. Under most conditions and assuming most common
mitigation boxes, it's either useless or even dangerous to do that
during a volume-based DDoS attack. I'd suggest to put, e.g., an
amplification example here, with port blocking done instead of IP
address blocking.

| Töma Gavrichenkov
| gpg: 2deb 97b1 0a3c 151d b67f 1ee5 00e7 94bc 4d08 9191
| mailto: [email-masked]
| fb: ximaera
| telegram: xima_era
| skype: xima_era
| tel. no: +7 916 515 49 58

---

From: "Dobbins, Roland" <[email-masked]>
Date: Sat, 3 Nov 2018 08:28:26 +0000

> use case is as follows (and you might want to take that with a grain

This draft is a) [imperfectly] duplicative of existing functionality 
such as flowspec and b) in need of further consideration and refinement, 
IMHO.

Suggest strongly that additional contributors with relevant technical 
and operational experience should be involved in re-working this draft 
from a conceptual level onwards.

--------------------------------------------
Roland Dobbins <[email-masked]>