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

From: "Konda, Tirumaleswar Reddy" <[email-masked]>
Date: Thu, 6 Dec 2018 14:20:52 +0000

> -----Original Message-----
> From: Dots <[email-masked]> On Behalf Of Yuhei Hayashi
> Sent: Thursday, November 29, 2018 2:15 PM
> To: [email-masked]
> 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-00
> 
> 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
> [email-masked]
> 
> _______________________________________________
> Dots mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dots

---

From: Yuhei Hayashi <[email-masked]>
Date: Mon, 10 Dec 2018 20:56:35 +0900

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.

I'm considering to add "inter-domain" DDoS offload usecase to my draft.
I will also consider which channel,expanded signal channel or data channel, is suitable to send attacker information under attack situation.

Thanks,
Yuhei

---

From: "Konda, Tirumaleswar Reddy" <[email-masked]>
Date: Mon, 10 Dec 2018 12:58:41 +0000

> Sent: Monday, December 10, 2018 5:27 PM
> To: [email-masked]
> Subject: Re: [Dots] draft-h-dots-mitigation-offload-expansion-00: Reasons why
> we want to standardize between DMS and orchestrator using DOTS
> 

If the DOTS data channel is capable of doing the job, Why do you see the need to extend the signal channel protocol ? 

>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

> >> 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.
> >>
> >> We want to use various and latest DMS in DDoS Orchestration usecase
> >> because DDoS attacks evolve day by day.
> >>
> >> 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.
> > 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
> >>

---

From: Yuhei Hayashi <[email-masked]>
Date: Wed, 12 Dec 2018 19:11:13 +0900

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.

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

---

From: "Konda, Tirumaleswar Reddy" <[email-masked]>
Date: Wed, 12 Dec 2018 10:38:41 +0000

> Sent: Wednesday, December 12, 2018 3:41 PM
> To: [email-masked]
> >> 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.
> >>>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.
> 
> - 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.

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

> >> Subject: Re: [Dots] draft-h-dots-mitigation-offload-expansion-00:
> >> Reasons why we want to standardize between DMS and orchestrator using
> >> DOTS
> >>
> >> 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 ?
> >
> >>
> >>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
> >>
> >>>> 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,
> >>>>
> >>>> https://datatracker.ietf.org/meeting/103/materials/minutes-103-dots
> >>>> -0
> >>>> 0
> >>>>
> >>>> 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.