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

["Konda, Tirumaleswar Reddy" <[e-mail]>]

> -----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