Subject: [Dots] Draft Charter

From: "Teague, Nik" <[email-masked]>
Date: Tue, 21 Apr 2015 16:24:31 +0000

Hi,

Please see a 1st pass draft charter below - comments and feedback always
welcome.

-Nik

The aim of DDoS Open Threat Signaling (DOTS) is to develop a standards
based approach to the real time signaling of DDoS related telemetry and
threat handling data between elements concerned with attack mitigation.

The elements may be described as:
* On-premise DDoS mitigation platforms
* Service provider DDoS mitigation platforms
* Other network devices/platforms that are able to sense DDoS and respond
* Chained instances of the above

These elements may be communicating inter-domain or intra-domain over
links that may be congested by attack traffic resulting in hostile
conditions for traditional connection oriented approaches and more
generalized signaling and telemetry solutions.  Robustness under these
conditions is paramount while ensuring appropriate regard for
authentication, authorization, privacy and data integrity.  Elements may
be deployed as part of a wider strategy incorporating multiple points of
detection and mitigation, both on premise or service provider based.
Should mitigation need to move between elements in the chain then
effective signaling of telemetry and current threat handling is essential.
 Feedback between participating elements is required for increased
awareness for effective decision making.

The WG will, where appropriate, reuse existing standard protocols and
mechanisms, for instance IPFIX and its templating mechanism.

The charter of the working group is to produce one or more standards track
specification to provide for this open signaling in the DDoS problem
space.  While the resulting standards should be designed so that there¹s a
possibility of applying them to network security applications beyond DDoS
mitigation, this working group will focus on just DDoS mitigation.  This
streamlined focus of the charter is intended to lead to an earlier result
due to community interests in having such capability in a short timeframe.
 The specification(s) produced by the WG will include a standard mechanism
for authentication and authorization, for data integrity, and for
providing for privacy in operation.

The WG will produce the following deliverables:

* Use case document to ensure commonality of the work among the
participants in the Working Group.  This document may be determined by the
working group to remain informal and not be published.
* Document or Documents describing the problem space, use cases, protocol
requirements and other qualifying information as the WG sees fit.
* Document or Documents specifying a protocol and associated data models
to address the WG stated goal.

---

From: "Adam W. Montville" <[email-masked]>
Date: Wed, 22 Apr 2015 08:35:17 -0500

Well-written, Nik.  I spotted a couple of minor nits (there may be others), and have a couple of observations/comments - all inline.

> On Apr 21, 2015, at 11:24 AM, Teague, Nik <[email-masked]> wrote:
> 
> Hi,
> 

The first two points seem pretty tight, but the third bullet seems less so.  As a reader, it feels that you may have wanted to write something like “Other DDoS mitigation platforms”, but didn’t for what is likely an important reason.  Maybe another way to look at it is that the first two bullets seem to be distinguished based on mitigation platform location, but the third is a catch-all not necessarily related to location.  

This isn’t a suggestion to change, but an observation you might choose to consider to clarify your meaning.

> effective signaling of telemetry and current threat handling is essential.

Consider a comma between “chain” and “then” resulting in: “Should mitigation need to move between elements in the chain, then…"

> awareness for effective decision making.

Could this be “…required for increased awareness supporting effective decision making”?

> mechanisms, for instance IPFIX and its templating mechanism.

Would it be helpful to also say that you intend (if you do) to coordinate efforts with other working groups that may be working on similar problems?  Consider i2nsf, supa, sacm, and mile.  Some of these have standards you might leverage, but others are still working on solutions.  In sacm, for example, we are working to define models and protocols based on endpoint posture assessment, which includes some expression of policy, endpoint attributes, and so on. Pieces of these things may be useful to dots.

> space.  

Make “specification” plural, so that the sentence reads: “…to produce one or more standards track specifications…”.

> While the resulting standards should be designed so that there¹s a
> mitigation, this working group will focus on just DDoS mitigation.  

