Subject: [Dots] wht are the "good reasons" to oppose "telemetry used for detection/classification/traceback of DDoS attacks"

From: Linda Dunbar <[email-masked]>
Date: Fri, 4 Sep 2015 20:38:19 +0000

Roland, 

Can you elaborate the "good reasons" for opposing "telemetry used for the detection/classification/traceback of DDoS attacks"? 

Thank you very much, 

Linda Dunbar

-----Original Message-----
From: Dots [mailto:[email-masked]] On Behalf Of Roland Dobbins

There are very good reasons to oppose scope-creep of this group into the arena of general telemetry used for the detection/classification/traceback of DDoS attacks, and very good reasons to maintain its focus on a signaling methodology for requesting DDoS mitigation services, which has the beneficial side-effect of making the provisioning of said DDoS mitigation services more automated.

-----------------------------------
Roland Dobbins <[email-masked]>

_______________________________________________
Dots mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dots

---

From: Christopher Morrow <[email-masked]>
Date: Fri, 4 Sep 2015 17:33:42 -0400

On Thu, Aug 27, 2015 at 10:29 AM, Flemming Andreasen <[email-masked]> wrote:
> On 8/27/15 3:12 AM, Roland Dobbins wrote:
>>
>> On 27 Aug 2015, at 17:01, Xialiang (Frank) wrote:
>>
>>> which includes the DDoS related telemetry information as its part,
>>
>>
>> The DDoS telemetry referred to in the WG charter is a starting point for
>> DOTS signaling - the telemetry itself is out-of-scope for this WG.
>
> Can you clarify the distinction you are making here ? The charter explicitly
> talks about DDoS related telemetry and based on previous discussions, It was
> my understanding that we wanted to provide information about an ongoing
> attack to an upstream entity to enable a more accurate and rapid response by
> that upstream entity.

perhaps part of the problem here is related to 'provide information
about an ongoing attack to an upstream entity....'

what information? pps? destination ip/network? src-addresses?
port/protocols used?

I suspect that the upstream provider can very quickly determine the
problem in almost all cases, probably better than the initial
reporter... and I'm not sure it's particularly useful to send upstream
much more than:
  "I am seeing an attack to destination X port/protocol Y/Z"

you will want to ask the upstream:
  "do not disable access"

probably... and as to the charter, the charter can always be
changed... or that work item can wait until the decision is that 'this
work is not relevant anymore'... it'd be best, I think, to focus on
the basic dots protocol work and leave the telemetry for a later
decision.

>
>> If the language needs to be massaged to reflect this, we can do it.
>>
> I don't think we can just change the charter, however we should make sure to
> capture the outcome of this thread as part of the overall requirements.

charters always change, it's not written in stone by aliens.

---

From: Christopher Morrow <[email-masked]>
Date: Fri, 4 Sep 2015 17:34:45 -0400

> Can you elaborate the "good reasons" for opposing "telemetry used for the detection/classification/traceback of DDoS attacks"?

it's not clear that a customer link can tell what's really going on,
so 'bad information' is worse than 'no information'... when bad things
are happening.

---

From: Xiaohong Deng <[email-masked]>
Date: Sat, 5 Sep 2015 04:34:17 +0000

On 5/09/2015 7:34 am, "Christopher Morrow" <[email-masked]> wrote:

>> Can you elaborate the "good reasons" for opposing "telemetry used for
>>the detection/classification/traceback of DDoS attacks"?
>>
>

What makes you think so?  To our knowledge, it¹s been already happening in
industry. 

DeepField, a company who does Big Data Business Intelligence for Network
Operators DNSFlow, becoming the largest Cloud and Telecom Big Data
provider in the Americas with coverage of more than 1/5 of all US Internet
traffic. All sorts of telemetry, BGP, iBGP, AAA, and Custom datasets, in
addition to basic NetFlow and Sflow they use to detect attacks and other
Network anomalies. 

Virtela( NTT acquired company), able to detecting network anomalies,
application behaviour anomalies and even give predictive forecast as they
claim, by using self-defined telemetry and analytics.

Hop Analysis, event Analysis, path paris with significant event are
enabled on end-to-end visibility across multi-domain paths by collecting
link telemetry, as per Narada Metrics.

>so 'bad information' is worse than 'no information'... when bad things

Market proved technology can not be providing Œbad information¹ in my
understanding.

If sucessful industry use cases do not look persuasive to WG, then I¹ve
used up my 2 Cents. :-)

-Xiaohong 

>> There are very good reasons to oppose scope-creep of this group into
>>the arena of general telemetry used for the
>>detection/classification/traceback of DDoS attacks, and very good
>>reasons to maintain its focus on a signaling methodology for requesting
>>DDoS mitigation services, which has the beneficial side-effect of making
>>the provisioning of said DDoS mitigation services more automated.
>>

---

From: Christopher Morrow <[email-masked]>
Date: Sat, 5 Sep 2015 01:30:31 -0400

> What makes you think so?  To our knowledge, it¹s been already happening in

having operated a very large network doing dos mitigation for
customers of that network for ~8 yrs.

> Market proved technology can not be providing Œbad information¹ in my

certainly they can?

---

From: "Roland Dobbins" <[email-masked]>
Date: Sat, 05 Sep 2015 16:47:44 +0700

> the detection/classification/traceback of DDoS attacks"?

I'm not opposed to the use of telemetry for that purpose - I use it 
every day, as do many, many others..

What I'm opposed to is this WG group getting involved in things beyond 
its scope and trying to redefine the world.

We need to focus on *one thing* - the ability to automatically summon 
(with the side benefit of autoprovisioning) DDoS mitigation on demand.

What's meant by the current language in the WG charter is that utilizing 
such telemetry in a situationally-appropriate way to determine 
mitigation response is something we may wish to incorporate into the 
DOTS signal composition process, at some point.

I know this because *I'm the person who inserted that language into the 
charter*.

This WG has no authority to define or redefine telemetry formats.  We 
have enough to do right now in terms of defining DOTS; it makes zero 
sense to go haring off in the direction of messing about with telemetry 
formats which we have no authority to change, and which already work 
very well today.

