Subject: [Dots] Fwd: New Version Notification for draft-reddy-dots-telemetry-00.txt

From: tirumal reddy <[email-masked]>
Date: Fri, 5 Jul 2019 18:50:38 +0530

Hi all,

https://tools.ietf.org/html/draft-reddy-dots-telemetry-00 aims to enrich
DOTS protocols with various telemetry attributes allowing optimal DDoS
attack mitigation. This document specifies the normal traffic baseline and
attack traffic telemetry attributes a DOTS client can convey to its
DOTS server in the mitigation request, the mitigation status
telemetry attributes a DOTS server can communicate to a DOTS client, and
the mitigation efficacy telemetry attributes a DOTS client can communicate
to a DOTS server.  The telemetry attributes can assist the mitigator to
choose the DDoS mitigation techniques and perform optimal DDoS attack
mitigation.

Comments, suggestions, and questions are more than welcome.

Cheers,
-Tiru

---------- Forwarded message ---------
From: <[email-masked]>
Date: Fri, 5 Jul 2019 at 18:44
Subject: New Version Notification for draft-reddy-dots-telemetry-00.txt
To: Tirumaleswar Reddy <[email-masked]>, Ehud Doron <[email-masked]>,
Mohamed Boucadair <[email-masked]>

A new version of I-D, draft-reddy-dots-telemetry-00.txt
has been successfully submitted by Tirumaleswar Reddy and posted to the
IETF repository.

Name:           draft-reddy-dots-telemetry
Revision:       00
Title:          Distributed Denial-of-Service Open Threat Signaling (DOTS)
Telemetry
Document date:  2019-07-05
Group:          Individual Submission
Pages:          13
URL:
https://www.ietf.org/internet-drafts/draft-reddy-dots-telemetry-00.txt
Status:         https://datatracker.ietf.org/doc/draft-reddy-dots-telemetry/
Htmlized:       https://tools.ietf.org/html/draft-reddy-dots-telemetry-00
Htmlized:
https://datatracker.ietf.org/doc/html/draft-reddy-dots-telemetry

Abstract:
   This document aims to enrich DOTS signal channel protocol with
   various telemetry attributes allowing optimal DDoS attack mitigation.
   This document specifies the normal traffic baseline and attack
   traffic telemetry attributes a DOTS client can convey to its DOTS
   server in the mitigation request, the mitigation status telemetry
   attributes a DOTS server can communicate to a DOTS client, and the
   mitigation efficacy telemetry attributes a DOTS client can
   communicate to a DOTS server.  The telemetry attributes can assist
   the mitigator to choose the DDoS mitigation techniques and perform
   optimal DDoS attack mitigation.

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat

---

From: kaname nishizuka <[email-masked]>
Date: Mon, 22 Jul 2019 22:13:58 +0900

I support this draft.

I'd like to mention about the telemetry attributes from a DOTS server to a DOTS client.
Currently, several transit ISPs are providing DDoS detection and protection services.
In such a service, they send a DDoS detection notification via e-mail when they noticed that their customer is under attack.
The mail includes the telemetry information such as 4.1.5. Attack Details.
This info can be used for further decision of protection strategy by the customer's security operators.
I think it should be covered by the DOTS telemetry specification.

One suggestion to the draft:
Pre-mitigation DOTS Telemetry Attributes can also be signaled from the DOTS server to the DOTS client.

thanks,
Kaname

On 2019/07/05 22:20, tirumal reddy wrote:
> Hi all,
>
> https://tools.ietf.org/html/draft-reddy-dots-telemetry-00 aims to enrich DOTS protocols with various telemetry attributes allowing optimal DDoS attack mitigation. This document specifies the normal traffic baseline and attack traffic telemetry attributes a DOTS client can convey to its DOTS server in the mitigation request, the mitigation status telemetry attributes a DOTS server can communicate to a DOTS client, and the mitigation efficacy telemetry attributes a DOTS client can communicate to a DOTS server.  The telemetry attributes can assist the mitigator to choose the DDoS mitigation techniques and perform optimal DDoS attack mitigation.
>
> From: <[email-masked] <mailto:[email-masked]>>
> To: Tirumaleswar Reddy <[email-masked] <mailto:[email-masked]>>, Ehud Doron <[email-masked] <mailto:[email-masked]>>, Mohamed Boucadair <[email-masked] <mailto:[email-masked]>>
>
>
>
> Title:          Distributed Denial-of-Service Open Threat Signaling (DOTS) Telemetry
> URL: https://www.ietf.org/internet-drafts/draft-reddy-dots-telemetry-00.txt
> Htmlized: https://datatracker.ietf.org/doc/html/draft-reddy-dots-telemetry
>
>
> Abstract:
> until the htmlized version and diff are available at tools.ietf.org <http://tools.ietf.org>.
>
> The IETF Secretariat
>
>
> _______________________________________________
> Dots mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dots

