< draft-ietf-dots-architecture-13.txt   draft-ietf-dots-architecture-14.txt >
DOTS A. Mortensen, Ed. DOTS A. Mortensen, Ed.
Internet-Draft Arbor Networks Internet-Draft Forcepoint
Intended status: Informational T. Reddy, Ed. Intended status: Informational T. Reddy, Ed.
Expires: October 5, 2019 McAfee, Inc. Expires: November 30, 2019 McAfee, Inc.
F. Andreasen F. Andreasen
Cisco Cisco
N. Teague N. Teague
Verisign Iron Mountain
R. Compton R. Compton
Charter Charter
April 03, 2019 May 29, 2019
Distributed-Denial-of-Service Open Threat Signaling (DOTS) Architecture Distributed-Denial-of-Service Open Threat Signaling (DOTS) Architecture
draft-ietf-dots-architecture-13 draft-ietf-dots-architecture-14
Abstract Abstract
This document describes an architecture for establishing and This document describes an architecture for establishing and
maintaining Distributed Denial of Service (DDoS) Open Threat maintaining Distributed Denial of Service (DDoS) Open Threat
Signaling (DOTS) within and between domains. The document does not Signaling (DOTS) within and between domains. The document does not
specify protocols or protocol extensions, instead focusing on specify protocols or protocol extensions, instead focusing on
defining architectural relationships, components and concepts used in defining architectural relationships, components and concepts used in
a DOTS deployment. a DOTS deployment.
skipping to change at page 1, line 42 skipping to change at page 1, line 42
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 October 5, 2019. This Internet-Draft will expire on November 30, 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 3, line 35 skipping to change at page 3, line 35
1.1.1. Key Words 1.1.1. Key Words
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in BCP14 [RFC2119] document are to be interpreted as described in BCP14 [RFC2119]
[RFC8174], when, and only when, they appear in all capitals. [RFC8174], when, and only when, they appear in all capitals.
1.1.2. Definition of Terms 1.1.2. Definition of Terms
This document uses the terms defined in [I-D.ietf-dots-requirements]. This document uses the terms defined in [RFC8612].
1.2. Scope 1.2. Scope
In this architecture, DOTS clients and servers communicate using DOTS In this architecture, DOTS clients and servers communicate using DOTS
signaling. As a result of signals from a DOTS client, the DOTS signaling. As a result of signals from a DOTS client, the DOTS
server may modify the forwarding path of traffic destined for the server may modify the forwarding path of traffic destined for the
attack target(s), for example by diverting traffic to a mitigator or attack target(s), for example by diverting traffic to a mitigator or
pool of mitigators, where policy may be applied to distinguish and pool of mitigators, where policy may be applied to distinguish and
discard attack traffic. Any such policy is deployment-specific. discard attack traffic. Any such policy is deployment-specific.
skipping to change at page 4, line 13 skipping to change at page 4, line 13
two or more participating networks, but single domain scenarios are two or more participating networks, but single domain scenarios are
valuable in their own right, as when aggregating intra-domain DOTS valuable in their own right, as when aggregating intra-domain DOTS
client signals for inter-domain coordinated attack response. client signals for inter-domain coordinated attack response.
This document does not address any administrative or business This document does not address any administrative or business
agreements that may be established between involved DOTS parties. agreements that may be established between involved DOTS parties.
Those considerations are out of scope. Regardless, this document Those considerations are out of scope. Regardless, this document
assumes necessary authentication and authorization mechanisms are put assumes necessary authentication and authorization mechanisms are put
in place so that only authorized clients can invoke the DOTS service. in place so that only authorized clients can invoke the DOTS service.
A detailed set of DOTS requirements are discussed in A detailed set of DOTS requirements are discussed in [RFC8612], and
[I-D.ietf-dots-requirements], and the DOTS architecture is designed the DOTS architecture is designed to follow those requirements. Only
to follow those requirements. Only new behavioral requirements are new behavioral requirements are described in this document.
described in this document.
1.3. Assumptions 1.3. Assumptions
This document makes the following assumptions: This document makes the following assumptions:
o All domains in which DOTS is deployed are assumed to offer the o All domains in which DOTS is deployed are assumed to offer the
required connectivity between DOTS agents and any intermediary required connectivity between DOTS agents and any intermediary
network elements, but the architecture imposes no additional network elements, but the architecture imposes no additional
limitations on the form of connectivity. limitations on the form of connectivity.
skipping to change at page 9, line 38 skipping to change at page 9, line 38
coordinating attack response originate. The requests may be in coordinating attack response originate. The requests may be in
response to an active, ongoing attack against a target in the DOTS response to an active, ongoing attack against a target in the DOTS
client's domain, but no active attack is required for a DOTS client client's domain, but no active attack is required for a DOTS client
to request help. Operators may wish to have upstream mitigators in to request help. Operators may wish to have upstream mitigators in
the network path for an indefinite period, and are restricted only by the network path for an indefinite period, and are restricted only by
business relationships when it comes to duration and scope of business relationships when it comes to duration and scope of
requested mitigation. requested mitigation.
The DOTS client requests attack response coordination from a DOTS The DOTS client requests attack response coordination from a DOTS
server over the signal channel, including in the request the DOTS server over the signal channel, including in the request the DOTS
client's desired mitigation scoping, as described in client's desired mitigation scoping, as described in [RFC8612] (SIG-
[I-D.ietf-dots-requirements] (SIG-008). The actual mitigation scope 008). The actual mitigation scope and countermeasures used in
and countermeasures used in response to the attack are up to the DOTS response to the attack are up to the DOTS server and mitigator
server and mitigator operators, as the DOTS client may have a narrow operators, as the DOTS client may have a narrow perspective on the
perspective on the ongoing attack. As such, the DOTS client's ongoing attack. As such, the DOTS client's request for mitigation
request for mitigation should be considered advisory: guarantees of should be considered advisory: guarantees of DOTS server availability
DOTS server availability or mitigation capacity constitute service or mitigation capacity constitute service level agreements and are
level agreements and are out of scope for this document. out of scope for this document.
The DOTS client adjusts mitigation scope and provides available The DOTS client adjusts mitigation scope and provides available
mitigation feedback (e.g., mitigation efficacy) at the direction of mitigation feedback (e.g., mitigation efficacy) at the direction of
its local administrator. Such direction may involve manual or its local administrator. Such direction may involve manual or
automated adjustments in response to updates from the DOTS server. automated adjustments in response to updates from the DOTS server.
To provide a metric of signal health and distinguish an idle signal To provide a metric of signal health and distinguish an idle signal
channel from a disconnected or defunct session, the DOTS client sends channel from a disconnected or defunct session, the DOTS client sends
a heartbeat over the signal channel to maintain its half of the a heartbeat over the signal channel to maintain its half of the
channel. The DOTS client similarly expects a heartbeat from the DOTS channel. The DOTS client similarly expects a heartbeat from the DOTS
skipping to change at page 16, line 49 skipping to change at page 16, line 49
the networks, domains, services or applications involved are assumed the networks, domains, services or applications involved are assumed
to have agreed upon the terms of the relationship involved. Such to have agreed upon the terms of the relationship involved. Such
agreements are out of scope for this document, but must be in place agreements are out of scope for this document, but must be in place
for a functional DOTS architecture. for a functional DOTS architecture.
It is assumed that as part of any DOTS service agreement, the DOTS It is assumed that as part of any DOTS service agreement, the DOTS
client is provided with all data and metadata required to establish client is provided with all data and metadata required to establish
communication with the DOTS server. Such data and metadata would communication with the DOTS server. Such data and metadata would
include any cryptographic information necessary to meet the message include any cryptographic information necessary to meet the message
confidentiality, integrity and authenticity requirement (SEC-002) in confidentiality, integrity and authenticity requirement (SEC-002) in
[I-D.ietf-dots-requirements], and might also include the pool of DOTS [RFC8612], and might also include the pool of DOTS server addresses
server addresses and ports the DOTS client should use for signal and and ports the DOTS client should use for signal and data channel
data channel messaging. messaging.
3.1.2. Establishing the DOTS Session 3.1.2. Establishing the DOTS Session
With the required business agreements in place, the DOTS client With the required business agreements in place, the DOTS client
initiates a DOTS session by contacting its DOTS server(s) over the initiates a DOTS session by contacting its DOTS server(s) over the
signal channel and (possibly) the data channel. To allow for DOTS signal channel and (possibly) the data channel. To allow for DOTS
service flexibility, neither the order of contact nor the time service flexibility, neither the order of contact nor the time
interval between channel creations is specified. A DOTS client MAY interval between channel creations is specified. A DOTS client MAY
establish signal channel first, and then data channel, or vice versa. establish signal channel first, and then data channel, or vice versa.
The methods by which a DOTS client receives the address and The methods by which a DOTS client receives the address and
associated service details of the DOTS server are not prescribed by associated service details of the DOTS server are not prescribed by
this document. For example, a DOTS client may be directly configured this document. For example, a DOTS client may be directly configured
to use a specific DOTS server IP address and port, and directly to use a specific DOTS server IP address and port, and directly
provided with any data necessary to satisfy the Peer Mutual provided with any data necessary to satisfy the Peer Mutual
Authentication requirement (SEC-001) in [I-D.ietf-dots-requirements], Authentication requirement (SEC-001) in [RFC8612], such as symmetric
such as symmetric or asymmetric keys, usernames and passwords, etc. or asymmetric keys, usernames and passwords, etc. All configuration
All configuration and authentication information in this scenario is and authentication information in this scenario is provided out-of-
provided out-of-band by the domain operating the DOTS server. band by the domain operating the DOTS server.
At the other extreme, the architecture in this document allows for a At the other extreme, the architecture in this document allows for a
form of DOTS client auto-provisioning. For example, the domain form of DOTS client auto-provisioning. For example, the domain
operating the DOTS server or servers might provide the client domain operating the DOTS server or servers might provide the client domain
only with symmetric or asymmetric keys to authenticate the only with symmetric or asymmetric keys to authenticate the
provisioned DOTS clients. Only the keys would then be directly provisioned DOTS clients. Only the keys would then be directly
configured on DOTS clients, but the remaining configuration required configured on DOTS clients, but the remaining configuration required
to provision the DOTS clients could be learned through mechanisms to provision the DOTS clients could be learned through mechanisms
similar to DNS SRV [RFC2782] or DNS Service Discovery [RFC6763]. similar to DNS SRV [RFC2782] or DNS Service Discovery [RFC6763].
The DOTS client SHOULD successfully authenticate and exchange The DOTS client SHOULD successfully authenticate and exchange
messages with the DOTS server over both signal and (if used) data messages with the DOTS server over both signal and (if used) data
channel as soon as possible to confirm that both channels are channel as soon as possible to confirm that both channels are
operational. operational.
As described in [I-D.ietf-dots-requirements] (DM-008), the DOTS As described in [RFC8612] (DM-008), the DOTS client can configure
client can configure preferred values for acceptable signal loss, preferred values for acceptable signal loss, mitigation lifetime, and
mitigation lifetime, and heartbeat intervals when establishing the heartbeat intervals when establishing the DOTS signal channel
DOTS signal channel session. A DOTS signal channel session is not session. A DOTS signal channel session is not active until DOTS
active until DOTS agents have agreed on the values for these DOTS agents have agreed on the values for these DOTS session parameters, a
session parameters, a process defined by the protocol. process defined by the protocol.
Once the DOTS client begins receiving DOTS server signals, the DOTS Once the DOTS client begins receiving DOTS server signals, the DOTS
session is active. At any time during the DOTS session, the DOTS session is active. At any time during the DOTS session, the DOTS
client may use the data channel to manage aliases, manage drop- and client may use the data channel to manage aliases, manage drop- and
accept-listed prefixes or addresses, leverage vendor-specific accept-listed prefixes or addresses, leverage vendor-specific
extensions, and so on. Note that unlike the signal channel, there is extensions, and so on. Note that unlike the signal channel, there is
no requirement that the data channel remains operational in attack no requirement that the data channel remains operational in attack
conditions (See Data Channel Requirements, Section 2.3 of conditions (See Data Channel Requirements, Section 2.3 of [RFC8612]).
[I-D.ietf-dots-requirements]).
3.1.3. Maintaining the DOTS Session 3.1.3. Maintaining the DOTS Session
DOTS clients and servers periodically send heartbeats to each other DOTS clients and servers periodically send heartbeats to each other
over the signal channel, discussed in [I-D.ietf-dots-requirements] over the signal channel, discussed in [RFC8612] (SIG-004). DOTS
(SIG-004). DOTS agent operators SHOULD configure the heartbeat agent operators SHOULD configure the heartbeat interval such that the
interval such that the frequency does not lead to accidental denials frequency does not lead to accidental denials of service due to the
of service due to the overwhelming number of heartbeats a DOTS agent overwhelming number of heartbeats a DOTS agent must field.
must field.
Either DOTS agent may consider a DOTS signal channel session Either DOTS agent may consider a DOTS signal channel session
terminated in the extended absence of a heartbeat from its peer terminated in the extended absence of a heartbeat from its peer
agent. The period of that absence will be established in the agent. The period of that absence will be established in the
protocol definition. protocol definition.
3.2. Modes of Signaling 3.2. Modes of Signaling
This section examines the modes of signaling between agents in a DOTS This section examines the modes of signaling between agents in a DOTS
architecture. architecture.
skipping to change at page 19, line 17 skipping to change at page 19, line 14
o Scheduled DOTS server maintenance; o Scheduled DOTS server maintenance;
o Scheduled modifications to the network path between DOTS server o Scheduled modifications to the network path between DOTS server
and DOTS client. and DOTS client.
A basic redirected DOTS signal channel session resembles the A basic redirected DOTS signal channel session resembles the
following, as shown in Figure 12. following, as shown in Figure 12.
+-------------+ +---------------+ +-------------+ +---------------+
| |<-(1)--- DOTS signal ------>| | | |<-(1)--- DOTS signal ------>| |
| | channel session 1 | | | | channel session 1 | |
| |<=(2)== redirect to B ======| | | |<=(2)== redirect to B ======| |
| DOTS client | | DOTS server A | | DOTS client | | DOTS server A |
| |X-(4)--- DOTS signal ------X| | | |X-(4)--- DOTS signal ------X| |
| | channel session 1 | | | | channel session 1 | |
| | | | | | | |
+-------------+ +---------------+ +-------------+ +---------------+
^ ^
| |
(3) DOTS signal channel (3) DOTS signal channel
| session 2 | session 2
skipping to change at page 21, line 51 skipping to change at page 21, line 51
Recursive signaling is opaque to the DOTS client. To maximize Recursive signaling is opaque to the DOTS client. To maximize
mitigation visibility to the DOTS client, however, the recursing mitigation visibility to the DOTS client, however, the recursing
domain SHOULD provide recursed mitigation feedback in signals domain SHOULD provide recursed mitigation feedback in signals
reporting on mitigation status to the DOTS client. For example, the reporting on mitigation status to the DOTS client. For example, the
recursing domain's mitigator should incorporate into mitigation recursing domain's mitigator should incorporate into mitigation
status messages available metrics such as dropped packet or byte status messages available metrics such as dropped packet or byte
counts from the recursed mitigation. counts from the recursed mitigation.
DOTS clients involved in recursive signaling must be able to withdraw DOTS clients involved in recursive signaling must be able to withdraw
requests for mitigation without warning or justification, per SIG-006 requests for mitigation without warning or justification, per SIG-006
in [I-D.ietf-dots-requirements]. in [RFC8612].
Operators recursing mitigation requests MAY maintain the recursed Operators recursing mitigation requests MAY maintain the recursed
mitigation for a brief, protocol-defined period in the event the DOTS mitigation for a brief, protocol-defined period in the event the DOTS
client originating the mitigation withdraws its request for help, as client originating the mitigation withdraws its request for help, as
per the discussion of managing mitigation toggling in SIG-006 of per the discussion of managing mitigation toggling in SIG-006 of
[I-D.ietf-dots-requirements]. [RFC8612].
Deployment of recursive signaling may result in traffic redirection, Deployment of recursive signaling may result in traffic redirection,
examination and mitigation extending beyond the initial bilateral examination and mitigation extending beyond the initial bilateral
relationship between DOTS client and DOTS server. As such, client relationship between DOTS client and DOTS server. As such, client
control over the network path of mitigated traffic may be reduced. control over the network path of mitigated traffic may be reduced.
DOTS client operators should be aware of any privacy concerns, and DOTS client operators should be aware of any privacy concerns, and
work with DOTS server operators employing recursive signaling to work with DOTS server operators employing recursive signaling to
ensure shared sensitive material is suitably protected. ensure shared sensitive material is suitably protected.
3.2.4. Anycast Signaling 3.2.4. Anycast Signaling
skipping to change at page 23, line 6 skipping to change at page 23, line 6
3.2.4.1. Anycast Signaling Considerations 3.2.4.1. Anycast Signaling Considerations
As long as network configuration remains stable, anycast DOTS As long as network configuration remains stable, anycast DOTS
signaling is to the individual DOTS client indistinct from direct signaling is to the individual DOTS client indistinct from direct
signaling. However, the operational challenges inherent in anycast signaling. However, the operational challenges inherent in anycast
signaling are anything but negligible, and DOTS server operators must signaling are anything but negligible, and DOTS server operators must
carefully weigh the risks against the benefits before deploying. carefully weigh the risks against the benefits before deploying.
While the DOTS signal channel primarily operates over UDP per SIG-001 While the DOTS signal channel primarily operates over UDP per SIG-001
in [I-D.ietf-dots-requirements], the signal channel also requires in [RFC8612], the signal channel also requires mutual authentication
mutual authentication between DOTS agents, with associated security between DOTS agents, with associated security state on both ends.
state on both ends.
Network instability is of particular concern with anycast signaling, Network instability is of particular concern with anycast signaling,
as DOTS signal channels are expected to be long-lived, and as DOTS signal channels are expected to be long-lived, and
potentially operating under congested network conditions caused by a potentially operating under congested network conditions caused by a
volumetric DDoS attack. volumetric DDoS attack.
For example, a network configuration altering the route to the DOTS For example, a network configuration altering the route to the DOTS
server during active anycast signaling may cause the DOTS client to server during active anycast signaling may cause the DOTS client to
send messages to a DOTS server other than the one with which it send messages to a DOTS server other than the one with which it
initially established a signaling session. That second DOTS server initially established a signaling session. That second DOTS server
skipping to change at page 26, line 20 skipping to change at page 26, line 20
and externally resolvable by the same name. For example, a detected and externally resolvable by the same name. For example, a detected
attack's internal target address can be mapped to a DNS name through attack's internal target address can be mapped to a DNS name through
a reverse lookup. The DNS name returned by the reverse lookup can a reverse lookup. The DNS name returned by the reverse lookup can
then be provided to the DOTS client as the external scope for then be provided to the DOTS client as the external scope for
mitigation. For the reverse DNS lookup, DNS Security Extensions mitigation. For the reverse DNS lookup, DNS Security Extensions
(DNSSEC) [RFC4033] must be used where the authenticity of response is (DNSSEC) [RFC4033] must be used where the authenticity of response is
critical. critical.
3.3. Triggering Requests for Mitigation 3.3. Triggering Requests for Mitigation
[I-D.ietf-dots-requirements] places no limitation on the [RFC8612] places no limitation on the circumstances in which a DOTS
circumstances in which a DOTS client operator may request mitigation, client operator may request mitigation, nor does it demand
nor does it demand justification for any mitigation request, thereby justification for any mitigation request, thereby reserving
reserving operational control over DDoS defense for the domain operational control over DDoS defense for the domain requesting
requesting mitigation. This architecture likewise does not prescribe mitigation. This architecture likewise does not prescribe the
the network conditions and mechanisms triggering a mitigation request network conditions and mechanisms triggering a mitigation request
from a DOTS client. from a DOTS client.
However, considering selected possible mitigation triggers from an However, considering selected possible mitigation triggers from an
architectural perspective offers a model for alternative or architectural perspective offers a model for alternative or
unanticipated triggers for DOTS deployments. In all cases, what unanticipated triggers for DOTS deployments. In all cases, what
network conditions merit a mitigation request are at the discretion network conditions merit a mitigation request are at the discretion
of the DOTS client operator. of the DOTS client operator.
The mitigation request itself is defined by DOTS, however the The mitigation request itself is defined by DOTS, however the
interfaces required to trigger the mitigation request in the interfaces required to trigger the mitigation request in the
skipping to change at page 28, line 42 skipping to change at page 28, line 42
3.3.3. Automated Mitigation on Loss of Signal 3.3.3. Automated Mitigation on Loss of Signal
To maintain a DOTS signal channel session, the DOTS client and the To maintain a DOTS signal channel session, the DOTS client and the
DOTS server exchange regular but infrequent messages across the DOTS server exchange regular but infrequent messages across the
signal channel. In the absence of an attack, the probability of signal channel. In the absence of an attack, the probability of
message loss in the signaling channel should be extremely low. Under message loss in the signaling channel should be extremely low. Under
attack conditions, however, some signal loss may be anticipated as attack conditions, however, some signal loss may be anticipated as
attack traffic congests the link, depending on the attack type. attack traffic congests the link, depending on the attack type.
While [I-D.ietf-dots-requirements] specifies the DOTS protocol be While [RFC8612] specifies the DOTS protocol be robust when signaling
robust when signaling under attack conditions, there are nevertheless under attack conditions, there are nevertheless scenarios in which
scenarios in which the DOTS signal is lost in spite of protocol best the DOTS signal is lost in spite of protocol best efforts. To handle
efforts. To handle such scenarios, a DOTS operator may request one such scenarios, a DOTS operator may request one or more mitigations
or more mitigations which are triggered only when the DOTS server which are triggered only when the DOTS server ceases receiving DOTS
ceases receiving DOTS client heartbeats beyond the miss count or client heartbeats beyond the miss count or interval permitted by the
interval permitted by the protocol. protocol.
The impact of mitigating due to loss of signal in either direction The impact of mitigating due to loss of signal in either direction
must be considered carefully before enabling it. Signal loss is not must be considered carefully before enabling it. Signal loss is not
caused by links congested with attack traffic alone, and as such caused by links congested with attack traffic alone, and as such
mitigation requests triggered by signal channel degradation in either mitigation requests triggered by signal channel degradation in either
direction may incur unnecessary costs, in network performance and direction may incur unnecessary costs, in network performance and
operational expense alike. operational expense alike.
4. IANA Considerations 4. IANA Considerations
skipping to change at page 30, line 12 skipping to change at page 30, line 12
given adequate protections, again in accordance with best current given adequate protections, again in accordance with best current
practices for network and host security. practices for network and host security.
6. Contributors 6. Contributors
Mohamed Boucadair Mohamed Boucadair
Orange Orange
mohamed.boucadair@orange.com mohamed.boucadair@orange.com
Christopher Gray Christopher Gray Christopher_Gray3@cable.comcast.com
Christopher_Gray3@cable.comcast.com
7. Acknowledgments 7. Acknowledgments
Thanks to Matt Richardson, Roman Danyliw, Frank Xialiang, Roland Thanks to Matt Richardson, Roman Danyliw, Frank Xialiang, Roland
Dobbins, Wei Pan, Kaname Nishizuka, Jon Shallow and Mohamed Boucadair Dobbins, Wei Pan, Kaname Nishizuka, Jon Shallow, and Mohamed
for their comments and suggestions. Boucadair for their comments and suggestions.
8. References 8. References
8.1. Normative References 8.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
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>. May 2017, <https://www.rfc-editor.org/info/rfc8174>.
8.2. Informative References 8.2. Informative References
[I-D.ietf-dots-requirements]
Mortensen, A., K, R., and R. Moskowitz, "Distributed
Denial of Service (DDoS) Open Threat Signaling
Requirements", draft-ietf-dots-requirements-22 (work in
progress), March 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
1.3", draft-ietf-tls-dtls13-31 (work in progress), March 1.3", draft-ietf-tls-dtls13-31 (work in progress), March
skipping to change at page 33, line 24 skipping to change at page 33, line 15
[RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol
Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
<https://www.rfc-editor.org/info/rfc8446>. <https://www.rfc-editor.org/info/rfc8446>.
[RFC8512] Boucadair, M., Ed., Sivakumar, S., Jacquenet, C., [RFC8512] Boucadair, M., Ed., Sivakumar, S., Jacquenet, C.,
Vinapamula, S., and Q. Wu, "A YANG Module for Network Vinapamula, S., and Q. Wu, "A YANG Module for Network
Address Translation (NAT) and Network Prefix Translation Address Translation (NAT) and Network Prefix Translation
(NPT)", RFC 8512, DOI 10.17487/RFC8512, January 2019, (NPT)", RFC 8512, DOI 10.17487/RFC8512, January 2019,
<https://www.rfc-editor.org/info/rfc8512>. <https://www.rfc-editor.org/info/rfc8512>.
[RFC8612] Mortensen, A., Reddy, T., and R. Moskowitz, "DDoS Open
Threat Signaling (DOTS) Requirements", RFC 8612,
DOI 10.17487/RFC8612, May 2019,
<https://www.rfc-editor.org/info/rfc8612>.
Authors' Addresses Authors' Addresses
Andrew Mortensen (editor) Andrew Mortensen (editor)
Arbor Networks Forcepoint
2727 S. State St
Ann Arbor, MI 48104
United States United States
EMail: andrewmortensen@gmail.com EMail: andrewmortensen@gmail.com
Tirumaleswar Reddy (editor) Tirumaleswar Reddy (editor)
McAfee, Inc. McAfee, Inc.
Embassy Golf Link Business Park Embassy Golf Link Business Park
Bangalore, Karnataka 560071 Bangalore, Karnataka 560071
India India
skipping to change at page 34, line 4 skipping to change at page 33, line 41
Bangalore, Karnataka 560071 Bangalore, Karnataka 560071
India India
EMail: kondtir@gmail.com EMail: kondtir@gmail.com
Flemming Andreasen Flemming Andreasen
Cisco Cisco
United States United States
EMail: fandreas@cisco.com EMail: fandreas@cisco.com
Nik Teague Nik Teague
Verisign Iron Mountain
United States United States
EMail: nteague@verisign.com EMail: nteague@ironmountain.co.uk
Rich Compton Rich Compton
Charter Charter
EMail: Rich.Compton@charter.com EMail: Rich.Compton@charter.com
 End of changes. 28 change blocks. 
75 lines changed or deleted 66 lines changed or added

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