There is no burning need to alter IPFIX.  Altering IPFIX from a 
telemetry standpoint is not within the remit of this group.  Continuing 
to stray into off-charter areas is not productive and does not advance 
achieving the goal of this WG, which is automated signaling for DDoS 
mitigation assistance.

We need to focus on the matter at hand.

---

From: "Roland Dobbins" <[email-masked]>
Date: Sat, 05 Sep 2015 16:52:26 +0700

> What makes you think so?  To our knowledge, it¹s been already 

Yes, it's used for this purpose every day, by networks which have that 
capability, .  But that isn't the point.

The endpoint nodes which require DDoS mitigation assistance and/or the 
networks on which they reside may well have no organic ability to 
perform telemetry generation and/or collection/analysis of same.

The goal of this WG is to produce a standards-based protocol, DOTS, 
which can be used by anything and everything with an IP address to 
programmatically summon DDoS mitigation assistance; this has the 
additional side-benefit of aiding auto-provisioning of DDoS mitigation 
services.

That is quite enough for us to work on, without straying into areas 
which are not our focus, and which are not in dire need of remediation 
in the first place.  Let's please focus on the task at hand.

---

From: "Roland Dobbins" <[email-masked]>
Date: Sat, 05 Sep 2015 17:01:56 +0700

On 27 Aug 2015, at 21:29, Flemming Andreasen wrote:

> The charter explicitly talks about DDoS related telemetry and based on 
> previous discussions, It was my understanding that we wanted to 
> provide information about an ongoing attack to an upstream entity to 
> enable a more accurate and rapid response by that upstream entity.

My intent when contributing that language to the charter was just this - 
to ensure that we determined what, if any, telemetry-derived information 
we wanted to make possible for DOTS supplicants to supply to DDoS 
mitigation service-providing entities.

Obviously, I didn't do a very good job of expressing that clearly, heh.

> I don't think we can just change the charter

Re-chartering is easy, especially at such an early stage of the life of 
a WG.  It shouldn't be necessary, but if this language is continued to 
be used as the basis for diluting our focus on the simple, 
straightforward task of producing a standardized protocol for the 
summoning of DDoS mitigation assistance, then we ought to correct it 
now, so that no more time and energy is wasted in discussing matters 
which are beyond the actual remit and intent of this WG (e.g., spending 
time talking about re-opening IPFIX when we already have an 
urgently-needed problem which we ought to be spending our time and 
energy solving).

---

From: "Roland Dobbins" <[email-masked]>
Date: Sat, 05 Sep 2015 17:11:56 +0700

> certainly they can?

Can and are, you're 100% correct.

As you indicate, the telemetry formats in use today for DDoS 
detection/classification/traceback, while not perfect, work pretty well 
- the proof of this is that they are successfully used for this purpose 
each and every day, and have been for 15 years or more.

The entire raison d'être for this WG is to produce a protocol intended 
to allow supplicants to summon DDoS mitigation assistance as needed; 
this has the side-benefit of allowing auto-provisioning of such 
services, which is also an urgent problem today.

This is more than enough for the DOTS WG to chew on.  This WG has no 
authority to re-open IPFIX to add additional classification elements; 
nor is there a burning need for same.

We need to stick to our knitting.

---

From: "Roland Dobbins" <[email-masked]>
Date: Sat, 05 Sep 2015 17:19:48 +0700

On 27 Aug 2015, at 15:15, Dacheng Zhang wrote:

> However, I agree that we may need to adjust some contents and make the
> draft fit the scope of the group better.

As the person who contributed that language to the charter, I can 
unambiguously assert that the intent behind it was to allow for the 
possibility of doing so in the service of *utilizing those existing 
standards in the service of summoning DDoS mitigation*, *not* to start 
adding additional traffic classification elements which are of dubious 
utility.  Obviously, I didn't do a good job of expressing this concept.

Concur 100% that it may be necessary to re-charter to clarify this 
intent, so that we can focus on our actual mission of producing a 
standards-based mechanism for signaling the need for DDoS mitigation 
assistance.  It's easy enough to do it at this early stage.

---

From: "Roland Dobbins" <[email-masked]>
Date: Sat, 05 Sep 2015 17:33:30 +0700

On 27 Aug 2015, at 19:13, Xialiang (Frank) wrote:

> [Frank]: I cannot agree with you at this point.

Whether you agree with me or not, that was what was meant by the 
language in the charter discussing the possible need to examine and 
possibly update existing telemetry formats.  I know, because I'm the 
person who contributed it.

Existing telemetry formats are successfully used every day to detect, 
classify, and traceback DDoS attacks.  While imperfect (there's always 
room for improvement), there is no burning need to add additional 
classification elements to them, and it is not within the remit of this 
group to do so.

> [Frank]: Instead of the subjective statements, I prefer to have more 
> constructive discussion on specific technical points.

We need to focus this WG's effort on the development of a 
standards-based mechanism for signaling the need for DDoS mitigation 
assistance - i.e., the actual purpose of this WG - instead of delving 
into areas which are not directly related to that attainment of that 
goal.

Can we please table discussion of draft-fu-ipfix-network-security-01 
until after we've developed and delivered the actual DOTS specification 
draft?

---

From: "Xialiang (Frank)" <[email-masked]>
Date: Mon, 7 Sep 2015 04:35:11 +0000

Hi Chris,
According to your comments: 
" it's not clear that a customer link can tell what's really going on, so 'bad information' is worse than 'no information'... when bad things are happening."
I have a question: In your mind, which kind of threat information is bad information, and which is good? 
My understanding is: It seems that most of us have consensus on the value of telemetry (ipfix or others) information, and the fact that it works pretty well for many years. We should not consider them as bad information, right?
I think your worry is not related to the telemetry itself, but to the collection mechanism, and the analysis algorithm to the collected telemetry information. And these are not in scope of DOTS standard works.

Response to your other comment below:

B.R.
Frank

-----邮件原件-----
发件人: Dots [mailto:[email-masked]] 代表 Christopher Morrow
发送时间: 2015年9月5日 5:34
收件人: Flemming Andreasen
抄送: Roland Dobbins; [email-masked]
主题: Re: [Dots] DOTS: next steps - call for editor volunteers for use case draft and requirements draft

