Subject: Re: [Dots] draft DOTS WG Charter [updated]

From: "Teague, Nik" <[email-masked]>
Date: Mon, 1 Jun 2015 19:13:57 +0000

Hi,

Having taken into account John and Sean¹s comments - please see an update
below.  Please let me know if you wish me to make any further revisions or
whether we can proceed with this so we can get this charter reviewed in
the next available slot.

Thanks!

-Nik

-[Charter for Working Group]-

The aim of DDoS Open Threat Signaling (DOTS) is to develop a standards
based approach for 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 devices/platforms with network perspective engaged in traffic
analysis

The elements may be chained for communication to construct a larger
collaborative system.

These elements may be communicating inter-domain or intra-domain over
links that may be congested by attack traffic resulting in hostile
conditions for 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 supporting
effective decision making.

The WG will, where appropriate, reuse or extend existing standard
protocols and mechanisms, for instance IPFIX and its templating mechanism.
 The WG may coordinate with other working groups and initiatives that
compliment the DOTS effort E.G. SACM, MILE, SUPA, I2NSF.

The charter of the working group is to produce one or more standards track
specifications to provide for this open signaling in the DDoS problem
space.  While the resulting standards should be designed so they apply to
network security applications beyond DDoS mitigation, this working group
will focus on DDoS mitigation.  Focusing the WG efforts on DDoS is
intended to meet the community's desire for a solution in the shorter
term.  The specification(s) produced by the WG will include a standard
mechanism for authentication and authorization, data integrity, and
providing for privacy in operation.

The WG will produce the following deliverables and milestones:

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

* Nov-2015: WG document for Requirements/Use Cases (informational)
* Mar-2016: WG document for Transport (proposed standard)
* Apr-2016: WG document for Data Model (proposed standard)

* Feb-2015: Requirements/Use Cases draft to IESG
* May-2016: Transport draft to IESG
* Jun-2016: Data Model draft to IESG

* Periodically re-examine milestones (3x month intervals)

---

From: Sean Turner <[email-masked]>
Date: Mon, 1 Jun 2015 20:57:59 -0700

Thanks for incorporating my comments.  This looks good to me.

spt

---

From: "Roland Dobbins" <[email-masked]>
Date: Tue, 02 Jun 2015 14:58:33 +0700

On 21 May 2015, at 0:02, Teague, Nik wrote:

> Thoughts/feedback of course valued and welcome.

-----

Change this:

> the real time signaling of DDoS related telemetry and

to this:

the realtime signaling of DDoS-related telemetry and threat handling 
requests and data between elements concerned with DDoS attack detection, 
classification, traceback, and mitigation.

-----

> * Other devices/platforms with network perspective engaged in traffic

to this:

  * Other network elements and services with the ability to analyze 
and/or influence network traffic.

-----

> The elements may be chained for communication to construct a larger

to this:

These elements may participate in DDoS detection, classification, 
traceback, and mitigation individually or within the context of a larger 
collaborative system.

-----

Change this:

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

to this:

Elements may be deployed as part of a wider strategy incorporating 
multiple points of DDoS detection, classification, traceback, and 
mitigation, both on-premise or service-provider based.

-----

Change this:

> Should mitigation need to move between elements in the chain, then 
> effective signaling of
> telemetry and current threat handling is essential.

to this:

Should changing conditions necessitate altering the specifics of 
mitigation actions and/or the topological scope of mitigation coverage, 
timely and effective signaling of telemetry and current threat status to 
all elements involved in the mitigation is essential.

-----

> protocols and mechanisms, for instance IPFIX and its templating 

to this:

The WG will, where appropriate, reuse or extend existing standard 
protocols and mechanisms (for example, IPFIX and its associated 
templating and extension mechanisms).

-----

> compliment the DOTS effort E.G. SACM, MILE, SUPA, I2NSF.

to this:

The WG may coordinate on a situationally-appropriate basis with other 
working groups and initiatives which
compliment the DOTS effort - e.g., SACM, MILE, SUPA, I2NSF, et. al.

-----

Change this:

> While the resulting standards should be designed so they apply to
> will focus on DDoS mitigation.

to this:

While the resulting standards should be designed so they can be applied 
to network security applications beyond the DDoS problem space, this 
working group will focus on signaling and coordination mechanisms 
directly related to DDoS attack detection, classification, traceback, 
and mitigation, incorporating the general principles articulated in 
RFC5218 <https://tools.ietf.org/html/rfc5218>.

-----

Change this:

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

to this:

This streamlined nature of this charter is intended to lead to the 
timely development of deployable mechanisms due to strong community 
interest in reaping the benefits of the described capabilities in the 
near term.

-----

> to address the WG stated goal.

to this:

* Document or Documents specifying protocols and associated data models 
to address the stated goals of the WG.

-----

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

---

From: "Teague, Nik" <[email-masked]>
Date: Tue, 2 Jun 2015 13:44:06 +0000

Hi,

I¹ve merged Roland¹s suggestions into the charter below.

Thanks,

-Nik

The aim of DDoS Open Threat Signaling (DOTS) is to develop a standards
based approach for the realtime signaling of DDoS related telemetry and
threat handling requests and data between elements concerned with DDoS
attack detection, classification, traceback and mitigation.

The elements may be described as:
* On-premise DDoS mitigation platforms
* Service provider DDoS mitigation platforms
* Other network elements and services with the ability to analyze and/or
influence network traffic

Elements may participate in DDoS detection, classification, traceback and
mitigation individually or within the context of a larger collaborative
system.

