RFC 9362: Distributed Denial-of-Service Open Threat Signaling (DOTS) Signal Channel Configuration Attributes for Robust Block Transmission
In plain English — editorial summary, not part of the RFC
This document specifies new DDoS Open Threat Signaling (DOTS) signal channel configuration parameters that can be negotiated between DOTS peers to enable the use of Q-Block1 and Q-Block2 Constrained Application Protocol (CoAP) options. These options enable robust and faster transmission rates for large amounts of data with less packet interchanges as well as support for faster recovery should any of the blocks get lost in transmission (especially during DDoS attacks). Also, this document defines a YANG data model for representing these new DOTS signal channel configuration parameters. This model augments the DOTS signal YANG module ("ietf-dots-signal-channel") defined in RFC 9132.
Document record
- Document ID
- RFC9362
- Published
- February 2023
- Authors
- M. Boucadair; J. Shallow
- Status
- PROPOSED STANDARD
- Stream
- IETF
- Area
- sec
- Pages
- 21
- Also known as
- —
Topics
Related documents
Ranked automatically by shared keywords, IETF area and stream — not by editorial selection.
- RFC 9177Constrained Application Protocol (CoAP) Block-Wise Transfer Options Supporting Robust TransmissionCurrent
March 2022
- RFC 9132Distributed Denial-of-Service Open Threat Signaling (DOTS) Signal Channel SpecificationCurrent
September 2021
- RFC 8783Distributed Denial-of-Service Open Threat Signaling (DOTS) Data Channel SpecificationCurrent
May 2020
- RFC 8782Distributed Denial-of-Service Open Threat Signaling (DOTS) Signal Channel SpecificationObsoleted
May 2020
- RFC 8768Constrained Application Protocol (CoAP) Hop-Limit OptionCurrent
March 2020
- RFC 9244Distributed Denial-of-Service Open Threat Signaling (DOTS) TelemetryCurrent
June 2022
- RFC 9133Controlling Filtering Rules Using Distributed Denial-of-Service Open Threat Signaling (DOTS) Signal ChannelCurrent
September 2021
- RFC 9145Integrity Protection for the Network Service Header (NSH) and Encryption of Sensitive Context HeadersCurrent
December 2021
Also filed under
About this page
The document record above — title, authors, date, status, stream, area, relationships, DOI and errata — is imported verbatim from the public RFC Editor index. The “in plain English” section is editorial: written by The metasystema editorial team, not part of the RFC. Where the two differ, the RFC text governs.
Last checked against the RFC Editor index on . RFCs are never revised after publication; changes are issued as new documents.
Data sources · Editorial policy · Report a correction · What is an RFC?