On Thu, Aug 27, 2015 at 10:29 AM, Flemming Andreasen <[email-masked]> wrote:
>> The DDoS telemetry referred to in the WG charter is a starting point 
>> for DOTS signaling - the telemetry itself is out-of-scope for this WG.
>
> Can you clarify the distinction you are making here ? The charter 
> explicitly talks about DDoS related telemetry and based on previous 
> discussions, It was my understanding that we wanted to provide 
> information about an ongoing attack to an upstream entity to enable a 
> more accurate and rapid response by that upstream entity.

perhaps part of the problem here is related to 'provide information about an ongoing attack to an upstream entity....'

I suspect that the upstream provider can very quickly determine the problem in almost all cases, probably better than the initial reporter... and I'm not sure it's particularly useful to send upstream much more than:
  "I am seeing an attack to destination X port/protocol Y/Z"

[Frank]: ipfix-based network flow sampling method is already adopted by many operators (network or service) in many cases. In our draft -- draft-fu-ipfix-network-security-01, the goal is very clear: identify the missing IPFIX metrics for specific network threats monitoring and propose supplement to current IPFIX metrics set, which does not require modifying the IPFIX format. For those operators who already deploy ipfix, the network threats detection is much easy than before through these new metrics, and with little change to current IPFIX protocol. I personal think this work is promising and worthwhile. Some examples of new ipfix metrics include: pktUpstreamCount, pktDownstreamCount, icmpEchoCount, icmpEchoReplyCount, fragmentIncompleteCount, fragmentOffestError, ... We will improve and detail the draft for justifying this direction.

probably... and as to the charter, the charter can always be changed... or that work item can wait until the decision is that 'this work is not relevant anymore'... it'd be best, I think, to focus on the basic dots protocol work and leave the telemetry for a later decision.

> I don't think we can just change the charter, however we should make 
> sure to capture the outcome of this thread as part of the overall requirements.

---

From: "Roland Dobbins" <[email-masked]>
Date: Mon, 07 Sep 2015 13:20:59 +0700

On 7 Sep 2015, at 11:35, Xialiang (Frank) wrote:

> In your mind, which kind of threat information is bad information, and 
> which is good?

I'm not Chris, but what he means is that having incomplete/inaccurate 
telemetry is worse than having none at all.

> identify the missing IPFIX metrics for specific network threats 
> monitoring and propose supplement to current IPFIX metrics set, which 
> does not require modifying the IPFIX format.

This is not within the remit of this WG.  And IPFIX is IPFIX; other than 
enterprise elements, there is no modifying it without reopening it.

We need to focus on getting the actual DOTS protocol standard devised 
before going around trying to take other WG's work from them.

All this discussion about IPFIX has not advanced the WG's iota by one 
centimeter.  Can we please focus on the matter at hand?

---

From: "Xialiang (Frank)" <[email-masked]>
Date: Mon, 7 Sep 2015 06:49:41 +0000

Hi Roland,
From my understanding, the works a WG should do ought to be decided or derived from the real use cases and requirements, not the solution what we have now. So, my suggestion is to push aside the discussion on specific solution, and be concerned on the use cases and requirements right now. At last, they will naturally lead us to what solution is mostly required, what part is missed now, etc.

Some of my responses to your comments are below:

-----邮件原件-----
发件人: Dots [mailto:[email-masked]] 代表 Roland Dobbins
发送时间: 2015年9月5日 17:48
收件人: [email-masked]
主题: Re: [Dots] wht are the "good reasons" to oppose "telemetry used for detection/classification/traceback of DDoS attacks"

> the detection/classification/traceback of DDoS attacks"?

I'm not opposed to the use of telemetry for that purpose - I use it every day, as do many, many others..

What I'm opposed to is this WG group getting involved in things beyond its scope and trying to redefine the world.

We need to focus on *one thing* - the ability to automatically summon (with the side benefit of autoprovisioning) DDoS mitigation on demand.
[Frank]: yes, that's our end goal. But, my question is how to reach it without specifying the information content and format (prefer the existing one) communicated between distributed anti-ddos elements?

What's meant by the current language in the WG charter is that utilizing such telemetry in a situationally-appropriate way to determine mitigation response is something we may wish to incorporate into the DOTS signal composition process, at some point.
[Frank]: would you please clarify: what is " a situationally-appropriate way "? what does it mean by " incorporate into the DOTS signal composition process "?

I know this because *I'm the person who inserted that language into the charter*.

This WG has no authority to define or redefine telemetry formats.  We have enough to do right now in terms of defining DOTS; it makes zero sense to go haring off in the direction of messing about with telemetry formats which we have no authority to change, and which already work very well today.
[Frank]: I agree DOTS WG cannot redefine the telemetry formats. What we should do is defining the information model and according data model based on appropriate existing formats (xml, ipfix, json, etc). And the reason behinds which is current information model does not exists, or miss something to support new scenarios. MILE and SACM WG with the similar goals are exactly acting this way.

There is no burning need to alter IPFIX.  Altering IPFIX from a telemetry standpoint is not within the remit of this group.  Continuing to stray into off-charter areas is not productive and does not advance achieving the goal of this WG, which is automated signaling for DDoS mitigation assistance.
[Frank]: I am still confused on your opinion about the necessity of specifying the signaling between the anti-ddos elements. Could you please clarify to me? Thanks!

B.R.
Frank

---

From: "Xialiang (Frank)" <[email-masked]>
Date: Mon, 7 Sep 2015 06:59:23 +0000

Please see my response inline:

-----邮件原件-----
发件人: Dots [mailto:[email-masked]] 代表 Roland Dobbins
发送时间: 2015年9月7日 14:21
收件人: [email-masked]
主题: Re: [Dots] DOTS: next steps - call for editor volunteers for use case draft and requirements draft

> In your mind, which kind of threat information is bad information, and 

I'm not Chris, but what he means is that having incomplete/inaccurate telemetry is worse than having none at all.
[Frank]: It's not the problem of telemetry itself, it's more of the problem about the collection mechanism and the analysis algorithm on them. What I mean is IPFIX telemetry is useful and good information, as it is widely used in industry in many cases.

> does not require modifying the IPFIX format.