The ‘ in “there’s” came up funny (probably a copy/paste issue).

> This

Something we recently did in sacm is to create a milestone for revisiting milestones.  The idea is that we know we’re going to have some data models and protocols, but we’re not sure how many or how they might be divided among multiple drafts.  Something like that could be useful here as well, because it is clear that you will have models and protocols, but it’s not clear how that work will ultimately materialize.

It might be too early, but do you have any idea as to dates for these milestones?

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

---

From: Linda Dunbar <[email-masked]>
Date: Wed, 22 Apr 2015 22:47:21 +0000

I have a few questions on the DOTS scope:

on the this paragraph:

> authentication, authorization, privacy and data integrity.

Is it the goal of the DOTS group to ensure the secure channels and congestion status for paths between the On-premise DDoS mitigation platforms and the  Service provider DDoS mitigation platforms?

Is it in the scope for DDOS elements to communicate with Network Management system to figure out an optimal path between the DDOS elements? 

Linda

-----Original Message-----
From: Dots [mailto:[email-masked]] On Behalf Of Adam W. Montville
Sent: Wednesday, April 22, 2015 8:35 AM
To: Teague, Nik
Cc: [email-masked]
Subject: Re: [Dots] Draft Charter

> Please see a 1st pass draft charter below - comments and feedback 
> always welcome.
> 
> -Nik
> 
> 
> based approach to the real time signaling of DDoS related telemetry 
> and threat handling data between elements concerned with attack mitigation.
> 

The first two points seem pretty tight, but the third bullet seems less so.  As a reader, it feels that you may have wanted to write something like "Other DDoS mitigation platforms", but didn't for what is likely an important reason.  Maybe another way to look at it is that the first two bullets seem to be distinguished based on mitigation platform location, but the third is a catch-all not necessarily related to location.  

This isn't a suggestion to change, but an observation you might choose to consider to clarify your meaning.

> authentication, authorization, privacy and data integrity.  Elements 
> may be deployed as part of a wider strategy incorporating multiple 
> points of detection and mitigation, both on premise or service provider based.

Consider a comma between "chain" and "then" resulting in: "Should mitigation need to move between elements in the chain, then."

> awareness for effective decision making.

Could this be ".required for increased awareness supporting effective decision making"?

> 
> The charter of the working group is to produce one or more standards 
> track specification to provide for this open signaling in the DDoS 
> problem space.

Make "specification" plural, so that the sentence reads: ".to produce one or more standards track specifications.".

> possibility of applying them to network security applications beyond 
> DDoS mitigation, this working group will focus on just DDoS mitigation.

The ' in "there's" came up funny (probably a copy/paste issue).

> This
> streamlined focus of the charter is intended to lead to an earlier 
> result due to community interests in having such capability in a short timeframe.
> The specification(s) produced by the WG will include a standard 
> mechanism for authentication and authorization, for data integrity, 
> and for providing for privacy in operation.
> 
> participants in the Working Group.  This document may be determined by 
> the working group to remain informal and not be published.
> * Document or Documents describing the problem space, use cases, 
> protocol requirements and other qualifying information as the WG sees fit.
> * Document or Documents specifying a protocol and associated data 
> models to address the WG stated goal.

Something we recently did in sacm is to create a milestone for revisiting milestones.  The idea is that we know we're going to have some data models and protocols, but we're not sure how many or how they might be divided among multiple drafts.  Something like that could be useful here as well, because it is clear that you will have models and protocols, but it's not clear how that work will ultimately materialize.

---

From: Scott Barvick <[email-masked]>
Date: Thu, 23 Apr 2015 15:49:13 +0000

Linda,

If I understand your questions, IMO  the answer to both of them is no, but
we do need to clarify.

