Skip to main content

Concluded WG DDoS Open Threat Signaling (dots)

Note: The data for concluded WGs is occasionally incorrect.

WG Name DDoS Open Threat Signaling
Acronym dots
Area Security Area (sec)
State Concluded
Charter charter-ietf-dots-01 Approved
Document dependencies
Additional resources Issue tracker, Wiki, Zulip stream
Personnel Chairs Liang Xia, Valery Smyslov
Area Director Paul Wouters
Mailing list Address dots@ietf.org
To subscribe https://www.ietf.org/mailman/listinfo/dots
Archive https://mailarchive.ietf.org/arch/browse/dots/

Closing note for Working Group

The working group has completed its chartered work items and there was consensus on the list to close the WG.

Final Charter for Working Group

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.

Done milestones

Date Milestone Associated documents
Done DOTS Telemetry Use Cases document to WGLC rfc9387 (was draft-ietf-dots-telemetry-use-cases)
Done DOTS Multihoming draft to WGLC rfc9284 (was draft-ietf-dots-multihoming)
Done 8782-bis draft to WGLC
Done DOTS Telemetry draft to WGLC draft-doron-dots-telemetry
Done DOTS Signal Channel Call Home document to WGLC rfc9066 (was draft-ietf-dots-signal-call-home)
Done DOTS Server Discovery document to WGLC rfc8973 (was draft-ietf-dots-server-discovery)
Done Architecture document to WGLC
Done Data channel document as proposed standard to WGLC
Done Signal channel document as proposed standard to WGLC
Done Use case document to WGLC
Done Requirements document to WGLC