This is not within the remit of this WG.  And IPFIX is IPFIX; other than enterprise elements, there is no modifying it without reopening it.

We need to focus on getting the actual DOTS protocol standard devised before going around trying to take other WG's work from them.

All this discussion about IPFIX has not advanced the WG's iota by one centimeter.  Can we please focus on the matter at hand?
[Frank]: ok, let's push aside this specific discussion about solution. It's more effective to start with use cases and requirements.

---

From: "Roland Dobbins" <[email-masked]>
Date: Mon, 07 Sep 2015 14:00:54 +0700

On 7 Sep 2015, at 13:49, Xialiang (Frank) wrote:

> [Frank]: yes, that's our end goal. But, my question is how to reach it 
> without specifying the information content and format (prefer the 
> existing one) communicated between distributed anti-ddos elements?

We intend to do just that.  But it has nothing to do with these changes 
to IPFIX you're pushing.

> [Frank]: would you please clarify: what is " a 
> situationally-appropriate way "? what does it mean by " incorporate 
> into the DOTS signal composition process "?

It means that IPFIX or another existing standard may be suitable to 
serve as the basis for the DOTS protocol, nothing more.

> [Frank]: I agree DOTS WG cannot redefine the telemetry formats.

Then why do you keep pushing do just that?

> What we should do is defining the information model and according data 
> model based on appropriate existing formats (xml, ipfix, json, etc). 
> And the reason behinds which is current information model does not 
> exists, or miss something to support new scenarios. MILE and SACM WG 
> with the similar goals are exactly acting this way.

Yes.  But the modifications you keep pushing for IPFIX do not fall under 
the category of inter-node signaling from supplicants to mitigation 
elements, and between mitigation elements, and so are inapplicable.

> [Frank]: I am still confused on your opinion about the necessity of 
> specifying the signaling between the anti-ddos elements. Could you 
> please clarify to me? Thanks!

There is no basis for your confusion, as I have clearly and consistently 
stated that such signaling is certainly within our remit.  Our first 
priority is signaling from the supplicant to the DDoS mitigation 
elements (the supplicant itself may well be a DDoS mitigation element).

But this continual harping on draft-fu-ipfix-network-security-01 is 
unhelpful, as it has nothing to do with signaling from supplicants to 
mitigation elements.  It is a distraction from our actual goals.

Let's please table draft-fu-ipfix-network-security-01 and similar 
proposals until after the initial DOTS specification has been finalized 
and is on the standards track.

---

From: "Roland Dobbins" <[email-masked]>
Date: Mon, 07 Sep 2015 14:15:29 +0700

On 7 Sep 2015, at 13:59, Xialiang (Frank) wrote:

> What I mean is IPFIX telemetry is useful and good information, as it 
> is widely used in industry in many cases.

Everyone here knows that, thanks.

> [Frank]: ok, let's push aside this specific discussion about solution. 
> It's more effective to start with use  cases and requirements.

Concur 100%, thanks!

---

From: "Teague, Nik" <[email-masked]>
Date: Mon, 7 Sep 2015 17:09:39 +0000

Hi,

On 31/08/2015 23:32, "Dots on behalf of Tobias Gondrom"
<[email-masked] on behalf of [email-masked]> wrote:

>Dear all, 
>
>apologies. Roman and I are currently still going through the (long) list
>of editing volunteers. Which is a great place to be in for our WG. I
>guess, we should be done by tomorrow.
>
>
>In addition to the editing volunteers, I agree that design teams for the
>two drafts might be useful. Always keep in mind that the editor's duty is
>to capture the input from the WG and write it down. So everyone can
>equally contribute. And a design team to work
> out the details sounds useful.

How close are we to getting this underway?  I’m keen as I can see others
are to get things moving and it would be great if we can have some solid
contributions/discussions going before the interim meeting.

Do you have any ideas regarding design teams or we can self organise?

Thanks,

-Nik

---

From: Flemming Andreasen <[email-masked]>
Date: Tue, 8 Sep 2015 11:22:26 -0400

> additional side-benefit of aiding auto-provisioning of DDoS mitigation 
I think this is an oversimplification of the WG's goal as per the 
charter text as well. One of the use case scenarios I would like to see 
covered is the case where an on-premise (e.g. enterprise) DDoS detector 
signals an upstream entity (e.g. SP or cloud provider) for help in 
mitigating a DDoS attack, and as part of that signaling, baseline 
information as well as locally known information about the attack is 
provided to that upstream entity so detection and mitigation doesn't 
have to start from scratch.

Do you agree this is in scope ?

Thanks

-- Flemming

---

From: Flemming Andreasen <[email-masked]>
Date: Tue, 8 Sep 2015 11:26:29 -0400

On 9/7/15 2:20 AM, Roland Dobbins wrote:
>> In your mind, which kind of threat information is bad information, 
>> and which is good?
>
> I'm not Chris, but what he means is that having incomplete
Disagree
> /inaccurate
Agree
> This is not within the remit of this WG.  And IPFIX is IPFIX; other 
> than enterprise elements, there is no modifying it without reopening it.
>
I agree - use cases and requirements first.

Thanks

-- Flemming

---

From: Flemming Andreasen <[email-masked]>
Date: Tue, 8 Sep 2015 11:29:06 -0400

>    "I am seeing an attack to destination X port/protocol Y/Z"
I disagree, and I know of at least one DDoS vendor that does as well.

-- Flemming

---

From: "Roland Dobbins" <[email-masked]>
Date: Tue, 08 Sep 2015 22:37:24 +0700

> I disagree, and I know of at least one DDoS vendor that does as well.

My operational experience with this is that, with some notable 
exceptions, the endpoint network folks lack the skills and experience to 
utilize the tools which can give them accurate information in terms of 
detection/classification/traceback, even if they have those tools.

The relatively few endpoint networks who're good at this tend to be 
ASPs/content providers, themselves; tech companies, some financials, and 
so forth.

Regardless, our task here in DOTS is to standardize signaling; we can't 
assume that the supplicant has any organic 
detection/classification/traceback capabilities (though if they do, of 
course, we want to be able to provide whats relevant to the mitigator).

---

