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: Wednesday, December 12, 2018 3:41 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,
> 
> >> 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 

Yes, but in your case the link b/w DMS and Orchestrator should not be congested, the offload request should be sent before a configured threshold is hit.

Cheers,
-Tiru

> 
> 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]
> 
> _______________________________________________
> Dots mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dots