---

From: "Konda, Tirumaleswar Reddy" <[email-masked]>
Date: Mon, 22 Jul 2019 14:11:29 +0000

Thanks Kaname for the support. I did not get the comment. what type of pre-mitigation DOTS telemetry attributes can be signaled from the DOTS server to the DOTS client ?
And How will the DOTS server know the pre-mitigation DOTS telemetry attributes relevant or associated with a DOTS client ?

Cheers,
-Tiru

From: Dots <[email-masked]> On Behalf Of kaname nishizuka
Sent: Monday, July 22, 2019 6:44 PM
To: tirumal reddy <[email-masked]>; [email-masked]
Subject: Re: [Dots] Fwd: New Version Notification for draft-reddy-dots-telemetry-00.txt

CAUTION: External email. Do not click links or open attachments unless you recognize the sender and know the content is safe.

________________________________
I support this draft.

thanks,
Kaname

Cheers,
-Tiru

---------- Forwarded message ---------
From: <[email-masked]<mailto:[email-masked]>>
Date: Fri, 5 Jul 2019 at 18:44
Subject: New Version Notification for draft-reddy-dots-telemetry-00.txt
To: Tirumaleswar Reddy <[email-masked]<mailto:[email-masked]>>, Ehud Doron <[email-masked]<mailto:[email-masked]>>, Mohamed Boucadair <[email-masked]<mailto:[email-masked]>>

Abstract:

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org<http://tools.ietf.org>.

The IETF Secretariat

Dots mailing list

[email-masked]<mailto:[email-masked]>

---

From: kaname nishizuka <[email-masked]>
Date: Mon, 22 Jul 2019 23:55:35 +0900

Hi Tiru,

Let me explain it.
There is a service by several transit providers such as detection capabilities to notify clients of potential attacks.
It is assumed that they have a DDoS mitigation system and a DDoS detection system (for example, a flow collector) separately.
It is a realistic deployment that the DOTS server is integrated with the flow collector.

When an attack occur, the DDoS detection system will notice that the customer is under attack, then the pre-mitigation DOTS telemetry(= attack details) can be signaled from the DOTS server to the (associated) DOTS client.

Here is one of the traffic anomaly detection notification example (threshold basis) quoted from some actual service.
Organization:       XXX
Attack ID:          13227
Start Time:         2019/06/05 22:52:30 JST+0900
Level:              1
Traffic Amount:     4.02k pps
Threshold:          4.00k pps
Direction:          incoming
Victim IP Address:  x.x.x.x/32
Attack Type:        TCP SYN

It says like "it seems you're under attack, what will you do? (We can offer some protection)"

regards,
Kaname

On 2019/07/22 23:11, Konda, Tirumaleswar Reddy wrote:
> *From:*Dots <[email-masked]> *On Behalf Of *kaname nishizuka
> *Sent:* Monday, July 22, 2019 6:44 PM
> *To:* tirumal reddy <[email-masked]>; [email-masked]
> *Subject:* Re: [Dots] Fwd: New Version Notification for draft-reddy-dots-telemetry-00.txt
>
> *CAUTION*:External email. Do not click links or open attachments unless you recognize the sender and know the content is safe.
>
> ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
>
> I support this draft.
>
>     [email-masked]  <mailto:[email-masked]>
>

---

From: "Konda, Tirumaleswar Reddy" <[email-masked]>
Date: Tue, 23 Jul 2019 07:04:00 +0000

Thanks for the clarification. I don’t think any of the DOTS use cases documents discuss this deployment. DOTS signal channel looks more suitable for these Pre-mitigation DOTS Telemetry Attributes than the DOTS data channel.

Cheers,
-Tiru

From: kaname nishizuka <[email-masked]>
Sent: Monday, July 22, 2019 8:26 PM
To: Konda, Tirumaleswar Reddy <[email-masked]>; tirumal reddy <[email-masked]>; [email-masked]
Subject: Re: [Dots] Fwd: New Version Notification for draft-reddy-dots-telemetry-00.txt

Let me explain it.

regards,
Kaname

Cheers,
-Tiru

From: Dots <[email-masked]><mailto:[email-masked]> On Behalf Of kaname nishizuka
Sent: Monday, July 22, 2019 6:44 PM
To: tirumal reddy <[email-masked]><mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re: [Dots] Fwd: New Version Notification for draft-reddy-dots-telemetry-00.txt

thanks,
Kaname

Cheers,
-Tiru

---------- Forwarded message ---------
From: <[email-masked]<mailto:[email-masked]>>
Date: Fri, 5 Jul 2019 at 18:44
Subject: New Version Notification for draft-reddy-dots-telemetry-00.txt
To: Tirumaleswar Reddy <[email-masked]<mailto:[email-masked]>>, Ehud Doron <[email-masked]<mailto:[email-masked]>>, Mohamed Boucadair <[email-masked]<mailto:[email-masked]>>

