< draft-ietf-dots-signal-channel-36.txt   draft-ietf-dots-signal-channel-37.txt >
DOTS T. Reddy, Ed. DOTS T. Reddy, Ed.
Internet-Draft McAfee Internet-Draft McAfee
Intended status: Standards Track M. Boucadair, Ed. Intended status: Standards Track M. Boucadair, Ed.
Expires: January 24, 2020 Orange Expires: January 29, 2020 Orange
P. Patil P. Patil
Cisco Cisco
A. Mortensen A. Mortensen
Arbor Networks, Inc. Arbor Networks, Inc.
N. Teague N. Teague
Iron Mountain Data Centers Iron Mountain Data Centers
July 23, 2019 July 28, 2019
Distributed Denial-of-Service Open Threat Signaling (DOTS) Signal Distributed Denial-of-Service Open Threat Signaling (DOTS) Signal
Channel Specification Channel Specification
draft-ietf-dots-signal-channel-36 draft-ietf-dots-signal-channel-37
Abstract Abstract
This document specifies the DOTS signal channel, a protocol for This document specifies the DOTS signal channel, a protocol for
signaling the need for protection against Distributed Denial-of- signaling the need for protection against Distributed Denial-of-
Service (DDoS) attacks to a server capable of enabling network Service (DDoS) attacks to a server capable of enabling network
traffic mitigation on behalf of the requesting client. traffic mitigation on behalf of the requesting client.
A companion document defines the DOTS data channel, a separate A companion document defines the DOTS data channel, a separate
reliable communication layer for DOTS management and configuration reliable communication layer for DOTS management and configuration
skipping to change at page 2, line 25 skipping to change at page 2, line 25
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on January 24, 2020. This Internet-Draft will expire on January 29, 2020.
Copyright Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2019 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 58, line 26 skipping to change at page 58, line 26
client can send mitigation requests over the current DOTS signal client can send mitigation requests over the current DOTS signal
channel session. In this case, the DOTS server can identify the DOTS channel session. In this case, the DOTS server can identify the DOTS
client is under attack and the inbound link to the DOTS client client is under attack and the inbound link to the DOTS client
(domain) is saturated. Furthermore, if the DOTS server does not (domain) is saturated. Furthermore, if the DOTS server does not
receive a mitigation request from the DOTS client, it implies the receive a mitigation request from the DOTS client, it implies the
DOTS client has not detected the attack or, if an attack mitigation DOTS client has not detected the attack or, if an attack mitigation
is in progress, it implies the applied DDoS mitigation actions are is in progress, it implies the applied DDoS mitigation actions are
not yet effective to handle the DDoS attack volume. not yet effective to handle the DDoS attack volume.
If the DOTS server does not receive any traffic from the peer DOTS If the DOTS server does not receive any traffic from the peer DOTS
client, then the DOTS server sends heartbeat requests to the DOTS client during the time span required to exhaust the maximum 'missing-
client and after maximum 'missing-hb-allowed' threshold is reached, hb-allowed' threshold, the DOTS server concludes the session is
the DOTS server concludes the session is disconnected. The DOTS disconnected. The DOTS server can then trigger pre-configured
server can then trigger pre-configured mitigation requests for this mitigation requests for this DOTS client (if any).
DOTS client (if any).
In DOTS over UDP, heartbeat messages MUST be exchanged between the In DOTS over UDP, heartbeat messages MUST be exchanged between the
DOTS agents using the "CoAP Ping" mechanism defined in Section 4.2 of DOTS agents using the "CoAP Ping" mechanism defined in Section 4.2 of
[RFC7252]. [RFC7252].
In DOTS over TCP, heartbeat messages MUST be exchanged between the In DOTS over TCP, heartbeat messages MUST be exchanged between the
DOTS agents using the Ping and Pong messages specified in Section 5.4 DOTS agents using the Ping and Pong messages specified in Section 5.4
of [RFC8323]. That is, the DOTS agent sends a Ping message and the of [RFC8323]. That is, the DOTS agent sends a Ping message and the
peer DOTS agent would respond by sending a single Pong message. The peer DOTS agent would respond by sending a single Pong message. The
sender of a Ping message has to allow up to 'heartbeat-interval' sender of a Ping message has to allow up to 'heartbeat-interval'
skipping to change at page 93, line 42 skipping to change at page 93, line 42
XML: N/A; the requested URI is an XML namespace. XML: N/A; the requested URI is an XML namespace.
URI: urn:ietf:params:xml:ns:yang:iana-dots-signal-channel URI: urn:ietf:params:xml:ns:yang:iana-dots-signal-channel
Registrant Contact: IANA. Registrant Contact: IANA.
XML: N/A; the requested URI is an XML namespace. XML: N/A; the requested URI is an XML namespace.
This document requests IANA to register the following YANG modules in This document requests IANA to register the following YANG modules in
the "YANG Module Names" subregistry [RFC7950] within the "YANG the "YANG Module Names" subregistry [RFC7950] within the "YANG
Parameters" registry. Parameters" registry.
Name: ietf-signal Name: ietf-dots-signal-channel
Namespace: urn:ietf:params:xml:ns:yang:ietf-dots-signal-channel Namespace: urn:ietf:params:xml:ns:yang:ietf-dots-signal-channel
Maintained by IANA: N Maintained by IANA: N
Prefix: signal Prefix: signal
Reference: RFC XXXX Reference: RFC XXXX
Name: iana-signal Name: iana-dots-signal-channel
Namespace: urn:ietf:params:xml:ns:yang:iana-dots-signal-channel Namespace: urn:ietf:params:xml:ns:yang:iana-dots-signal-channel
Maintained by IANA: Y Maintained by IANA: Y
Prefix: iana-signal Prefix: iana-signal
Reference: RFC XXXX Reference: RFC XXXX
This document defines the initial version of the IANA-maintained This document defines the initial version of the IANA-maintained
iana-dots-signal-channel YANG module. IANA is requested to add this iana-dots-signal-channel YANG module. IANA is requested to add this
note: note:
Status, conflict status, conflict cause, and attack status values Status, conflict status, conflict cause, and attack status values
 End of changes. 7 change blocks. 
11 lines changed or deleted 10 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/