Subject: Re: [Dots] Draft Charter

From: Andrew Mortensen <[email-masked]>
Date: Sat, 2 May 2015 01:28:36 -0400

Hi Nik. Thanks for giving us a good foundation to build upon.

Comments/nitpicks inline, trying not to overlap too much with Adam.

andrew

--

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

I think the “real time” phrase here is intended to emphasize that the signaling is expected to be done under attack conditions. That seems to me an important differentiator from mile. We should make it explicit here.

> 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

Something along the lines of “Other devices with network perspective performing traffic analysis”  or “…engaged in traffic analysis” should encompass things like flow monitoring and IDS/IPS.

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

Strike “traditional”. Regardless of innovation, a connection-oriented protocol is not appropriate for dots for the reasons you’ve just stated. I think this can be tightened to, e.g., “…hostile conditions for connection-oriented signaling and telemetry protocols.”

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

Is the implication that an on-premise device may signal laterally intentional? Or is the expectation that each subsequent element in the chain will be upstream from the previous?

> 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

“…designed so they may apply to network security applications…"

> mitigation, this working group will focus on just DDoS mitigation.

Strike “just”.

> 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: Kathleen Moriarty <[email-masked]>
Date: Sat, 9 May 2015 13:28:12 -0400

Are there any other comments on the proposed charter?  If you've read it and do not have changes, expressions of support for the current version would be helpful to understand how many folks agree this is important and want to work on this in the IETF.

Thank you,
Kathleen 

Sent from my iPhone

> On May 2, 2015, at 1:28 AM, Andrew Mortensen <[email-masked]> wrote:
> 
> _______________________________________________
> Dots mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dots

---

From: Dave Larson <[email-masked]>
Date: Sat, 9 May 2015 17:32:53 +0000

I support this charter - and I am prepared to support this work within the
IETF.  This is critically important work for dealing with a difficult
problem today and ensuring an ongoing robust response as the issue of DDoS
is only getting worse.

Dave 

On 5/9/15, 12:28 PM, "Kathleen Moriarty"
<[email-masked]> wrote:

>Are there any other comments on the proposed charter?  If you've read it
>and do not have changes, expressions of support for the current version
>would be helpful to understand how many folks agree this is important and
>want to work on this in the IETF.
>
>Thank you,
>Kathleen 
>
>Sent from my iPhone
>
>> I think the “real time” phrase here is intended to emphasize that the
>>signaling is expected to be done under attack conditions. That seems to
>>me an important differentiator from mile. We should make it explicit
>>here.
>> 
>> Something along the lines of “Other devices with network perspective
>>performing traffic analysis”  or “…engaged in traffic analysis” should
>>encompass things like flow monitoring and IDS/IPS.
>> 
>> Strike “traditional”. Regardless of innovation, a connection-oriented
>>protocol is not appropriate for dots for the reasons you’ve just stated.
>>I think this can be tightened to, e.g., “…hostile conditions for
>>connection-oriented signaling and telemetry protocols.”
>> 
>>> Robustness under these
>> Is the implication that an on-premise device may signal laterally
>>intentional? Or is the expectation that each subsequent element in the
>>chain will be upstream from the previous?
>>

---

From: "Xialiang (Frank)" <[email-masked]>
Date: Mon, 11 May 2015 01:15:42 +0000

Hi All,
I support the charter with some comments proposed before.
I also think this work is valuable for Anti-DDoS technologies evolution.

B.R.
Frank

-----邮件原件-----
发件人: Dots [mailto:[email-masked]] 代表 Kathleen Moriarty
发送时间: 2015年5月10日 1:28
收件人: Andrew Mortensen
抄送: Teague, Nik; [email-masked]
主题: Re: [Dots] Draft Charter

Thank you,
Kathleen 

Sent from my iPhone

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

---

From: Daniel Migault <[email-masked]>
Date: Mon, 11 May 2015 16:45:20 +0000

I support the charter.

-----Original Message-----
From: Dots [mailto:[email-masked]] On Behalf Of Kathleen Moriarty
Sent: Saturday, May 09, 2015 1:28 PM
To: Andrew Mortensen
Cc: Teague, Nik; [email-masked]
Subject: Re: [Dots] Draft Charter

Thank you,
Kathleen 

Sent from my iPhone

---

From: Scott Barvick <[email-masked]>
Date: Tue, 12 May 2015 02:03:40 +0000

Kathleen,

I’ll also add my support for the charter and commitment to actively work on the deliverables that it defines.

Regards,
Scott

---

From: "Tirumaleswar Reddy (tireddy)" <[email-masked]>
Date: Tue, 12 May 2015 02:06:01 +0000

+1.

-Tiru