Abstract:

The IETF Secretariat

Dots mailing list

Dots mailing list

---

From: "Jon Shallow" <[email-masked]>
Date: Tue, 23 Jul 2019 10:29:31 +0100

Hi Kaname,

“When an attack occur, the DDoS detection system will notice that the customer is under attack, then the pre-mitigation DOTS telemetry(= attack details) can be signaled from the DOTS server to the (associated) DOTS client”

How is the DOTS telemetry information signalled/pushed from the DOTS server to the DOTS client?

Can it be assumed that a mitigation request is already active from the DOTS client and the telemetry update is piggybacked on a mitigation observe response?

Is it down to the client doing a periodic poll of a (potentially new) resource?

[The call home concept could cover this, but the client and server roles need to be clearly defined with possibly a client and server being resident in each peer]

Regards

Jon

From: Dots [mailto: [email-masked]] On Behalf Of Konda, Tirumaleswar Reddy
Sent: 23 July 2019 08:04
To: kaname nishizuka; tirumal reddy; [email-masked]
Subject: Re: [Dots] Fwd: New Version Notification for draft-reddy-dots-telemetry-00.txt

Cheers,

-Tiru

  _____  

Hi Tiru,

Let me explain it.

regards,
Kaname

Cheers,

-Tiru

From: Dots  <mailto:[email-masked]> <[email-masked]> On Behalf Of kaname nishizuka
Sent: Monday, July 22, 2019 6:44 PM
To: tirumal reddy  <mailto:[email-masked]> <[email-masked]>; [email-masked]
Subject: Re: [Dots] Fwd: New Version Notification for draft-reddy-dots-telemetry-00.txt

  _____  

I support this draft.

thanks,
Kaname

Hi all,

Cheers,

-Tiru

---------- Forwarded message ---------
From: <[email-masked]>
Date: Fri, 5 Jul 2019 at 18:44
Subject: New Version Notification for draft-reddy-dots-telemetry-00.txt
To: Tirumaleswar Reddy <[email-masked]>, Ehud Doron <[email-masked]>, Mohamed Boucadair <[email-masked]>

Abstract:

The IETF Secretariat

---

From: "Meiling Chen" <[email-masked]>
Date: Tue, 23 Jul 2019 17:48:24 +0800

Hi kaname,Exactly, DDoS mitigation system and DDoS detection system (for example, a flow collector) are separately, one scenario of the deployments that the DOTS server is integrated with the flow collector.I'd like to do more discussion,  there exist some VIPs that they don't have their own DDoS detection system, and buy another company's service to prevent attack.on this occasion, attack target can't sense the attack, DDoS detection system is responsible for the role of Dots Client,  then a centralized scheduling platform(if it exists) can act as Dots server.in the draft draft-chen-dots-server-hierarchical-deployment we make some consideration for dots server deployment(welcome reading and comments)Htmlized: https://tools.ietf.org/html/draft-chen-dots-server-hierarchical-deployment-00
Traffic Amount:     4.02k pps  [question] is it means the total packets including attacks and normal traffic? In my draft I named attack-bandwidth.
Threshold:          4.00k pps[question] is threshold setting depending on each attack type？In my draft I named  Target-attack-type-threshold   
Direction:          incoming
Victim IP Address:  x.x.x.x/32[comments]: It would also be helpful to assess the number of all attack ips in distributed attack mode 
Attack Type:        TCP SYN
[comments]:In the draft draft-chen-dots-attack-informations-02 we propose a unify classify method to name the attack type.
Htmlized: https://tools.ietf.org/html/draft-chen-dots-attack-informations-02

From: Konda, Tirumaleswar Reddy
Date: 2019-07-23 15:04
To: kaname nishizuka; tirumal reddy; [email-masked]
Subject: Re: [Dots] Fwd: New Version Notification for draft-reddy-dots-telemetry-00.txt
Thanks for the clarification. I don’t think any of the DOTS use cases documents discuss this deployment. DOTS signal channel looks more suitable for these Pre-mitigation DOTS Telemetry Attributes than the DOTS data channel. 
 
Cheers,
-Tiru

Hi Tiru,

Let me explain it.

regards,
Kaname

Cheers,
-Tiru

I support this draft.

thanks,
Kaname

Cheers,
-Tiru
 
---------- Forwarded message ---------
From: <[email-masked]>
Date: Fri, 5 Jul 2019 at 18:44
Subject: New Version Notification for draft-reddy-dots-telemetry-00.txt
To: Tirumaleswar Reddy <[email-masked]>, Ehud Doron <[email-masked]>, Mohamed Boucadair <[email-masked]>

Abstract:

The IETF Secretariat

_______________________________________________Dots mailing [email-masked]://www.ietf.org/mailman/listinfo/dots