From: Flemming Andreasen <[email-masked]>
Date: Tue, 8 Sep 2015 12:19:35 -0400

On 9/8/15 11:37 AM, Roland Dobbins wrote:
> exceptions, the endpoint network folks lack the skills and experience 
> to utilize the tools which can give them accurate information in terms 
> of detection/classification/traceback, even if they have those tools.
>
I'm not talking about endpoints.

> ASPs/content providers, themselves; tech companies, some financials, 
> and so forth.
>
> Regardless, our task here in DOTS is to standardize signaling; we 
> can't assume that the supplicant has any organic 
Agreed - modularity and flexibility is key here; we don't want to 
mandate an overly comprehensive set of capabilities on everybody, but at 
the same time, there are real-life examples where those capabilities 
exists, and having a standardized signaling mechanism in place for those 
is where I see a lot of value in the DOTS work.

-- Flemming

> .

---

From: Linda Dunbar <[email-masked]>
Date: Tue, 8 Sep 2015 20:26:52 +0000

Chris, 

I like your example on the concrete information that the DOTS initiator can send to upstream DDoS entity:

Are you saying that other telemetry, like the number of attacks, Src IP addresses or ports of the detected attacks, etc, are not necessary? If the initiator send those detailed information, does it hurt? What are the issues of sending those extra information beyond taking up some bandwidth? 

Just curious. 

Linda

---

From: Linda Dunbar <[email-masked]>
Date: Tue, 8 Sep 2015 20:26:52 +0000

Roland, 

Thank you very much for the good explanation. 

In your opinion, what are the necessary attributes or parameters to "automatically summon (with the side benefit of auto-provisioning) DDoS mitigation on demand"?

i.e. for an entity "A" to summon a DDoS mitigation somewhere else, what does the entity "A" need to provide?  I have my view, but curious to hear yours. 

Linda

---

From: "Roland Dobbins" <[email-masked]>
Date: Wed, 09 Sep 2015 03:35:46 +0700

On 9 Sep 2015, at 3:26, Linda Dunbar wrote:

> Are you saying that other telemetry, like the number of attacks, Src 
> IP addresses or ports of the detected attacks, etc, are not necessary?

Not even that amount of information is necessary.  'I am under attack, 
and I'm running these apps/services on these ports/protocols, and 
here're my credentials' is Good Enough.

> If the initiator send those detailed information, does it hurt? What 
> are the issues of sending those extra information beyond taking up 
> some bandwidth?

The issue is that the supplicant may not have the capability to do so, 
or even if it does, to do so accurately.

The supplicant may well be an app on a mobile phone that has a Big Red 
Button.

We must make no assumptions that the supplicant has any ability 
whatsoever to detect/classify/traceback traffic.  It may only be able to 
know it's under load, or a human being may've noticed that it's 
staggering, and pushed the Big Red Button on that app.

By self-identifying, the supplicant allows upstream mitigators to 
auto-provision countermeasures and other potential mitigation actions.  
Provisioning is a huge problem in dealing with DDoS attacks today; DOTS 
will have the welcome side-effect of promoting automagic or 
semi-automagic DDoS defense provisioning.

---

From: "Roland Dobbins" <[email-masked]>
Date: Wed, 09 Sep 2015 03:37:07 +0700

> Do you have any ideas regarding design teams or we can self organise?

I vote for self-organization.

---

From: "Roland Dobbins" <[email-masked]>
Date: Wed, 09 Sep 2015 03:38:43 +0700

> Do you agree this is in scope ?

Of course, but detection/classification information oughtn't to be 
mandatory.  I've stated before that if such information is available 
from the supplicant, fine; if not, that's fine, too.

Apologies for being unclear!

---

From: "Roland Dobbins" <[email-masked]>
Date: Wed, 09 Sep 2015 03:39:42 +0700

On 9 Sep 2015, at 3:26, Linda Dunbar wrote:

> i.e. for an entity "A" to summon a DDoS mitigation somewhere else, 
> what does the entity "A" need to provide?  I have my view, but curious 
> to hear yours.

"I need DDoS mitigation assistance.  Here's my IP address.  Here're the 
service/apps I'm running on these ports/protocols.  Here're my auth 
credentials."

---

From: "Roland Dobbins" <[email-masked]>
Date: Wed, 09 Sep 2015 04:15:32 +0700

On 9 Sep 2015, at 3:39, Roland Dobbins wrote:

> "I need DDoS mitigation assistance.  Here's my IP address.  Here're 
> the service/apps I'm running on these ports/protocols.  Here're my 
> auth credentials."

Actually, "I need DDoS mitigation assistance.  Here's my IP address.  
Here're my auth credentials" should probably be the minimum-viability 
DOTS mitigation request, in cases where the end-customer organization 
are simply incapable of providing this information, for whatever reason.

But the information about services/apps on ports/protocols is really 
important, and should be provided whenever possible.

---

From: Flemming Andreasen <[email-masked]>
Date: Tue, 8 Sep 2015 17:23:03 -0400

> Apologies for being unclear!
No worries - sounds like we are on the same page here after all.

Cheers

-- Flemming

---

From: Linda Dunbar <[email-masked]>
Date: Tue, 8 Sep 2015 21:28:15 +0000

Roland,

You said
      " But the information about services/apps on ports/protocols is really important, and should be provided whenever possible."

Should the End Points register their "Services/Apps on ports/protocols" before any attack starts? Say with an entity (e.g. the upstream management system)? I would imagine that end points can provide more accurate information before the end point is attacked, correct?

Linda