These elements may be communicating inter-domain or intra-domain over
links that may be congested by attack traffic resulting in hostile
conditions for 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 DDoS detection,
classification, traceback and mitigation, both on premise or service
provider based.  Should changing conditions necessitate altering the
specifics of mitigation actions and/or the topological scope of mitigation
coverage, timely and effective signaling of telemetry and current threat
status to all elements involved in the mitigation is essential.  Feedback
between participating elements is required for increased awareness
supporting effective decision making.

The WG will, where appropriate, reuse or extend existing standard
protocols and mechanisms (for example, IPFIX and its associated templating
and extension mechanisms).  The WG may coordinate on a situationally
appropriate basis with other working groups and initiatives which
compliment the DOTS effort e.g. SACM, MILE, SUPA, I2NSF et. al.

The charter of the working group is to produce one or more standards track
specifications to provide for this open signaling in the DDoS problem
space.  While the resulting standards should be designed so they apply to
network security applications beyond the DDoS problem space, this working
group will focus on signaling and coordination mechanisms directly related
to DDoS attack detection, classification, traceback and mitigation,
incorporating the general priniciples articulated in RFC5218
<https://tools.ietf.org/html/rfc5218>.  Focusing the WG efforts on DDoS is
intended to meet the community's desire for a solution in the shorter
term.  The specification(s) produced by the WG will include a standard
mechanism for authentication and authorization, data integrity, and
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 protocols and associated data models to
address the stated goals of the WG.

---

From: Kathleen Moriarty <[email-masked]>
Date: Tue, 2 Jun 2015 10:08:27 -0400

Thank you.  I'll wait until tomorrow to see if there is additional feedback and then will move the charter to the next review phase.

Thank you,
Kathleen

Sent from my iPhone

> On Jun 2, 2015, at 9:44 AM, "Teague, Nik" <[email-masked]> wrote:
> 
> Hi,
> 
> _______________________________________________
> Dots mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dots

---

From: John Schiel <[email-masked]>
Date: Tue, 02 Jun 2015 08:13:26 -0600

+1

--John

---

From: "Roland Dobbins" <[email-masked]>
Date: Tue, 02 Jun 2015 22:12:56 +0700

> I¹ve merged Roland¹s suggestions into the charter below.

Just some slight wordsmithing:

-----

Change this:

> Focusing the WG efforts on DDoS is intended to meet the community's 
> desire for a solution in the shorter term.

to this:

Focusing the WG efforts on DDoS is intended to meet the community's 
desire for a deployable solution in the near  term.

-----

Thanks again!

---

From: "Teague, Nik" <[email-masked]>
Date: Tue, 2 Jun 2015 15:31:46 +0000

Hi,

Updated again with Roland¹s last tweak...

-Nik

The charter of the working group is to produce one or more standards track
specifications to provide for this open signaling in the DDoS problem
space.  While the resulting standards should be designed so they apply to
network security applications beyond the DDoS problem space, this working
group will focus on signaling and coordination mechanisms directly related
to DDoS attack detection, classification, traceback and mitigation,
incorporating the general priniciples articulated in RFC5218
<https://tools.ietf.org/html/rfc5218>.  Focusing the WG efforts on DDoS is
intended to meet the community's desire for a deployable solution in the
near term.  The specification(s) produced by the WG will include a
standard mechanism for authentication and authorization, data integrity,
and providing for privacy in operation.

---

From: Tobias Gondrom <[email-masked]>
Date: Wed, 03 Jun 2015 10:53:18 +0200

Hi all,

looks good to me.
I fully support this WG and believe these are important elements for the 
Internet.

And I think it is good that we are quite open in the charter and do not 
exclude possible solution paths.
That will give us the opportunity to explore and combine various 
possible solution approaches to form the best defense.

Small nits for the charter:
Milestones:
s/* Feb-2015: Requirements/Use Cases draft to IESG/ * Mar-2015: 
Requirements/Use Cases draft to IESG

Best regards, Tobias

---

From: Tobias Gondrom <[email-masked]>
Date: Wed, 03 Jun 2015 13:01:32 +0200

Apologies. The nits was of course:

Milestones:
s/* Feb-2015: Requirements/Use Cases draft to IESG/ * Feb-2016: 
Requirements/Use Cases draft to IESG

Best, Tobias

On 03/06/15 10:53, Tobias Gondrom wrote:
> Hi all,
>
> looks good to me.
> I fully support this WG and believe these are important elements for 
> the Internet.
>
> And I think it is good that we are quite open in the charter and do 
> not exclude possible solution paths.

---

From: "Teague, Nik" <[email-masked]>
Date: Wed, 3 Jun 2015 13:13:12 +0000

Hi,

Updated to correct the nits Tobias highlighted on the milestone date
(Thanks!)

-Nik

* Feb-2016: Requirements/Use Cases draft to IESG
* May-2016: Transport draft to IESG
* Jun-2016: Data Model draft to IESG

---

From: Kathleen Moriarty <[email-masked]>
Date: Thu, 4 Jun 2015 09:32:11 -0400

Hello,

I put forward the charter text in the last message for IESG and IAB
review.  I would like to see this effort move quickly and will monitor
progress of it closely to make sure there is enough traction to continue
this as a WG once formed.  I'd like to see the requirements draft move
forward in advance of the projected date as I think that will be too tight
to move the other drafts forward and meet the dates specified.  I'd like to
see the requirements draft to the IESG (through WG last call) by the end of
November.

The chairs will need to manage this closely and ensure editors are
responsive and add editors or change them as needed to meet these deadlines.

Thank you,
Kathleen

-- 

Best regards,
Kathleen