_______________________________________________Dots mailing [email-masked]://www.ietf.org/mailman/listinfo/dots

---

From: H Y <[email-masked]>
Date: Tue, 23 Jul 2019 07:57:41 -0400

Hi Tiru,

I read the draft and I also support this draft.
Sending detail information about attack traffic helps my dms offload
scenario because the orchestrator can decide what to do based on the
detail information.

IMO, "top talker" attribute defined in my previous draft is also
feasible to send and effective to mitigate attack correctly.
https://datatracker.ietf.org/doc/draft-h-dots-mitigation-offload-expansion/
What do you think about including the top talker attribute to the telemetry?

Thanks,
Yuhei

-- 
----------------------------------
Yuuhei HAYASHI
08065300884
[email-masked]
[email-masked]
----------------------------------

---

From: kaname nishizuka <[email-masked]>
Date: Tue, 23 Jul 2019 21:07:01 +0900

Hi Tiru,

On 2019/07/23 16:04, Konda, Tirumaleswar Reddy wrote:
>
> Thanks for the clarification.
>
Welcome :)

> I don’t think any of the DOTS use cases documents discuss this deployment.
>
Also, no for me.

> DOTS signal channel looks more suitable for these Pre-mitigation DOTS Telemetry Attributes than the DOTS data channel.
>
Yes, I agree.

thanks,
Kaname
>
> Cheers,
>
> -Tiru
>
> *From:*kaname nishizuka <[email-masked]>
> *Sent:* Monday, July 22, 2019 8:26 PM
> *To:* Konda, Tirumaleswar Reddy <[email-masked]>; tirumal reddy <[email-masked]>; [email-masked]
>     *From:*Dots <[email-masked]> <mailto:[email-masked]> *On Behalf Of *kaname nishizuka
>     *To:* tirumal reddy <[email-masked]> <mailto:[email-masked]>; [email-masked] <mailto:[email-masked]>

---

From: kaname nishizuka <[email-masked]>
Date: Tue, 23 Jul 2019 21:29:19 +0900

Hi Jon,

Please see inline.

> How is the DOTS telemetry information signalled/pushed from the DOTS server to the DOTS client?
[kaname]Yes, that is the question. I think it should be discussed in the meeting with regard to the telemetry I-D.

> Can it be assumed that a mitigation request is already active from the DOTS client and the telemetry update is piggybacked on a mitigation observe response?
[kaname]No. Currently the notification (via e-mail etc...) is done before any mitigation request.
If we allowed a dummy mitigation request for that observation purpose, it could be yes. (I don't think it's a good strategy)

> Is it down to the client doing a periodic poll of a (potentially new) resource?
[kaname]It could be one solution, however I'd like to seek a way with push notification.

> [The call home concept could cover this, but the client and server roles need to be clearly defined with possibly a client and server being resident in each peer]
[kaname] Yes, the telemetry I-D is covering the information exchange in both directions(server->client, client->server). Then I think it's a typical deployment for ISPs and mobile carriers that the DOTS server is in the provider's network and the DOTS client in the customer's network, as Meiling agreed with the usecase.

thanks,
Kaname
>
> Regards
>
> Jon
>
> *From:*Dots [mailto: [email-masked]] *On Behalf Of *Konda, Tirumaleswar Reddy
> *Sent:* 23 July 2019 08:04
> *To:* kaname nishizuka; tirumal reddy; [email-masked]

---

From: "Konda, Tirumaleswar Reddy" <[email-masked]>
Date: Wed, 24 Jul 2019 12:18:07 +0000

Hi Yuhei,

Thanks for the support. The problem is fragmentation of the DOTS telemetry message, DOTS Telemetry is sent over the DOTS signal channel using UDP and the message size cannot exceed PMTU.

Cheers,
-Tiru

> -----Original Message-----
> From: Dots <[email-masked]> On Behalf Of H Y
> Sent: Tuesday, July 23, 2019 5:28 PM
> To: tirumal reddy <[email-masked]>
> Cc: [email-masked]
> 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,
> 
> Sending detail information about attack traffic helps my dms offload scenario
> because the orchestrator can decide what to do based on the detail
> information.
> 
> IMO, "top talker" attribute defined in my previous draft is also feasible to
> send and effective to mitigate attack correctly.
> attack traffic telemetry attributes a DOTS client can convey to its DOTS server
> in the mitigation request, the mitigation status telemetry attributes a DOTS
> server can communicate to a DOTS client, and the mitigation efficacy
> telemetry attributes a DOTS client can communicate to a DOTS server.  The
> telemetry attributes can assist the mitigator to choose the DDoS mitigation
> techniques and perform optimal DDoS attack mitigation.
> >
> > To: Tirumaleswar Reddy <[email-masked]>, Ehud Doron
> > <[email-masked]>, Mohamed Boucadair
> <[email-masked]>
> >
> >
> >
> > A new version of I-D, draft-reddy-dots-telemetry-00.txt has been
> > successfully submitted by Tirumaleswar Reddy and posted to the IETF
> > repository.
> >
> > Please note that it may take a couple of minutes from the time of
> > submission until the htmlized version and diff are available at tools.ietf.org.
> >
> > The IETF Secretariat
> >

