WG Action: Formed DDoS Open Threat Signaling (dots)

[The IESG <[e-mail]>]

A new IETF working group has been formed in the Security Area. For
additional information please contact the Area Directors or the WG Chair.

DDoS Open Threat Signaling (dots)
------------------------------------------------
Current Status: Proposed WG

Chairs:
  Roman Danyliw <[e-mail]>

Assigned Area Director:
  Kathleen Moriarty <[e-mail]>

Mailing list
  Address: [e-mail]
  To Subscribe: https://www.ietf.org/mailman/listinfo/dots
  Archive: https://mailarchive.ietf.org/arch/browse/dots/

Charter:

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 potentially
hostile conditions for any type of upstream signaling, in particular 
transport protocols that yield to congestion, 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).  Any modification of or extension 
to existing protocols must be in close coordination with the working 
groups responsible for the protocol being modified, and may be done in 
this working group after agreement with all the relevant WGs and 
responsible Area Directors.  The WG may coordinate on a situationally
appropriate basis with other working groups and initiatives which
compliment the DOTS effort e.g. M3AAWG, SACM, MILE, SUPA, I2NSF et. al.

The WG will document requirements for the transport protocol to be used 
for the signaling of DOTS and consult with the Transport Area about the 
requirements and, if applicable, any new development of an encapsulation 
scheme for DOTS.  The working group may develop an applicability 
statement (architecture document) explaining how all these elements 
should communicate together for a complete DDoS service.

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 principles 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, with privacy-friendly choices 
being the default in all cases.

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 protocols and associated data models 
to address the stated goals of the WG.

Milestones:
  Feb 2016 - Requirements/use case information document to IESG
  May 2016 - Transport document as proposed standard to IESG
  Jun 2016 - Data model document as proposed standard to IESG