Re: [Dots] Dots Digest, Vol 45, Issue 3

[Yuhei Hayashi <[e-mail]>]

Hi, all

Thank you for comments and feedback.

> ** 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)? 
[Yuhei]
It's just my mistake.
I want to express that request (1) or (2) can be selected by the network's policy as below.

<alt> [triggered by telemetry/monitoring system]
      (1)[telemetry system]->[orchestrator]: DOTS Mitigation Request
      
      [triggered by network administrator]
      (2)[network admin]->[orchestrator]: DOTS Mitigation Request

> ** Is there an implicit out-of-band channel between the orchestrator and network admins to enable (2)?  
[Yuhei]
Yes.

> Why does the network admin have to be a DOTS client rather than a function in the orchestrator (out of scope for DOTS)?
[Yuhei]
I referred the current use-case draft, and it describes use case (fig. 4) where network admin has DOTS client functionality.
https://www.ietf.org/id/draft-ietf-dots-use-cases-16.txt

Hence, I described so, however, I also think it can be a function of orchestrator.

> ** Will the mitigation status requests back to the telemetry system and network admins in (1) and (2) be the same? 
[Yuhei]
Yes.

> ** Is the traffic examined by the DMS the same as seen by the telemetry systems?
[Yuhei]
Yes.

> 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? 
[Yuhei]
Töma's opinion is correct for me.
> 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.

After request (3), DMS examines the suspicious traffic redirected by the routers, with information of target IP address or IP prefix reported by DOTS client.

> This draft is a) [imperfectly] duplicative of existing functionality 
> such as flowspec 
[Yuhei]
What I'd like to propose is to use DOTS protocol, not flowspec, in  "(4) [DMS]->[orchestrator]: DOTS Mitigation Request".
And I'd like DOTS client to send attacker information at the time to filter attack traffic correctly at "(5) [orchestrator]->[routers/switch]".

In the current DOTS specification, sending attacker information is out of scope, so I’d like to expand it.

> 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.
[Yuhei]
I'm searching those who has same concepts or requirements that DOTS client send attacker information by signal channel.

We are looking for more proponents of this draft, and are under discussion with some DOTS folks.
Actually, I received some positive feedback and I believe that this proposal useful for further work of DOTS-WG.

Thanks,
Yuhei


On 2018/11/04 4:00, [e-mail] wrote:
> Send Dots mailing list submissions to
> 	[e-mail]
> 
> To subscribe or unsubscribe via the World Wide Web, visit
> 	https://www.ietf.org/mailman/listinfo/dots
> or, via email, send a message with subject or body 'help' to
> 	[e-mail]
> 
> You can reach the person managing the list at
> 	[e-mail]
> 
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Dots digest..."
> 
> 
> 
> Today's Topics:
> 
>     1. Workflow question about
>        draft-h-dots-mitigation-offload-expansion-00 (Roman Danyliw)
>     2. Re: Workflow question about
>        draft-h-dots-mitigation-offload-expansion-00 (T?ma Gavrichenkov)
>     3. Re: Workflow question about
>        draft-h-dots-mitigation-offload-expansion-00 (Dobbins, Roland)
> 
> 
> 
> _______________________________________________
> Dots mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dots
> 
-----------------------------------------
Nippon Telegraph and Telephone Corporation
  Network Service Systems Laboratories
   Transport Service Platform Innovation Project
    Transport Service Systems Development Project
     Yuhei Hayashi
0422-59-3485
[e-mail]