---

From: "Konda, Tirumaleswar Reddy" <[email-masked]>
Date: Wed, 24 Jul 2019 12:23:46 +0000

Alternatively Observe can be used to send unsolicited notifications of pre-mitigation DOTS Telemetry Attributes for a new resource (e.g. /telemetry for targets in the victim’s network).

Cheers,
-Tiru

---

From: <[email-masked]>
Date: Wed, 24 Jul 2019 12:32:09 +0000

Hi Tiru, 

That’s true...but fragmentation is a general issue each time we need to supply more telemetry information in the signal channel. As already noted in the draft, we will need to figure out when it is better to provide some telemetry information using data channel.

BTW, "top talker" can already be supplied using source-prefix attribute. Whether top-talker needs to be defined as a separated attribute, but structured as a list of source-prefixes is a design details (if the WG agrees to include it in the telemetry information). 

Anyway, let's continue collecting candidate telemetry information and then make a selection in a second phase.  

Cheers,
Med

> -----Message d'origine-----
> De : Dots [mailto:[email-masked]] De la part de Konda, Tirumaleswar
> Reddy
> Envoyé : mercredi 24 juillet 2019 14:18
> À : H Y; tirumal reddy
> Cc : [email-masked]
> Objet : Re: [Dots] Fwd: New Version Notification for draft-reddy-dots-
> telemetry-00.txt
> 
> Hi Yuhei,
> 
> Thanks for the support. The problem is fragmentation of the DOTS telemetry
> message, DOTS Telemetry is sent over the DOTS signal channel using UDP and
> the message size cannot exceed PMTU.
> 
> Cheers,
> -Tiru
> 
> scenario
> feasible to
> > > Htmlized:       https://datatracker.ietf.org/doc/html/draft-reddy-
> dots-
> > telemetry
> > >
> > >
> > > Abstract:

---

From: <[email-masked]>
Date: Wed, 24 Jul 2019 12:40:46 +0000

Indeed.

This is one of the discuss points in Section 4.1 of the draft:

     “check if we can define a dedicated URI for telemetry (e.g.: use
      ./telemetry).  Some of the information is not specific to each
      mitigation request."

Cheers,
Med

De : Dots [mailto:[email-masked]] De la part de Konda, Tirumaleswar Reddy
Envoyé : mercredi 24 juillet 2019 14:24
À : kaname nishizuka; Jon Shallow; [email-masked]
Objet : Re: [Dots] Fwd: New Version Notification for draft-reddy-dots-telemetry-00.txt

Cheers,
-Tiru

---

From: "Konda, Tirumaleswar Reddy" <[email-masked]>
Date: Wed, 24 Jul 2019 12:44:32 +0000

> From: [email-masked]
> Sent: Wednesday, July 24, 2019 6:02 PM
> To: Konda, Tirumaleswar Reddy
> <[email-masked]>; H Y
> <[email-masked]>; tirumal reddy <[email-masked]>
> Cc: [email-masked]
> Subject: RE: [Dots] Fwd: New Version Notification for draft-reddy-dots-
> telemetry-00.txt
> 
> That’s true...but fragmentation is a general issue each time we need to
> supply more telemetry information in the signal channel. As already noted in
> the draft, we will need to figure out when it is better to provide some
> telemetry information using data channel.

Yes, normal traffic baseline attributes can be conveyed in the DOTS data channel and traffic from top talkers can also be blocked/rate-limited using the DOTS data channel during peace time. 

> 
> BTW, "top talker" can already be supplied using source-prefix attribute.
> Whether top-talker needs to be defined as a separated attribute, but
> structured as a list of source-prefixes is a design details (if the WG agrees to
> include it in the telemetry information).

Source-prefix is already a list/array.

> make a selection in a second phase.

Sure.

Cheers,
-Tiru

> > De : Dots [mailto:[email-masked]] De la part de Konda,
> > Tirumaleswar Reddy Envoyé : mercredi 24 juillet 2019 14:18 À : H Y;
> > tirumal reddy Cc : [email-masked] Objet : Re: [Dots] Fwd: New Version
> > Notification for draft-reddy-dots- telemetry-00.txt
> >
> > Hi Yuhei,
> >
> > Thanks for the support. The problem is fragmentation of the DOTS
> > telemetry message, DOTS Telemetry is sent over the DOTS signal channel
> > using UDP and the message size cannot exceed PMTU.
> >
> > Cheers,
> > -Tiru
> >
> > > Subject: Re: [Dots] Fwd: New Version Notification for
> > > draft-reddy-dots- telemetry-00.txt
> > >
> > > open attachments unless you recognize the sender and know the
> > > content is safe.
> > >
> > > Hi Tiru,
> > >
> > > DOTS protocols with various telemetry attributes allowing optimal
> > > DDoS attack mitigation. This document specifies the normal traffic
> > > baseline
> > and
> > > DOTS
> > server
> > > in the mitigation request, the mitigation status telemetry
> > > attributes a
> > DOTS
> > > > successfully submitted by Tirumaleswar Reddy and posted to the
> > > > IETF repository.
> > > >