1) “ensure … congestion status”   -  Under a big DDoS attack, the inbound
link to the DDoS device may be so saturated that ‘traditional methods…
solutions” will not work because they most likely utilize 2 way
(connection-oriented) traffic.   If the inbound link is saturated, we
might only be able to “reliably” get the situation signaled through a
connectionless protocol that counts on repetition and statistical
likelihood for success.  So, I don’t think we can ensure congestion status
(other than designing for congestion:).

2) “ensure secure channels” .   The channel is not dedicated so the
protocol needs to do the right thing, as the charter says about “…
Appropriate regard for … data integrity”.  If my channel, you mean the
logical channel between the devices, then, yes, I think we have to address
that.

3) At least in the first round, I don’t see us having the DDoS elements
trying to figure out optimal paths between the devices.   The DDoS devices
signal, the upstream receivers take action, and the routing/rerouting
happens around the DDoS devices.

Regards,
Scott

On 4/22/15, 6:47 PM, "Linda Dunbar" <[email-masked]> wrote:

>Is it the goal of the DOTS group to ensure the secure channels and
>congestion status for paths between the On-premise DDoS mitigation
>platforms and the  Service provider DDoS mitigation platforms?
>
>Is it in the scope for DDOS elements to communicate with Network
>Management system to figure out an optimal path between the DDOS
>elements? 
>
>Linda
>
>Well-written, Nik.  I spotted a couple of minor nits (there may be
>others), and have a couple of observations/comments - all inline.
>
>The first two points seem pretty tight, but the third bullet seems less
>so.  As a reader, it feels that you may have wanted to write something
>like "Other DDoS mitigation platforms", but didn't for what is likely an
>important reason.  Maybe another way to look at it is that the first two
>bullets seem to be distinguished based on mitigation platform location,
>but the third is a catch-all not necessarily related to location.
>
>Consider a comma between "chain" and "then" resulting in: "Should
>mitigation need to move between elements in the chain, then."
>
>Would it be helpful to also say that you intend (if you do) to coordinate
>efforts with other working groups that may be working on similar
>problems?  Consider i2nsf, supa, sacm, and mile.  Some of these have
>standards you might leverage, but others are still working on solutions.
>In sacm, for example, we are working to define models and protocols based
>on endpoint posture assessment, which includes some expression of policy,
>endpoint attributes, and so on. Pieces of these things may be useful to
>dots.
>
>
>> 
>Make "specification" plural, so that the sentence reads: ".to produce one
>or more standards track specifications.".
>
>Something we recently did in sacm is to create a milestone for revisiting
>milestones.  The idea is that we know we're going to have some data
>models and protocols, but we're not sure how many or how they might be
>divided among multiple drafts.  Something like that could be useful here
>as well, because it is clear that you will have models and protocols, but
>it's not clear how that work will ultimately materialize.
>

---

From: "Teague, Nik" <[email-masked]>
Date: Thu, 23 Apr 2015 17:00:32 +0000

Adam hi,

Thanks! - comments inline to the inline re scope, collaboration,
milestones.

On 22/04/2015 14:35, "Adam W. Montville" <[email-masked]>
wrote:

>...
>like ³Other DDoS mitigation platforms², but didn¹t for what is likely an
>This isn¹t a suggestion to change, but an observation you might choose to
>consider to clarify your meaning.

This is a little vague, yes.  What I was trying to express was a way to
define other devices (routers, firewalls, ids, monitoring platforms etc.)
that may be able to make a basic assessment on traffic profile that a DDoS
is occurring and signal such.  These components may not have a specific
DDoS focus but may be able to still participate in the
detection/mitigation.  My concern was expressing such so as not to mire
the scope by making it too wide ranging while still attempting to address
the need.  Or maybe we should just omit stating such explicitly  above and
have it covered by the more implicit statement:

"While the resulting standards should be designed so that there¹s a
possibility of applying them to network security applications beyond DDoS
mitigation, this working group will focus on just DDoS mitigation.²

>...

Yes this should be a consideration and we should endeavour to understand
where we can collaborate and leverage some of the parallel efforts.

