Re: [Dots] draft-h-dots-mitigation-offload-expansion-00: Reasons why we want to standardize between DMS and orchestrator using DOTS

[Yuhei Hayashi <[e-mail]>]

Hi Tiru,

>> If the DOTS data channel is capable of doing the job, Why do you see the need to extend the signal channel protocol ?
Through this discussion, I get the feeling that it's not necessary to expand signal channel if the data channel can do the job about intra-domain DDoS offload usecase.
I will check whether the data channel can do the job or not through test of the usecase.

>>>From a protocol perspective, do you see any differences b/w "intra-domain" and "inter-domain" DDoS offload use cases ?
>> The new use cases is interesting to signal the attacker information when the mitigation is in progress, and the link b/w the DMS and Orchestrator won't be congested, so DOTS data channel can be used
>> to convey the drop-listed filtering rules.

So far, I consider inter-domain DDoS offload usecase like as below.
- Downstream NW has in-line DMS and upstream NW has Orchestrator.
- When downstream NW is attacked and the DMS is saturated, the downstream NW sends offload request with target and attacker information to the Orchestrator in upstream NW via link b/w the downstream NW and the upstream NW.
- In upstream NW, orchestrator orders routers to block the attack traffic using the target and attacker information.

Based on IETF 103 hackathon report, all of the data-channel communications fail in attack-time.
So I think DOTS data channel can't be used to convey attacker information about the usecase.
https://datatracker.ietf.org/meeting/103/materials/slides-103-dots-interop-report-from-ietf-103-hackathon-00

Thanks,
Yuhei

On 2018/12/10 21:58, Konda, Tirumaleswar Reddy wrote:
>> -----Original Message-----
>> From: Dots <[e-mail]> On Behalf Of Yuhei Hayashi
>> Sent: Monday, December 10, 2018 5:27 PM
>> To: [e-mail]
>> Subject: Re: [Dots] draft-h-dots-mitigation-offload-expansion-00: Reasons why
>> we want to standardize between DMS and orchestrator using DOTS
>>
>> This email originated from outside of the organization. Do not click links or
>> open attachments unless you recognize the sender and know the content is safe.
>>
>> Hi Tiru,
>>
>> Thank you for advising!
>> I will consider to use not only expanded signal channel but also data channel to
>> the intra-domain DDoS offload usecase.
> 
> If the DOTS data channel is capable of doing the job, Why do you see the need to extend the signal channel protocol ?
> 
>>
>> I'm considering to add "inter-domain" DDoS offload usecase to my draft.
> 
>>From a protocol perspective, do you see any differences b/w "intra-domain" and "inter-domain" DDoS offload use cases ?
> 
>> I will also consider which channel,expanded signal channel or data channel, is
>> suitable to send attacker information under attack situation.
> 
> The new use cases is interesting to signal the attacker information when the mitigation is in progress, and the link b/w the DMS and Orchestrator won't be congested, so DOTS data channel can be used
> to convey the drop-listed filtering rules.
> 
> Cheers,
> -Tiru
> 
>>
>> Thanks,
>> Yuhei
>>
>> On 2018/12/06 23:20, Konda, Tirumaleswar Reddy wrote:
>>>> -----Original Message-----
>>>> From: Dots <[e-mail]> On Behalf Of Yuhei Hayashi
>>>> Sent: Thursday, November 29, 2018 2:15 PM
>>>> To: [e-mail]
>>>> Subject: [Dots] draft-h-dots-mitigation-offload-expansion-00: Reasons
>>>> why we want to standardize between DMS and orchestrator using DOTS
>>>>
>>>> This email originated from outside of the organization. Do not click
>>>> links or open attachments unless you recognize the sender and know the
>> content is safe.
>>>>
>>>> Hi Tiru, Flemming,
>>>>
>>>> Thank you for asking question for my draft
>>>> "draft-h-dots-mitigation-offload- expansion-00" in IETF103.
>>>>
>>>> I'm sorry I'm late for answering the question.
>>>> These questions are similar so I will answer the question in this one thread.
>>>>> Q: (Tiru Reddy) Why the DMS must use DOTS to talk to the orchestrator?
>>>>> Q: (Flemming Andreasen) Is it worthwhile to standardize the
>>>>> communication
>>>> between the DMS with the orchestrator?
>>>> https://datatracker.ietf.org/meeting/103/materials/minutes-103-dots-0
>>>> 0
>>>>
>>>> We want to use various and latest DMS in DDoS Orchestration usecase
>>>> because DDoS attacks evolve day by day.
>>>>
>>>> However, syslog format varies from DMS to DMS.
>>>> There is no standardized IF or API between DMS and Orchestrator, so
>>>> we have to develop IF module on orchestrator for adapting the DMS to the
>> orchestrator.
>>>> I think it is obstacle to use various DMS in DDoS Orchestration usecase.
>>>>
>>>> We are paying attention to DOTS, which is being debated the most as a
>>>> standard for signaling related to DDoS.
>>>
>>> The list of top attackers could be huge, DOTS signal channel is supposed to
>> have small message sizes.
>>> DOTS data channel can be used to managing filters. Why not use DOTS data
>> channel to block the traffic from the top N attackers to the target ?
>>>
>>> Cheers,
>>> -Tiru
>>>
>>>>
>>>> Thanks,
>>>> Yuhei
>>>>
>>>> -----------------------------------------
>>>> 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
>>>
>> -----------------------------------------
>> 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
> 
> _______________________________________________
> 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]