---

From: <[email-masked]>
Date: Wed, 24 Jul 2019 12:56:42 +0000

Re-,

Please see inline. 

Cheers,
Med

> De : Konda, Tirumaleswar Reddy [mailto:[email-masked]]
> Envoyé : mercredi 24 juillet 2019 14:45
> À : BOUCADAIR Mohamed TGI/OLN; H Y; tirumal reddy
> Cc : [email-masked]
> Objet : RE: [Dots] Fwd: New Version Notification for draft-reddy-dots-
> telemetry-00.txt
> 
> Yes, normal traffic baseline attributes can be conveyed in the DOTS data
> channel and traffic from top talkers can also be blocked/rate-limited
> using the DOTS data channel during peace time.
> 
> >

[Med] Yes. My point is if one has to return a list of top-talkers in terms of pps, another list of top-talkers in terms of second_criteria, or other information relying on source-prefix dedicated attributes will be needed because this cannot be inferred from the current source-prefix attribute. 

> 
> >
> > Anyway, let's continue collecting candidate telemetry information and
> then
> > make a selection in a second phase.
> 
> Sure.
> 
> Cheers,
> -Tiru
> 
> >
> > Cheers,
> > Med
> >
> > > > > Title:          Distributed Denial-of-Service Open Threat
> Signaling
> > > (DOTS)
> > > > Telemetry
> > > > > URL:            https://www.ietf.org/internet-drafts/draft-reddy-
> dots-
> > > > telemetry-00.txt

---

From: kaname nishizuka <[email-masked]>
Date: Wed, 24 Jul 2019 22:19:40 +0900

That's good to know.
I prefer this direction.

thanks,
Kaname

On 2019/07/24 21:40, [email-masked] wrote:
> *De :*Dots [mailto:[email-masked]] *De la part de* Konda, Tirumaleswar Reddy
> *Envoyé :* mercredi 24 juillet 2019 14:24
> *À :* kaname nishizuka; Jon Shallow; [email-masked]
> *Objet :* Re: [Dots] Fwd: New Version Notification for draft-reddy-dots-telemetry-00.txt
>
> Alternatively Observe can be used to send unsolicited notifications of pre-mitigation DOTS Telemetry Attributesfor a new resource (e.g. /telemetry for targets in the victim’s network).
>
> Cheers,
>
> -Tiru
>

---

From: H Y <[email-masked]>
Date: Wed, 24 Jul 2019 09:26:39 -0400

Hi Med,

> [Med] Yes. My point is if one has to return a list of top-talkers in terms of pps, another list of top-talkers in terms of second_criteria, or other information relying on source-prefix dedicated a…
[hayashi] +1. This top-talker information is helpful for the
orchestrator to decide which attack traffic should be blocked
preferentially in network. The criteria information is also needed.

Thanks,
Yuhei

---

From: "Konda, Tirumaleswar Reddy" <[email-masked]>
Date: Wed, 24 Jul 2019 13:34:34 +0000

Hi Yuhei,

What is stopping the attacker to frequently change the IP address (especially with IPv6) ?
What kind of attack traffic is generated by the top talkers and what happens if the top talkers are spoofed IP addresses (e.g. amplification attack) ?

Cheers,
-Tiru

