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

[kaname nishizuka <[e-mail]>]

Hi Yuhei,

I'd advise you to keep the thread of discussions for readability and traceability (don't mix replies in one mail).
I can't see you're replying to whom.

Then, here is my comment:
The proposal of this draft is adding source IP address information in the signal channel.
Sometimes source IP address information is important, sometimes not.
I'd like to list up the cases source IP address information is useful (or not).

# useful protection with source IP address
Given source IP addresses of an attack is clear from a vantage point of an ISP:
  1. The attack is coming from a few number of specific source IP addresses
      - call home usecase can be classified here?
  2. The attack is coming from a particular group of source IP addresses
      - there could be some bias in distribution of attack sources of an AMP attack.

# the cases a protection with source IP address is not useful
  1. source IP addresses are spoofed(randomize)
      - source IP addresses are time varying
  2. widely distributed AMP attack with thousands of amplifying devices
      - stopping only a few of them is not effective


thanks,
Kaname



On 2018/11/05 11:12, Yuhei Hayashi wrote:
> 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]
>
> _______________________________________________
> Dots mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dots