> From: Dots [mailto:[email-masked]] On Behalf Of Daniel Migault
> Sent: Monday, May 11, 2015 10:15 PM
> To: Kathleen Moriarty; Andrew Mortensen
> Are there any other comments on the proposed charter?  If you've read it and
> do not have changes, expressions of support for the current version would be
> helpful to understand how many folks agree this is important and want to
> work on this in the IETF.
> 
> Thank you,
> Kathleen
> 
> Sent from my iPhone
> 
> signaling is expected to be done under attack conditions. That seems to me
> an important differentiator from mile. We should make it explicit here.
> >
> protocol is not appropriate for dots for the reasons you’ve just stated. I think
> this can be tightened to, e.g., “…hostile conditions for connection-oriented
> signaling and telemetry protocols.”
> >
> >> Robustness under these
> intentional? Or is the expectation that each subsequent element in the chain
> will be upstream from the previous?
> >

---

From: Sean Turner <[email-masked]>
Date: Tue, 12 May 2015 09:55:44 +0200

+1 with the tweaks suggested by Adam & Andrew.

spt

---

From: Andrew Mortensen <[email-masked]>
Date: Tue, 12 May 2015 04:44:06 -0400

> Are there any other comments on the proposed charter?  If you've read it and do not have changes, expressions of support for the current version would be helpful to understand how many folks agree…

I support and will contribute to dots. It fills a narrow but significant gap in attack response coordination, at a time when confronting attacks of increasing frequency and scale demands effective cross-organizational collaboration. 

As I’ve indicated with my suggested changes, I believe the current charter draft requires some minor revisions, but in general effectively and succinctly communicates the scope and aims of the work ahead.

One issue I do want to see addressed is visible the following extracts:

“...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.**” (Emphasis added)

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

