< draft-ietf-dots-signal-channel-28.txt   draft-ietf-dots-signal-channel-29.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: August 2, 2019 Orange Expires: August 26, 2019 Orange
P. Patil P. Patil
Cisco Cisco
A. Mortensen A. Mortensen
Arbor Networks, Inc. Arbor Networks, Inc.
N. Teague N. Teague
Verisign, Inc. Verisign, Inc.
January 29, 2019 February 22, 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-28 draft-ietf-dots-signal-channel-29
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 1, line 48 skipping to change at page 1, line 48
(DOTS) Signal Channel Specification"; (DOTS) Signal Channel Specification";
o "| [RFCXXXX] |" o "| [RFCXXXX] |"
o reference: RFC XXXX o reference: RFC XXXX
Please update this statement with the RFC number to be assigned to Please update this statement with the RFC number to be assigned to
the following documents: the following documents:
o "RFC YYYY: Distributed Denial-of-Service Open Threat Signaling o "RFC YYYY: Distributed Denial-of-Service Open Threat Signaling
(DOTS) Data Channel Specification (used to be (DOTS) Data Channel Specification (used to be I-D.ietf-dots-data-
[I-D.ietf-dots-data-channel]) channel)
Please update TBD/TBD1/TBD2 statements with the assignments made by Please update TBD/TBD1/TBD2 statements with the assignments made by
IANA to DOTS Signal Channel Protocol. IANA to DOTS Signal Channel Protocol.
Also, please update the "revision" date of the YANG modules. Also, please update the "revision" date of the YANG modules.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
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 August 2, 2019. This Internet-Draft will expire on August 26, 2019.
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 39, line 27 skipping to change at page 39, line 27
a mitigation is active ('mitigating-config') and when no mitigation a mitigation is active ('mitigating-config') and when no mitigation
is active ('idle-config'). This is particularly useful for DOTS is active ('idle-config'). This is particularly useful for DOTS
servers that might want to reduce heartbeat frequency or cease servers that might want to reduce heartbeat frequency or cease
heartbeat exchanges when an active DOTS client has not requested heartbeat exchanges when an active DOTS client has not requested
mitigation. If distinct configurations are used, DOTS agents MUST mitigation. If distinct configurations are used, DOTS agents MUST
follow the appropriate configuration set as a function of the follow the appropriate configuration set as a function of the
mitigation activity (e.g., if no mitigation request is active, 'idle- mitigation activity (e.g., if no mitigation request is active, 'idle-
config'-related values must be followed). Additionally, DOTS agents config'-related values must be followed). Additionally, DOTS agents
MUST automatically switch to the other configuration upon a change in MUST automatically switch to the other configuration upon a change in
the mitigation activity (e.g., if an attack mitigation is launched the mitigation activity (e.g., if an attack mitigation is launched
after a peacetime, the DOTS agent switches from 'idle-config' to after an 'idle' time, the DOTS agent switches from 'idle-config' to
'mitigating-config'-related values). 'mitigating-config'-related values).
CoAP Requests and responses are indicated for reliable delivery by CoAP Requests and responses are indicated for reliable delivery by
marking them as Confirmable messages. DOTS signal channel session marking them as Confirmable messages. DOTS signal channel session
configuration requests and responses are marked as Confirmable configuration requests and responses are marked as Confirmable
messages. As explained in Section 2.1 of [RFC7252], a Confirmable messages. As explained in Section 2.1 of [RFC7252], a Confirmable
message is retransmitted using a default timeout and exponential message is retransmitted using a default timeout and exponential
back-off between retransmissions, until the DOTS server sends an back-off between retransmissions, until the DOTS server sends an
Acknowledgement message (ACK) with the same Message ID conveyed from Acknowledgement message (ACK) with the same Message ID conveyed from
the DOTS client. the DOTS client.
skipping to change at page 39, line 49 skipping to change at page 39, line 49
Message transmission parameters are defined in Section 4.8 of Message transmission parameters are defined in Section 4.8 of
[RFC7252]. The DOTS server can either piggyback the response in the [RFC7252]. The DOTS server can either piggyback the response in the
acknowledgement message or, if the DOTS server cannot respond acknowledgement message or, if the DOTS server cannot respond
immediately to a request carried in a Confirmable message, it simply immediately to a request carried in a Confirmable message, it simply
responds with an Empty Acknowledgement message so that the DOTS responds with an Empty Acknowledgement message so that the DOTS
client can stop retransmitting the request. Empty Acknowledgement client can stop retransmitting the request. Empty Acknowledgement
messages are explained in Section 2.2 of [RFC7252]. When the messages are explained in Section 2.2 of [RFC7252]. When the
response is ready, the server sends it in a new Confirmable message response is ready, the server sends it in a new Confirmable message
which in turn needs to be acknowledged by the DOTS client (see which in turn needs to be acknowledged by the DOTS client (see
Sections 5.2.1 and 5.2.2 of [RFC7252]). Requests and responses Sections 5.2.1 and 5.2.2 of [RFC7252]). Requests and responses
exchanged between DOTS agents during peacetime are marked as exchanged between DOTS agents during 'idle' time are marked as
Confirmable messages. Confirmable messages.
Implementation Note: A DOTS client that receives a response in a Implementation Note: A DOTS client that receives a response in a
Confirmable message may want to clean up the message state right Confirmable message may want to clean up the message state right
after sending the ACK. If that ACK is lost and the DOTS server after sending the ACK. If that ACK is lost and the DOTS server
retransmits the Confirmable message, the DOTS client may no longer retransmits the Confirmable message, the DOTS client may no longer
have any state that would help it correlate this response: from have any state that would help it correlate this response: from
the DOTS client's standpoint, the retransmission message is the DOTS client's standpoint, the retransmission message is
unexpected. The DOTS client will send a Reset message so it does unexpected. The DOTS client will send a Reset message so it does
not receive any more retransmissions. This behavior is normal and not receive any more retransmissions. This behavior is normal and
skipping to change at page 75, line 6 skipping to change at page 75, line 6
server immediately responds with a DOTS mitigation response. This server immediately responds with a DOTS mitigation response. This
assumes no packet loss is experienced. assumes no packet loss is experienced.
o 0-RTT mode in which the DOTS client can authenticate itself and o 0-RTT mode in which the DOTS client can authenticate itself and
send DOTS mitigation request messages in the first message, thus send DOTS mitigation request messages in the first message, thus
reducing handshake latency. 0-RTT only works if the DOTS client reducing handshake latency. 0-RTT only works if the DOTS client
has previously communicated with that DOTS server, which is very has previously communicated with that DOTS server, which is very
likely with the DOTS signal channel. likely with the DOTS signal channel.
The DOTS client has to establish a (D)TLS session with the DOTS The DOTS client has to establish a (D)TLS session with the DOTS
server during peacetime and share a PSK. server during 'idle' time and share a PSK.
During a DDoS attack, the DOTS client can use the (D)TLS session During a DDoS attack, the DOTS client can use the (D)TLS session
to convey the DOTS mitigation request message and, if there is no to convey the DOTS mitigation request message and, if there is no
response from the server after multiple retries, the DOTS client response from the server after multiple retries, the DOTS client
can resume the (D)TLS session in 0-RTT mode using PSK. can resume the (D)TLS session in 0-RTT mode using PSK.
Section 8 of [RFC8446] discusses some mechanisms to implement to Section 8 of [RFC8446] discusses some mechanisms to implement to
limit the impact of replay attacks on 0-RTT data. If the DOTS limit the impact of replay attacks on 0-RTT data. If the DOTS
server accepts 0-RTT, it MUST implement one of these mechanisms. server accepts 0-RTT, it MUST implement one of these mechanisms.
A DOTS server can reject 0-RTT by sending a TLS HelloRetryRequest. A DOTS server can reject 0-RTT by sending a TLS HelloRetryRequest.
skipping to change at page 75, line 28 skipping to change at page 75, line 28
client are idempotent requests. As a reminder, Message ID client are idempotent requests. As a reminder, Message ID
(Section 3 of [RFC7252]) is changed each time a new CoAP request (Section 3 of [RFC7252]) is changed each time a new CoAP request
is sent, and the Token (Section 5.3.1 of [RFC7252]) is randomized is sent, and the Token (Section 5.3.1 of [RFC7252]) is randomized
in each CoAP request. The DOTS server(s) can use Message ID and in each CoAP request. The DOTS server(s) can use Message ID and
Token in the DOTS signal channel message to detect replay of early Token in the DOTS signal channel message to detect replay of early
data, and accept 0-RTT data at most once. Furthermore, 'mid' data, and accept 0-RTT data at most once. Furthermore, 'mid'
value is monotonically increased by the DOTS client for each value is monotonically increased by the DOTS client for each
mitigation request, attackers replaying mitigation requests with mitigation request, attackers replaying mitigation requests with
lower numeric 'mid' values and overlapping scopes with mitigation lower numeric 'mid' values and overlapping scopes with mitigation
requests having higher numeric 'mid' values will be rejected requests having higher numeric 'mid' values will be rejected
systematically by the DOTS server. systematically by the DOTS server. Likewise, 'sid' value is
monotonically increased by the DOTS client for each configuration
session, attackers replaying configuration requests with lower
numeric 'sid' values will be rejected by the DOTS server if it
maintains a higher numeric 'sid' value for this DOTS client.
Owing to the aforementioned protections, especially those afforded Owing to the aforementioned protections, especially those afforded
by CoAP deduplication (Section 4.5 of [RFC7252]) and RFC 8446 by CoAP deduplication (Section 4.5 of [RFC7252]) and RFC 8446
anti-replay mechanisms, all DOTS signal channel requests are safe anti-replay mechanisms, all DOTS signal channel requests are safe
to transmit in TLS 1.3 as early data. Refer to to transmit in TLS 1.3 as early data. Refer to
[I-D.boucadair-dots-earlydata] for more details. [I-D.boucadair-dots-earlydata] for more details.
A simplified TLS 1.3 handshake with 0-RTT DOTS mitigation request A simplified TLS 1.3 handshake with 0-RTT DOTS mitigation request
message exchange is shown in Figure 26. message exchange is shown in Figure 26.
skipping to change at page 91, line 34 skipping to change at page 91, line 34
o Dan Wing, Email: dwing-ietf@fuggles.com o Dan Wing, Email: dwing-ietf@fuggles.com
12. Acknowledgements 12. Acknowledgements
Thanks to Christian Jacquenet, Roland Dobbins, Roman D. Danyliw, Thanks to Christian Jacquenet, Roland Dobbins, Roman D. Danyliw,
Michael Richardson, Ehud Doron, Kaname Nishizuka, Dave Dolson, Liang Michael Richardson, Ehud Doron, Kaname Nishizuka, Dave Dolson, Liang
Xia, Gilbert Clark, Xialiang Frank, Jim Schaad, Klaus Hartke and Xia, Gilbert Clark, Xialiang Frank, Jim Schaad, Klaus Hartke and
Nesredien Suleiman for the discussion and comments. Nesredien Suleiman for the discussion and comments.
The authors would like to give special thanks to Kaname Nishizuka and
Jon Shallow for their efforts in implementing the protocol and
performing interop testing at IETF Hackathons.
Thanks to the core WG for the recommendations on Hop-Limit and Thanks to the core WG for the recommendations on Hop-Limit and
redirect signaling. redirect signaling.
Special thanks to Benjamin Kaduk for the detailed AD review. Special thanks to Benjamin Kaduk for the detailed AD review.
13. References 13. References
13.1. Normative References 13.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
skipping to change at page 95, line 15 skipping to change at page 95, line 20
[I-D.ietf-core-yang-cbor] [I-D.ietf-core-yang-cbor]
Veillette, M., Pelov, A., Somaraju, A., Turner, R., and A. Veillette, M., Pelov, A., Somaraju, A., Turner, R., and A.
Minaburo, "CBOR Encoding of Data Modeled with YANG", Minaburo, "CBOR Encoding of Data Modeled with YANG",
draft-ietf-core-yang-cbor-07 (work in progress), September draft-ietf-core-yang-cbor-07 (work in progress), September
2018. 2018.
[I-D.ietf-dots-architecture] [I-D.ietf-dots-architecture]
Mortensen, A., Andreasen, F., K, R., Teague, N., Compton, Mortensen, A., Andreasen, F., K, R., Teague, N., Compton,
R., and c. christopher_gray3@cable.comcast.com, R., and c. christopher_gray3@cable.comcast.com,
"Distributed-Denial-of-Service Open Threat Signaling "Distributed-Denial-of-Service Open Threat Signaling
(DOTS) Architecture", draft-ietf-dots-architecture-10 (DOTS) Architecture", draft-ietf-dots-architecture-11
(work in progress), December 2018. (work in progress), February 2019.
[I-D.ietf-dots-data-channel] [I-D.ietf-dots-data-channel]
Boucadair, M., K, R., Nishizuka, K., Xia, L., Patil, P., Boucadair, M., K, R., Nishizuka, K., Xia, L., Patil, P.,
Mortensen, A., and N. Teague, "Distributed Denial-of- Mortensen, A., and N. Teague, "Distributed Denial-of-
Service Open Threat Signaling (DOTS) Data Channel Service Open Threat Signaling (DOTS) Data Channel
Specification", draft-ietf-dots-data-channel-25 (work in Specification", draft-ietf-dots-data-channel-25 (work in
progress), January 2019. progress), January 2019.
[I-D.ietf-dots-requirements] [I-D.ietf-dots-requirements]
Mortensen, A., Moskowitz, R., and R. K, "Distributed Mortensen, A., K, R., and R. Moskowitz, "Distributed
Denial of Service (DDoS) Open Threat Signaling Denial of Service (DDoS) Open Threat Signaling
Requirements", draft-ietf-dots-requirements-16 (work in Requirements", draft-ietf-dots-requirements-18 (work in
progress), October 2018. progress), February 2019.
[I-D.ietf-dots-use-cases] [I-D.ietf-dots-use-cases]
Dobbins, R., Migault, D., Fouant, S., Moskowitz, R., Dobbins, R., Migault, D., Fouant, S., Moskowitz, R.,
Teague, N., Xia, L., and K. Nishizuka, "Use cases for DDoS Teague, N., Xia, L., and K. Nishizuka, "Use cases for DDoS
Open Threat Signaling", draft-ietf-dots-use-cases-17 (work Open Threat Signaling", draft-ietf-dots-use-cases-17 (work
in progress), January 2019. in progress), January 2019.
[I-D.ietf-tls-dtls13] [I-D.ietf-tls-dtls13]
Rescorla, E., Tschofenig, H., and N. Modadugu, "The Rescorla, E., Tschofenig, H., and N. Modadugu, "The
Datagram Transport Layer Security (DTLS) Protocol Version Datagram Transport Layer Security (DTLS) Protocol Version
 End of changes. 13 change blocks. 
15 lines changed or deleted 23 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/