>...
>milestones.  The idea is that we know we¹re going to have some data
>models and protocols, but we¹re not sure how many or how they might be
>it¹s not clear how that work will ultimately materialize.
>

I agree on the milestone re-evaluation - I don¹t have dates yet on
milestones - I still think we need a little more work there before we can
agree on those.

Thanks again,

-Nik

---

From: "Xialiang (Frank)" <[email-masked]>
Date: Fri, 24 Apr 2015 01:54:22 +0000

Hi Nik,
Firstly, thanks for your excellent work on the charter. I think it's good and capture most of our thoughts about DOTS work.
I also have some comments as followed:
1. Please do not limit the possible elements (network devices such as router, switch) involved in the Anti-DDoS work of DOTS architecture now, because they represent different use case with respective pro and con. We will have more materials to elaborate more use cases under the same DOTS scope. We think they can increase DOTS value without new influence to it.
2. should we consider the initial negotiation mechanism and the openness mechanism for DOTS to adapt to new kind of DDoS attacks? My suggested modification is: "Feedback and initial capability negotiation mechanisms between participating elements is required for increased awareness for effective decision making."

B.R.
Frank

-----邮件原件-----
发件人: Dots [mailto:[email-masked]] 代表 Teague, Nik
发送时间: 2015年4月24日 1:01
收件人: Adam W. Montville
抄送: [email-masked]
主题: Re: [Dots] Draft Charter

Adam hi,

Thanks! - comments inline to the inline re scope, collaboration, milestones.

On 22/04/2015 14:35, "Adam W. Montville" <[email-masked]>
wrote:

>...
>> 
>> 
>> The aim of DDoS Open Threat Signaling (DOTS) is to develop a 
>> standards based approach to the real time signaling of DDoS related 
>> telemetry and threat handling data between elements concerned with attack mitigation.
>> 
>like ³Other DDoS mitigation platforms², but didn¹t for what is likely 
>an important reason.  Maybe another way to look at it is that the first 
>two bullets seem to be distinguished based on mitigation platform 
>location, but the third is a catch-all not necessarily related to location.
>
>This isn¹t a suggestion to change, but an observation you might choose 
>to consider to clarify your meaning.

This is a little vague, yes.  What I was trying to express was a way to define other devices (routers, firewalls, ids, monitoring platforms etc.) that may be able to make a basic assessment on traffic profile that a DDoS is occurring and signal such.  These components may not have a specific DDoS focus but may be able to still participate in the detection/mitigation.  My concern was expressing such so as not to mire the scope by making it too wide ranging while still attempting to address the need.  Or maybe we should just omit stating such explicitly  above and have it covered by the more implicit statement:

"While the resulting standards should be designed so that there¹s a possibility of applying them to network security applications beyond DDoS mitigation, this working group will focus on just DDoS mitigation.²

>Would it be helpful to also say that you intend (if you do) to 
>coordinate efforts with other working groups that may be working on 
>similar problems?  Consider i2nsf, supa, sacm, and mile.  Some of these 
>have standards you might leverage, but others are still working on solutions.
>In sacm, for example, we are working to define models and protocols 
>based on endpoint posture assessment, which includes some expression of 
>policy, endpoint attributes, and so on. Pieces of these things may be 
>useful to dots.

Yes this should be a consideration and we should endeavour to understand where we can collaborate and leverage some of the parallel efforts.

>
>...
>
>Something we recently did in sacm is to create a milestone for 
>revisiting milestones.  The idea is that we know we¹re going to have 
>some data models and protocols, but we¹re not sure how many or how they 
>might be divided among multiple drafts.  Something like that could be 
>useful here as well, because it is clear that you will have models and 
>protocols, but it¹s not clear how that work will ultimately materialize.
>

I agree on the milestone re-evaluation - I don¹t have dates yet on milestones - I still think we need a little more work there before we can agree on those.

Thanks again,

-Nik