Subject: [Dots] Consolidation of all draft charter feedback

From: "Roman D. Danyliw" <[email-masked]>
Date: Sun, 17 May 2015 02:26:01 +0000

Hello!

There has been robust discussion on the draft charter text (http://www.ietf.org/mail-archive/web/dots/current/msg00077.html).  To make it easier to review the draft charter with the benefit of previous feedback, below you can find a summary of all comments to date aggregated inline with corresponding links.  

Per Kathleen Moriarty's request (http://www.ietf.org/mail-archive/web/dots/current/msg00074.html), please provide further commentary or statements of support.

Roman

----[ Aggregated comments on the draft charter ]----

> 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

[Andrew Mortensen] suggested that "real time" signaling is expected under attack conditions, and that this detail should be noted explicitly in http://www.ietf.org/mail-archive/web/dots/current/msg00086.html

> 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

[Adam Montville] suggested to tighten up the language of this third bullet in
http://www.ietf.org/mail-archive/web/dots/current/msg00080.html

--
[Nik Teague] proposed to the following text in response to Adam:

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

in http://www.ietf.org/mail-archive/web/dots/current/msg00083.html

--
[Xialiang (Frank)] Recommended leaving the third bullet vague pending a review of the use cases in
http://www.ietf.org/mail-archive/web/dots/current/msg00085.html

--
[Andrew Mortensen] suggested "Other devices with network perspective performing traffic analysis"  or ".engaged in traffic analysis"

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

[Andrew Mortensen] suggested removing "traditional" in http://www.ietf.org/mail-archive/web/dots/current/msg00086.html

> 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

[Adam Montville] suggested a comma between "chain" and "then" resulting in: "Should mitigation need to move between elements in the chain, then." in http://www.ietf.org/mail-archive/web/dots/current/msg00080.html

--
[Linda Dunbar] sought clarity on whether the following items were in scope:
* determining the optimal path between DDOS elements determined in concert with the Network Management system
* ensuring the secure channels and congestion status for paths between the mitigating devices

In http://www.ietf.org/mail-archive/web/dots/current/msg00081.html

--
[Scott Barvick] replied to [Linda Dunbar] on this scope in http://www.ietf.org/mail-archive/web/dots/current/msg00082.html

--
[Andrew Mo ] sought clarity on whether "... 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?" in http://www.ietf.org/mail-archive/web/dots/current/msg00086.html

--
[Linda Dunbar] suggested updated text that reads as "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." In http://www.ietf.org/mail-archive/web/dots/current/msg00102.html

--
[Scott Barvick] in http://www.ietf.org/mail-archive/web/dots/current/msg00104.html and [Kathleen Moriarty] in http://www.ietf.org/mail-archive/web/dots/current/msg00103.html believe the existing language covers [Linda Dunbar]'s proposal.

> effective signaling of telemetry and current threat handling is essential.
>  Feedback between participating elements is required for increased
> awareness for effective decision making.

[Adam Montville] suggested  ".required for increased awareness supporting effective decision making" in http://www.ietf.org/mail-archive/web/dots/current/msg00080.html

--
[Xialiang (Frank)] suggested "Feedback and initial capability negotiation mechanisms between participating elements is required for increased awareness for effective decision making." in http://www.ietf.org/mail-archive/web/dots/current/msg00085.html

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

[Adam Montville] suggested mentioning other working groups in 
http://www.ietf.org/mail-archive/web/dots/current/msg00080.html

--
[Andrew ] highlighted the inherent conflict between reusing IPFIX (stated here) and the limitation of "traditional connection oriented protocols" (stated above in the chart) in http://www.ietf.org/mail-archive/web/dots/current/msg00098.html

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

[Adam Montville] suggested making "specification" plural, so that the sentence reads: ".to produce one or more standards track specifications." in http://www.ietf.org/mail-archive/web/dots/current/msg00080.html

> While the resulting standards should be designed so that there¹s a possibility
> of applying them to network security applications beyond DDoS mitigation,

[Andrew Mortensen] suggested using ".designed so they may apply to network security applications." in http://www.ietf.org/mail-archive/web/dots/current/msg00086.html

> this working group will focus on just DDoS mitigation.  This streamlined focus

[Andrew Mortensen] suggested removing "just" in http://www.ietf.org/mail-archive/web/dots/current/msg00086.html

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

[Adam Montville] suggested adding a milestone to review milestones and specific dates for these in 
http://www.ietf.org/mail-archive/web/dots/current/msg00080.html

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

---

From: Daniel Migault <[email-masked]>
Date: Tue, 19 May 2015 14:13:46 +0000

Hi, 

I suggest to remove the first milestone item:

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

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

BR, 
Daniel
-----Original Message-----
From: Dots [mailto:[email-masked]] On Behalf Of Roman D. Danyliw
Sent: Saturday, May 16, 2015 10:26 PM
To: [email-masked]
Subject: [Dots] Consolidation of all draft charter feedback

Hello!

Roman

> * Other network devices/platforms that are able to sense DDoS and 

[Adam Montville] suggested to tighten up the language of this third bullet in http://www.ietf.org/mail-archive/web/dots/current/msg00080.html

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

--
[Xialiang (Frank)] Recommended leaving the third bullet vague pending a review of the use cases in http://www.ietf.org/mail-archive/web/dots/current/msg00085.html

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

> mechanisms, for instance IPFIX and its templating mechanism.

[Adam Montville] suggested mentioning other working groups in http://www.ietf.org/mail-archive/web/dots/current/msg00080.html

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

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

[Adam Montville] suggested adding a milestone to review milestones and specific dates for these in http://www.ietf.org/mail-archive/web/dots/current/msg00080.html

---

From: John Schiel <[email-masked]>
Date: Tue, 19 May 2015 15:37:24 -0600

> I suggest to remove the first milestone item:

I kind of like the idea of a use case document as long as the examples 
are small and concise. It would provide a good reference tool for 
discussion and for developing the standard.

Thanks,

--John

---

From: Daniel Migault <[email-masked]>
Date: Tue, 19 May 2015 21:48:19 +0000

Hi, 

I also like the idea of a use case document and I think it is a helpful document to have. The reason I mentioned the first item could be removed is that use cases are already mentioned in the second item, and as such it looks redundant with the second item.

BR, 
Daniel 

-----Original Message-----
From: Dots [mailto:[email-masked]] On Behalf Of John Schiel
Sent: Tuesday, May 19, 2015 5:37 PM
To: [email-masked]
Subject: Re: [Dots] Consolidation of all draft charter feedback

> I suggest to remove the first milestone item:

I kind of like the idea of a use case document as long as the examples are small and concise. It would provide a good reference tool for discussion and for developing the standard.

Thanks,

--John

>> participants in the Working Group.  This document may be determined 
>> by the working group to remain informal and not be published.
>> 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
> [Andrew Mortensen] suggested that "real time" signaling is expected 
> under attack conditions, and that this detail should be noted 
> explicitly in 
> http://www.ietf.org/mail-archive/web/dots/current/msg00086.html
>
> DDoS mitigation, this working group will focus on just DDoS 
> mitigation.²
>
> [Andrew Mortensen] suggested removing "traditional" in 
> http://www.ietf.org/mail-archive/web/dots/current/msg00086.html
>
>> as part of a wider strategy incorporating multiple points of 
>> detection and mitigation, both on premise or service provider based.
> [Adam Montville] suggested a comma between "chain" and "then" 
> resulting in: "Should mitigation need to move between elements in the 
> chain, then." in 
> * determining the optimal path between DDOS elements determined in 
> concert with the Network Management system
> [Scott Barvick] replied to [Linda Dunbar] on this scope in 
> http://www.ietf.org/mail-archive/web/dots/current/msg00082.html
>
> --
> [Andrew Mo ] sought clarity on whether "... 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?" 
> in http://www.ietf.org/mail-archive/web/dots/current/msg00086.html
>
> --
> [Linda Dunbar] suggested updated text that reads as "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." In 
> http://www.ietf.org/mail-archive/web/dots/current/msg00102.html
>
> --
> [Adam Montville] suggested  ".required for increased awareness 
> supporting effective decision making" in 
> [Xialiang (Frank)] suggested "Feedback and initial capability 
> negotiation mechanisms between participating elements is required for 
> increased awareness for effective decision making." in 
> [Andrew ] highlighted the inherent conflict between reusing IPFIX 
> (stated here) and the limitation of "traditional connection oriented 
> protocols" (stated above in the chart) in 
> http://www.ietf.org/mail-archive/web/dots/current/msg00098.html
>
> [Adam Montville] suggested making "specification" plural, so that the 
> sentence reads: ".to produce one or more standards track 
> specifications." in 
> [Andrew Mortensen] suggested using ".designed so they may apply to 
> network security applications." in 
> http://www.ietf.org/mail-archive/web/dots/current/msg00086.html
>
> [Andrew Mortensen] suggested removing "just" in 
> http://www.ietf.org/mail-archive/web/dots/current/msg00086.html
>
>> participants in the Working Group.  This document may be determined 
>> by the working group to remain informal and not be published.

---

From: John Schiel <[email-masked]>
Date: Tue, 19 May 2015 16:57:55 -0600

> I also like the idea of a use case document and I think it is a helpful document to have. The reason I mentioned the first item could be removed is that use cases are already mentioned in the secon…

Daniel,

    Ahh, ok, point taken, I didn't see that. Was trying to work my way 
through the summarization  and missed that.

     Thanks for pointing that out.

--John