-----Original Message-----
From: Dots [mailto:[email-masked]] On Behalf Of Roland Dobbins
Sent: Tuesday, September 08, 2015 4:16 PM
To: [email-masked]
Subject: Re: [Dots] What are the necessary attributes to automatically summon DDoS mitigation on demand ?(was: what are the "good reasons" to oppose "telemetry used for detection/classification/traceback of DDoS attacks"

Actually, "I need DDoS mitigation assistance.  Here's my IP address.
Here're my auth credentials" should probably be the minimum-viability DOTS mitigation request, in cases where the end-customer organization are simply incapable of providing this information, for whatever reason.

But the information about services/apps on ports/protocols is really important, and should be provided whenever possible.

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

_______________________________________________
Dots mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/dots

---

From: "Roland Dobbins" <[email-masked]>
Date: Wed, 09 Sep 2015 05:33:02 +0700

On 9 Sep 2015, at 4:28, Linda Dunbar wrote:

> Should the End Points register their "Services/Apps on 
> ports/protocols" before any attack starts?

Ideally, yes, that's how it should work.  But just-in-time (JIT) would 
be possible, as well - and that's key for organizations which didn't 
have a mitigation service in place ahead-of-time, which come under 
attack, and are screaming for DDoS mitigation assistance.  If their 
apps/services/infrastructure is DOTS-capable, mitigation can be 
provisioned JIT, without all the fumbling and bumbling of trying to a) 
manually gather/vet the requisite information and b) communicate it 
manually, either verbally or in writing (see p. 20 of 
<https://app.box.com/s/wwvlklsqsaeus3upx2sssxu4p8wytpqq>, and pp. 15-20 
of <https://app.box.com/s/wwvlklsqsaeus3upx2sssxu4p8wytpqq>).

Note that this isn't a function of the DOTS signaling protocol itself, 
but rather a function of the mitigation organization's infrastructure, 
operational practices, etc.

> Say with an entity (e.g. the upstream management system)? I would 
> imagine that end points can provide more accurate information before 
> the end point is attacked, correct?

We assume that the provisioning information is accurate, as that's 
generally much more static and well-understood (even though in many 
cases, it's poorly understood, or not at all understood) than traffic 
statistics, attack classification, etc.  The accuracy should be 
unchanged with regards to pre-attack vs. active-attack scenarios.

And as moves/adds/changes happen over time, there's obviously a high 
desirability for re-registration as events warrant.  Provisioning 
validation, mitigation validation/rehearsal, et. al. all become easier, 
as well.

---

From: Jelena Mirkovic <[email-masked]>
Date: Tue, 8 Sep 2015 15:41:03 -0700

Now I'm confused. JIT assumes that someone will mitigate attacks for free,
if there was no preregistration, no contract. Is there a movement in
industry in this direction?

=========================

Jelena Mirkovic
Research Faculty
USC Information Sciences Institute
4676 Admiralty Way, Suite 1001
Marina del Rey, CA 90292
310-448-9170

On Tue, Sep 8, 2015 at 3:33 PM, Roland Dobbins <[email-masked]> wrote:

> Should the End Points register their "Services/Apps on ports/protocols"
>> before any attack starts?
>>
>
> Ideally, yes, that's how it should work.  But just-in-time (JIT) would be
> possible, as well - and that's key for organizations which didn't have a
> mitigation service in place ahead-of-time, which come under attack, and are
> screaming for DDoS mitigation assistance.  If their
> apps/services/infrastructure is DOTS-capable, mitigation can be provisioned
> JIT, without all the fumbling and bumbling of trying to a) manually
> gather/vet the requisite information and b) communicate it manually, either
> verbally or in writing (see p. 20 of <
> https://app.box.com/s/wwvlklsqsaeus3upx2sssxu4p8wytpqq>, and pp. 15-20 of
> <https://app.box.com/s/wwvlklsqsaeus3upx2sssxu4p8wytpqq>).
>
> Note that this isn't a function of the DOTS signaling protocol itself, but
> rather a function of the mitigation organization's infrastructure,
> Say with an entity (e.g. the upstream management system)? I would imagine
>> that end points can provide more accurate information before the end point
>> is attacked, correct?
>>
>
> generally much more static and well-understood (even though in many cases,
> it's poorly understood, or not at all understood) than traffic statistics,
> attack classification, etc.  The accuracy should be unchanged with regards
> to pre-attack vs. active-attack scenarios.
>
> validation, mitigation validation/rehearsal, et. al. all become easier, as
> well.
>
>

---

From: "Roland Dobbins" <[email-masked]>
Date: Wed, 09 Sep 2015 05:51:48 +0700

On 9 Sep 2015, at 5:41, Jelena Mirkovic wrote:

> JIT assumes that someone will mitigate attacks for free, if there was 
> no preregistration, no contract.

No - JIT assumes the end-customer calls up the ISP/MSSP screaming, 
"Help, the Internet is down!", and the ISP/MSSP says, "Credit card, 
please," and the end-customer provides it, and then rapid provisioning 
followed by mitigation takes place.

Note that this may also take place online, with zero human-to-human 
contact.  But the above is the logical representation of the process.

;>

A *lot* of DDoS attacks are mitigated (and all too often, not) due to 
this kind of approach.  DOTS will make it much less error-prone and 
achievable within an operationally useful timeframe (e.g., while the 
attack is still taking place).

I've personally taken a combo transit/hosting/colo/wireline broadband 
access/wireless mobile broadband ISP from zero DDoS 
detection/classification/traceback/mitigation capability to full 
capability and active attack mitigation in 90 minutes, *during an 
attack*, and that included racking and stacking boxes and getting 
everything turned up.  This particular attack was against the largest 
and most prominent bank in the country in question; the ISP successfully 
mitigated the attack, everything came back up, and they negotiated the 
contractual and billing stuff post-attack.

Chris Morrow can provide similar examples, as I'm sure can Stefan Fouant 
and Scott Barvick.

DOTS will make this sort of thing far more doable - and, it's hoped, far 
less common, eventually.

---

From: Christopher Morrow <[email-masked]>
Date: Tue, 8 Sep 2015 22:54:00 -0400

> Are you saying that other telemetry, like the number of attacks, Src IP addresses or ports of the detected attacks, etc, are not necessary? If the initiator send those detailed information, does it…

Quite often the ISP customer has much smaller pipes and much less
information about the problem than the ISP has access to. The case
often is: "I am being synflooded!!" when the real problem is not a
synflood, but a full connection flood where the syns are 'line rate'
for the customer access link... or the speed of the server interface
:(

'That is not a synflood, that is a full connection flood'

there are different methods to mitigate such attacks, so sending an
ISP technician off to solve 'syn flood' will not necessarily help in
the case of 'full connection flood'.

Wrong information is almost always a distraction and time-wasting
event for the upstream mitigation provider. The minimal information
required upstream is:
  what ip(s) are being attacked
  over which protocol(s)
  to which destination port(s)
  "can the mitigation provider block all access to the affected address(es)"

(There are, actually, quite a few cases where the /32 being attacked
can be turned off, and other services at the end-site are still
reachable/useful. The endsite should have the option to say 'just make
the attack stop')

-chris

---

From: Christopher Morrow <[email-masked]>
Date: Tue, 8 Sep 2015 22:58:32 -0400

(teach me to read out of order)

On Tue, Sep 8, 2015 at 4:35 PM, Roland Dobbins <[email-masked]> wrote:
>> Are you saying that other telemetry, like the number of attacks, Src IP
>> addresses or ports of the detected attacks, etc, are not necessary?
>
>
> Not even that amount of information is necessary.  'I am under attack, and
> I'm running these apps/services on these ports/protocols, and here're my
> credentials' is Good Enough.
>

I forgot the credentials.. I presumed there was a pre-existing
relationship (I think there HAS to be this, really anyway) in which:
"requests from IP-X are bob, and are "OK" he has contracted for X
services over Y time" (of course that happens automatically, but my
point is pre-provisioned relationships are mandatory).  Roland's auth
point here is: "But I am not bob and I can tell you to do things to
bob... hahahaa!" which is, of course, correct... auth is required.

>> If the initiator send those detailed information, does it hurt? What are
>> the issues of sending those extra information beyond taking up some
>> bandwidth?
>
>
> The issue is that the supplicant may not have the capability to do so, or
> even if it does, to do so accurately.
>

it's really the 'accurately' part that I find almost no downstream can
get right :( so I'd rather they not confuse the issue and let the
mitigation provider figure out what's going on, it really only takes a
moment anyway... dos is pretty darned clear when it's happening.

> We must make no assumptions that the supplicant has any ability whatsoever
> to detect/classify/traceback traffic.  It may only be able to know it's
> under load, or a human being may've noticed that it's staggering, and pushed
> the Big Red Button on that app.
>

yup!

> Provisioning is a huge problem in dealing with DDoS attacks today; DOTS will
> have the welcome side-effect of promoting automagic or semi-automagic DDoS
> defense provisioning.
>

this is my hope.

---

From: Christopher Morrow <[email-masked]>
Date: Tue, 8 Sep 2015 23:00:56 -0400

> telemetry is worse than having none at all.

exactly.

>
>> identify the missing IPFIX metrics for specific network threats monitoring
>> and propose supplement to current IPFIX metrics set, which does not require
>> modifying the IPFIX format.
>
>
> We need to focus on getting the actual DOTS protocol standard devised before
> going around trying to take other WG's work from them.
>

yes

> centimeter.  Can we please focus on the matter at hand?

The first step here is: "Agree on what the protocol between the two
endpoints of the conversation (supplicant and mitigation-provider)
should include"

I think we could start with roland's list ... and move along from there.

---

From: Christopher Morrow <[email-masked]>
Date: Tue, 8 Sep 2015 23:06:55 -0400

On Tue, Sep 8, 2015 at 6:51 PM, Roland Dobbins <[email-masked]> wrote:
>> JIT assumes that someone will mitigate attacks for free, if there was no
>> preregistration, no contract.
>

I'd argue that this isn't really important to the ietf nor dots... the
'business model' could be different depending on the players involved.

>
> No - JIT assumes the end-customer calls up the ISP/MSSP screaming, "Help,
> the Internet is down!", and the ISP/MSSP says, "Credit card, please," and
> the end-customer provides it, and then rapid provisioning followed by
> mitigation takes place.
>
> Note that this may also take place online, with zero human-to-human contact.
> But the above is the logical representation of the process.
>
> ;>
>

yup, sometimes there's payment, sometimes not, in either case, if the
process gues from: "oh noz!" to "yes we can help!"

the next bit is where dots-like stuff should happen.

> A *lot* of DDoS attacks are mitigated (and all too often, not) due to this
> kind of approach.  DOTS will make it much less error-prone and achievable
> within an operationally useful timeframe (e.g., while the attack is still
> taking place).
>
> detection/classification/traceback/mitigation capability to full capability
> and active attack mitigation in 90 minutes, *during an attack*, and that
> included racking and stacking boxes and getting everything turned up.  This
> particular attack was against the largest and most prominent bank in the
> country in question; the ISP successfully mitigated the attack, everything
> came back up, and they negotiated the contractual and billing stuff
> post-attack.
>
> Chris Morrow can provide similar examples, as I'm sure can Stefan Fouant and
> Scott Barvick.
>

yup. have similar experience as roland in this regard.
I don't view the business-plan part as important at all to the dots process.

-chris

---

From: "Roland Dobbins" <[email-masked]>
Date: Wed, 09 Sep 2015 12:33:03 +0700

> 'business model' could be different depending on the players involved.

Concur - just pointing out that pre-provisioning isn't absolutely 
necessary, in response to Linda's question.

---

From: "Jon Shallow" <[email-masked]>
Date: Wed, 9 Sep 2015 09:44:34 +0100

I would also argue that the source port potentially is also a vital
component if it is singular.  Think reflective attacks coming back from port
123, 53 etc. to potentially random destination ports in which case the
destination port is usually meaningless.

Regards

Jon

-----Original Message-----
From: Dots [mailto:[email-masked]] On Behalf Of
Christopher Morrow
Sent: 09 September 2015 03:54
To: Linda Dunbar
Cc: Flemming Andreasen; Roland Dobbins; [email-masked]
Subject: Re: [Dots] minimum information to exchange to upstream DDoS (was
RE: DOTS: next steps - call for editor volunteers for use case draft and
requirements draft

> Are you saying that other telemetry, like the number of attacks, Src IP
addresses or ports of the detected attacks, etc, are not necessary? If the
initiator send those detailed information, does it hurt? What are the issues
of sending those extra information beyond taking up some bandwidth?

Quite often the ISP customer has much smaller pipes and much less
information about the problem than the ISP has access to. The case often is:
"I am being synflooded!!" when the real problem is not a synflood, but a
full connection flood where the syns are 'line rate'
for the customer access link... or the speed of the server interface :(

there are different methods to mitigate such attacks, so sending an ISP
technician off to solve 'syn flood' will not necessarily help in the case of
'full connection flood'.

Wrong information is almost always a distraction and time-wasting event for
the upstream mitigation provider. The minimal information required upstream
is:
  what ip(s) are being attacked
  over which protocol(s)
  to which destination port(s)
  "can the mitigation provider block all access to the affected address(es)"

(There are, actually, quite a few cases where the /32 being attacked can be
turned off, and other services at the end-site are still reachable/useful.
The endsite should have the option to say 'just make the attack stop')

-chris

> perhaps part of the problem here is related to 'provide information about
an ongoing attack to an upstream entity....'
> I suspect that the upstream provider can very quickly determine the
problem in almost all cases, probably better than the initial reporter...
and I'm not sure it's particularly useful to send upstream much more than:
> probably... and as to the charter, the charter can always be changed... or
that work item can wait until the decision is that 'this work is not
relevant anymore'... it'd be best, I think, to focus on the basic dots
protocol work and leave the telemetry for a later decision.

---

From: "Roland Dobbins" <[email-masked]>
Date: Wed, 09 Sep 2015 16:38:53 +0700

> destination port is usually meaningless.

Again, there mustn't be a presumption of any 
detection/classification/traceback capability on the supplicant.

Most UDP reflection/amplification attacks pummel either UDP/80, UDP/443, 
UDP/123, and UDP/53 on the target, btw.

<https://app.box.com/s/r7an1moswtc7ce58f8gg>

---

From: "gclark mti-systems.com" <[email-masked]>
Date: Wed, 9 Sep 2015 09:08:57 -0400 (EDT)

I think earlier in the thread there was also a question of if or how detection /
classification / traceback of the supplicant could be trusted if it is present.
 I suppose that one could set up something involving signatures and reputation
as ways to establish varying degrees of trust (and thus support different sets
of telemetry), but that seems like it could be complex to implement, deploy, and
maintain.

Regardless, +1 that most information should be optional.  In general, I'm of the
opinion that DOTS should:

* Keep *requirements* for mitigation requests simple
* Offer a way to *optionally* include additional information with the message
for the provider to consider
    ] Offhand, I'd think that information encoded here should be arbitrary but
self-descriptive, with a registry of well-known types of telemetry
    ] For example, "source port", "destination port", that kind of thing
    ] I don't think message size is a primary consideration (as long as it's
sane)
    ] Alternative idea might be to use publish / subscribe for this - customer
explicitly requests mitigation assistance to provider and the message includes a
subscription endpoint to which the provider can attach to receive more
information about the attack.   provider can optionally choose to subscribe to
indicated endpoint.  customer's device then publishes telemetry (over something
that might work better across a bad link ... raptor codes come to mind, but
maybe not) to all subscribed providers, who are able to use that information in
whatever way they see (or don't see) fit.
* If additional information is included, explicitly note that the provider is
under no obligation to do anything with it (though it can if it wants)

Also, it might be interesting to say that, *if* any additional information is
included beyond "help, I'm under attack", there is expected to be a minimum set
of components that are included then (e.g. must specify port information or
something).

-Gilbert

> On September 9, 2015 at 5:38 AM Roland Dobbins <[email-masked]> wrote:
> 
> 
>

---

From: "Roland Dobbins" <[email-masked]>
Date: Wed, 09 Sep 2015 20:42:43 +0700

> classification / traceback of the supplicant could be trusted if it is 

The concern was actually regarding fidelity; DOTS will have auth reds.

> Alternative idea might be to use publish / subscribe for this - 
> customer

This is way too complex and well beyond our remit, IMHO.

We're working on the signaling protocol, and functions directly 
associated therewith.  This gets into other areas which may be 
interesting, but not part of what we're directly trying to accomplish 
with DOTS.

> under no obligation to do anything with it (though it can if it wants)

Concur with this.
> of components that are included then (e.g. must specify port 

Concur with this, too.

---

From: "gclark mti-systems.com" <[email-masked]>
Date: Wed, 9 Sep 2015 10:26:51 -0400 (EDT)

> interesting, but not part of what we're directly trying to accomplish 

I'll buy the way too complex bit.  In my head, the actual straw-man there wasn't
intended to be the focus so much as the idea that, in general, it might make
sense to just point the provider to a way to *get* the information it wants /
needs from the customer (should the customer choose to provide it) than it would
to actually provide that information as a part of any DOTS protocol ... that
keeps the initial HELP message sizes to a relative minimum, avoids wasted
telemetry frames destined for the provider if the provider isn't interested, and
is an attempt to avoid protocol bloat (since, in theory, this could lead to less
of a temptation to keep adding new, "useful" fields to a signaling protocol).

Cheers,
Gilbert

---

From: Christopher Morrow <[email-masked]>
Date: Wed, 9 Sep 2015 11:47:02 -0400

On Wed, Sep 9, 2015 at 1:33 AM, Roland Dobbins <[email-masked]> wrote:
> Concur - just pointing out that pre-provisioning isn't absolutely necessary,
> in response to Linda's question.

yup, totally agree with this.

---

From: Robert Moskowitz <[email-masked]>
Date: Mon, 21 Sep 2015 16:35:30 -0400

> The concern was actually regarding fidelity; DOTS will have auth reds.

reds?  or reqs?

thanks

>
>> Alternative idea might be to use publish / subscribe for this - customer

---

From: Robert Moskowitz <[email-masked]>
Date: Mon, 21 Sep 2015 16:37:59 -0400

> of a temptation to keep adding new, "useful" fields to a signaling protocol).

Isn't that why you have a language to describe how to define fields 
within the protocol?  Not to try to create a complete taxonomy of all 
possible useful fields?

Reminds me of some X. work of old.

---

From: Christopher Morrow <[email-masked]>
Date: Mon, 21 Sep 2015 20:54:08 -0400

>> The concern was actually regarding fidelity; DOTS will have auth reds.

creds, credentials

>> We're working on the signaling protocol, and functions directly associated
>> therewith.  This gets into other areas which may be interesting, but not
>> part of what we're directly trying to accomplish with DOTS.
>>