DDoS Open Threat Signaling

The information below is for an older proposed charter
Document Proposed charter DDoS Open Threat Signaling WG (dots) Snapshot
Title DDoS Open Threat Signaling
Last updated 2015-06-25
State IESG Review (Charter for Approval, Selected by Secretariat) Rechartering
WG State Proposed
IESG Responsible AD Benjamin Kaduk
Charter Edit AD Kathleen Moriarty
Send notices to (None)


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

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 

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.