> From: H Y <[email-masked]>
> Sent: Wednesday, July 24, 2019 6:57 PM
> To: Mohamed Boucadair <[email-masked]>
> Cc: Konda, Tirumaleswar Reddy <[email-masked]>;
> tirumal reddy <[email-masked]>; [email-masked]
> > [Med] Yes. My point is if one has to return a list of top-talkers in terms of
> pps, another list of top-talkers in terms of second_criteria, or other
> information relying on source-prefix dedicated attributes will be needed
> because this cannot be inferred from the current source-prefix attribute.
> [hayashi] +1. This top-talker information is helpful for the orchestrator to
> decide which attack traffic should be blocked preferentially in network. The
> criteria information is also needed.
> 
> Thanks,
> Yuhei
> 
> > > De : Konda, Tirumaleswar Reddy
> > > [mailto:[email-masked]]
> > > Envoyé : mercredi 24 juillet 2019 14:45 À : BOUCADAIR Mohamed
> > > TGI/OLN; H Y; tirumal reddy Cc : [email-masked] Objet : RE: [Dots]
> > > Fwd: New Version Notification for draft-reddy-dots- telemetry-00.txt
> > >
> > > > Subject: RE: [Dots] Fwd: New Version Notification for
> > > > This email originated from outside of the organization. Do not
> > > > click
> > > links or
> > > > That’s true...but fragmentation is a general issue each time we
> > > > need to supply more telemetry information in the signal channel.
> > > > As already
> > > noted in
> > > > the draft, we will need to figure out when it is better to provide
> > > > some telemetry information using data channel.
> > >
> > > Yes, normal traffic baseline attributes can be conveyed in the DOTS
> > > data channel and traffic from top talkers can also be
> > > blocked/rate-limited using the DOTS data channel during peace time.
> > >
> > > >
> > > > Whether top-talker needs to be defined as a separated attribute,
> > > > but structured as a list of source-prefixes is a design details
> > > > (if the WG
> > > agrees to
> > [Med] Yes. My point is if one has to return a list of top-talkers in terms of
> pps, another list of top-talkers in terms of second_criteria, or other
> information relying on source-prefix dedicated attributes will be needed
> because this cannot be inferred from the current source-prefix attribute.
> >
> > >
> > > >
> > > > > Tirumaleswar Reddy Envoyé : mercredi 24 juillet 2019 14:18 À : H
> > > > > Y; tirumal reddy Cc : [email-masked] Objet : Re: [Dots] Fwd: New
> > > > > Version Notification for draft-reddy-dots- telemetry-00.txt
> > > > >
> > > > > Hi Yuhei,
> > > > >
> > > > > telemetry message, DOTS Telemetry is sent over the DOTS signal
> > > > > channel using UDP and the message size cannot exceed PMTU.
> > > > >
> > > > > Cheers,
> > > > > -Tiru
> > > > >
> > > > > > This email originated from outside of the organization. Do not
> > > > > > click
> > > > > links or
> > > > > > because the orchestrator can decide what to do based on the
> > > > > > detail information.
> > > > > >
> > > > > > https://datatracker.ietf.org/doc/draft-h-dots-mitigation-offlo
> > > > > > ad-
> > > > > expansion/
> > > > > > What do you think about including the top talker attribute to
> > > > > > the
> > > > > telemetry?
> > > > > >
> > > > > > Thanks,
> > > > > > Yuhei
> > > > > >
> > > > > > > https://tools.ietf.org/html/draft-reddy-dots-telemetry-00
> > > > > > > aims to
> > > > > enrich
> > > > > > DOTS protocols with various telemetry attributes allowing
> > > > > > optimal DDoS attack mitigation. This document specifies the
> > > > > > normal traffic baseline
> > > > > and
> > > > > > attack traffic telemetry attributes a DOTS client can convey
> > > > > > to its DOTS
> > > > > server
> > > > > > server can communicate to a DOTS client, and the mitigation
> > > > > > efficacy telemetry attributes a DOTS client can communicate to a
> DOTS server.
> > > > > The
> > > > > > telemetry attributes can assist the mitigator to choose the
> > > > > > DDoS
> > > > > mitigation
> > > > > > > A new version of I-D, draft-reddy-dots-telemetry-00.txt has
> > > > > > > been successfully submitted by Tirumaleswar Reddy and posted
> > > > > > > to the IETF repository.
> > > > > > >
> > > > > > >    traffic telemetry attributes a DOTS client can convey to
> > > > > > > its
> > > DOTS
> > > > > > >    attributes a DOTS server can communicate to a DOTS
> > > > > > > client, and
> > > the
> > > > > > >    communicate to a DOTS server.  The telemetry attributes
> > > > > > > can
> > > assist
> > > > > > >    the mitigator to choose the DDoS mitigation techniques
> > > > > > > and
> > > perform
> > > > > > > Please note that it may take a couple of minutes from the
> > > > > > > time of submission until the htmlized version and diff are
> > > > > > > available at
> > > > > tools.ietf.org.
> > > > > > >
> > > > > > > The IETF Secretariat
> > > > > > >

---

From: H Y <[email-masked]>
Date: Wed, 24 Jul 2019 09:55:36 -0400

Hi Tiru

> What kind of attack traffic is generated by the top talkers and what happens if the top talkers are spoofed IP addresses (e.g. amplification attack) ?
IMO, when a reflection attack hits a target, src_ip address detected
at the target are reflectors ip address.
If the reflector's ip does not change frequently, the top talker
information can be used.
Is it wrong?

Thanks,
Yuhei

---

From: "Konda, Tirumaleswar Reddy" <[email-masked]>
Date: Fri, 26 Jul 2019 08:53:23 +0000

> Sent: Wednesday, July 24, 2019 7:26 PM
> To: Konda, Tirumaleswar Reddy <[email-masked]>
> Cc: Mohamed Boucadair <[email-masked]>; tirumal reddy
> <[email-masked]>; [email-masked]
> > What kind of attack traffic is generated by the top talkers and what
> happens if the top talkers are spoofed IP addresses (e.g. amplification
> attack) ?
> IMO, when a reflection attack hits a target, src_ip address detected at the
> target are reflectors ip address.
> If the reflector's ip does not change frequently, the top talker information
> can be used.
> Is it wrong?

Yes, the reflector becomes the victim in this attack and cannot access the services of the target server. For example, consider an attack scenario where the surveillance IP camera's IP address is spoofed and it no longer can send feeds to its server (and the attacker can successfully launch a physical attack (e.g. home burglary)).

Cheers,
-Tiru

> > What kind of attack traffic is generated by the top talkers and what
> happens if the top talkers are spoofed IP addresses (e.g. amplification
> attack) ?
> >
> > Cheers,
> > -Tiru
> >
> > > pps, another list of top-talkers in terms of second_criteria, or
> > > other information relying on source-prefix dedicated attributes will
> > > be needed because this cannot be inferred from the current source-
> prefix attribute.
> > > > > > That’s true...but fragmentation is a general issue each time
> > > > > > we need to supply more telemetry information in the signal channel.
> > > > > > As already
> > > > > noted in
> > > > > > the draft, we will need to figure out when it is better to
> > > > > > provide some telemetry information using data channel.
> > > > >
> > > > > Yes, normal traffic baseline attributes can be conveyed in the
> > > > > DOTS data channel and traffic from top talkers can also be
> > > > > > Whether top-talker needs to be defined as a separated
> > > > > > attribute, but structured as a list of source-prefixes is a
> > > > > > design details (if the WG
> > > > > agrees to
> > > pps, another list of top-talkers in terms of second_criteria, or
> > > other information relying on source-prefix dedicated attributes will
> > > be needed because this cannot be inferred from the current source-
> prefix attribute.
> > > >
> > > > >
> > > > > >
> > > > > > > De : Dots [mailto:[email-masked]] De la part de
> > > > > > > Konda, Tirumaleswar Reddy Envoyé : mercredi 24 juillet 2019
> > > > > > > 14:18 À : H Y; tirumal reddy Cc : [email-masked] Objet : Re:
> > > > > > > [Dots] Fwd: New Version Notification for draft-reddy-dots-
> > > > > > > telemetry-00.txt
> > > > > > >
> > > > > > > Hi Yuhei,
> > > > > > >
> > > > > > > Thanks for the support. The problem is fragmentation of the
> > > > > > > DOTS telemetry message, DOTS Telemetry is sent over the DOTS
> > > > > > > signal channel using UDP and the message size cannot exceed
> PMTU.
> > > > > > >
> > > > > > > Cheers,
> > > > > > > -Tiru
> > > > > > >
> > > > > > > > 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,
> > > > > > > >
> > > > > > > > because the orchestrator can decide what to do based on
> > > > > > > > the detail information.
> > > > > > > >
> > > > > > > > What do you think about including the top talker attribute
> > > > > > > > to the
> > > > > > > telemetry?
> > > > > > > >
> > > > > > > > Thanks,
> > > > > > > > Yuhei
> > > > > > > >
> > > > > > > > optimal DDoS attack mitigation. This document specifies
> > > > > > > > the normal traffic baseline
> > > > > > > and
> > > > > > > > attack traffic telemetry attributes a DOTS client can
> > > > > > > > convey to its DOTS
> > > > > > > server
> > > > > > > > server can communicate to a DOTS client, and the
> > > > > > > > communicate to a
> > > > > > > > telemetry attributes can assist the mitigator to choose
> > > > > > > > the DDoS
> > > > > > > mitigation
> > > > > > > > > has been successfully submitted by Tirumaleswar Reddy
> > > > > > > > > and posted to the IETF repository.
> > > > > > > > >
> > > > > > > > >    various telemetry attributes allowing optimal DDoS
> > > > > > > > > attack
> > > > > > > mitigation.
> > > > > > > > >    traffic telemetry attributes a DOTS client can convey
> > > > > > > > > to its
> > > > > DOTS
> > > > > > > > >    server in the mitigation request, the mitigation
> > > > > > > > > status
> > > > > telemetry
> > > > > > > > >    communicate to a DOTS server.  The telemetry
> > > > > > > > > attributes can
> > > > > assist
> > > > > > > > >    the mitigator to choose the DDoS mitigation
> > > > > > > > > techniques and
> > > > > perform
> > > > > > > > > Please note that it may take a couple of minutes from
> > > > > > > > > the time of submission until the htmlized version and
> > > > > > > > > diff are available at
> > > > > > > tools.ietf.org.
> > > > > > > > >
> > > > > > > > > The IETF Secretariat
> > > > > > > > >