“Appropriate regard for authentication, authorization, privacy and data integrity” while expecting to use IPFIX in “hostile conditions for traditional connection oriented approaches” seems to dictate the use of IPFIX+DTLS, but Brian Trammel warned against using it during the BoF (“Please think very hard about whether this is going to work under attack”, <https://www.ietf.org/proceedings/92/minutes/minutes-92-dots>).

Kathleen, you alluded to the same issue on the i2nsf list (http://www.ietf.org/mail-archive/web/i2nsf/current/msg00327.html):

"DOTS will have to stick to very specific requirements to be effective with a transport during a DDoS attack. IPFIX was consistent across proposals, but the choice of UDP may change once Brian Trammel's analysis is shared.”

Is there analysis to be shared? It seems to me the needs laid out in the charter—signaling over extremely congested pipes while ensuring message integrity and security—require a common understanding of IPFIX+DTLS's ability to meet them.

andrew

---

From: Tobias Gondrom <[email-masked]>
Date: Tue, 12 May 2015 21:29:05 +0200

I agree that this is important work for the community and should be done.
And overall, I do support the proposed charter with adjustments as 
suggested by several people here on the mailing-list.
Best regards, Tobias

---

From: Rich Groves <[email-masked]>
Date: Tue, 12 May 2015 21:38:44 +0000

+1  I support the charter. Agreed that it is important and we commit to work actively on it.
On May 12, 2015, at 12:29 PM, Tobias Gondrom <[email-masked]<mailto:[email-masked]>> wrote:

I agree that this is important work for the community and should be done.
And overall, I do support the proposed charter with adjustments as suggested by several people here on the mailing-list.
Best regards, Tobias

Thank you,
Kathleen

Sent from my iPhone

On May 2, 2015, at 1:28 AM, Andrew Mortensen <[email-masked]><mailto:[email-masked]> wrote:

andrew

--

Robustness under these

Strike “just”.

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

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

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

---

From: Linda Dunbar <[email-masked]>
Date: Tue, 12 May 2015 22:14:45 +0000

I support the charter, with some suggestion on the wording:

Since it is not within DOTS scope to figure out "congestion status" of the links/paths nor ensure zero packet loss,  the charter should simply say:

 "These elements may be communicating over congested links/paths, with possibility of packets loss.  Therefore, mechanisms have be considered to compensate packets loss to ensure appropriate regard for authentication, authorization, privacy and data integrity." 

Instead of the following wording:
>> links/path that may be congested by attack traffic resulting in hostile 
>> generalized signaling and telemetry solutions.  Robustness under 
>> these conditions is paramount while ensuring appropriate regard for 
>> authentication, authorization, privacy and data integrity.

Linda Dunbar

-----Original Message-----
From: Scott Barvick [mailto:[email-masked]] 
Sent: Thursday, April 23, 2015 10:49 AM
To: Linda Dunbar; Adam W. Montville; Teague, Nik
Cc: [email-masked]
Subject: Re: [Dots] Draft Charter

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:

>I have a few questions on the DOTS scope:
>
>on the this paragraph:
>
>> generalized signaling and telemetry solutions.  Robustness under 
>> these conditions is paramount while ensuring appropriate regard for 
>> 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
>
>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]
>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,
>> 
>> Please see a 1st pass draft charter below - comments and feedback 
>> always welcome.
>> 
>> -Nik
>> 
>> 
>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.
>
>>generalized signaling and telemetry solutions.  Robustness under these  
>Consider a comma between "chain" and "then" resulting in: "Should 
>mitigation need to move between elements in the chain, then."
>
>Could this be ".required for increased awareness supporting effective 
>decision making"?
>
>> 
>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.
>
>
>> 
>> problem 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 
>> 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.
>>participants in the Working Group.  This document may be determined by  
>>the working group to remain informal and not be published.
>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?
>
>>

---

From: Kathleen Moriarty <[email-masked]>
Date: Tue, 12 May 2015 20:34:56 -0400

Interesting.  I read the current text with the intent of your proposed text, but if others read it differently, adjustments may be helpful.  I do like the wording of the original, so maybe it could be tweaked a bit to make sure Linda's point is clear?

Thanks,
Kathleen
(No hat) 

Sent from my iPhone

> On May 12, 2015, at 6:14 PM, Linda Dunbar <[email-masked]> wrote:
>

---

From: Scott Barvick <[email-masked]>
Date: Wed, 13 May 2015 01:11:28 +0000

I don’t think that the original implies that the elements need to determine congestion status nor ensure zero packet loss, just be robust and secure in the face of them.   I also agree that the new suggestion is functionally equivalent so I think we should stick with the current proposal because it makes the important point that this work is not covered by existing or other proposed efforts.

Scott

---

From: Zongning <[email-masked]>
Date: Wed, 13 May 2015 03:51:42 +0000

Hi,

I support the current DOTS charter. Just some general suggestions:
1. why doesn't DOTS consider the centralized architecture which includes a centralized analysis and control platform? Comparing the distributed way, a centralized platform has advantage of forming a holistic view of network threat for detection, and generating the overall optimized security policies for mitigation. A typical example is defending against the APT attacks in network; 2. Only reuse IPFIX is not enough, DOTS works need to extend it with new IPFIX elements for special security requirements; 3. Maybe a framework document is needed to describe the whole solution, include: its components, the logic relations and communication protocols between them...

Thanks.

-Ning

-----邮件原件-----
发件人: Dots [mailto:[email-masked]] 代表 Kathleen Moriarty
发送时间: 2015年5月10日 1:28
收件人: Andrew Mortensen
抄送: Teague, Nik; [email-masked]
主题: Re: [Dots] Draft Charter

Thank you,
Kathleen 

Sent from my iPhone

---

From: Linda Dunbar <[email-masked]>
Date: Wed, 13 May 2015 15:13:35 +0000

If everyone agrees, it is fine with me. 

I just wanted to emphasize that packet loss happens even without security attacks, with connection oriented or connectionless oriented path. 

I.e. Events/data exchanges among DDoS devices have to consider mechanism to mitigate packet loss. 

Linda

-----Original Message-----
From: Scott Barvick [mailto:[email-masked]] 
Sent: Tuesday, May 12, 2015 8:11 PM
To: Kathleen Moriarty
Cc: Linda Dunbar; Adam W. Montville; Nik Teague; [email-masked]
Subject: Re: [Dots] Draft Charter

I don't think that the original implies that the elements need to determine congestion status nor ensure zero packet loss, just be robust and secure in the face of them.   I also agree that the new suggestion is functionally equivalent so I think we should stick with the current proposal because it makes the important point that this work is not covered by existing or other proposed efforts.

Scott

On May 12, 2015, at 8:34 PM, Kathleen Moriarty <[email-masked]> wrote:

>>>> These elements may be communicating inter-domain or intra-domain 
>>>> over links/path 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.
>> 
>> Linda Dunbar
>> 
>>>> 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.
>>> 
>>>> standards  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.
>>> 
>>>> 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.
>>> Could this be ".required for increased awareness supporting 
>>> effective decision making"?
>>> 
>>>> 
>>>> The WG will, where appropriate, reuse existing standard protocols 
>>>> and mechanisms, for instance IPFIX and its templating mechanism.
>>> 
>>> similar problems?  Consider i2nsf, supa, sacm, and mile.  Some of 
>>> these have standards you might leverage, but others are still working on solutions.
>>> 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.
>>> 
>>> 
>>>> 
>>>> 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.
>>> 
>>>> result due to community interests in having such capability in a 
>>>> short timeframe.
>>> 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?
>>> 
>>>>

---

From: Danny McPherson <[email-masked]>
Date: Fri, 15 May 2015 06:58:05 -0600

On 2015-05-12 18:34, Kathleen Moriarty wrote: 

> Interesting. I
read the current text with the intent of your proposed text, but if
others read it differently, adjustments may be helpful. I do like the
wording of the original, so maybe it could be tweaked a bit to make sure
Linda's point is clear?

I believe the current text and discussion
around robustness and congestion is precisely addressing Linda's point.

I support the current charter as well.

-danny