draft-ietf-dots-requirements-11.txt   draft-ietf-dots-requirements-12.txt 
DOTS A. Mortensen DOTS A. Mortensen
Internet-Draft Arbor Networks Internet-Draft Arbor Networks
Intended status: Informational R. Moskowitz Intended status: Informational R. Moskowitz
Expires: July 27, 2018 Huawei Expires: July 29, 2018 Huawei
T. Reddy T. Reddy
McAfee, Inc. McAfee, Inc.
January 23, 2018 January 25, 2018
Distributed Denial of Service (DDoS) Open Threat Signaling Requirements Distributed Denial of Service (DDoS) Open Threat Signaling Requirements
draft-ietf-dots-requirements-11 draft-ietf-dots-requirements-12
Abstract Abstract
This document defines the requirements for the Distributed Denial of This document defines the requirements for the Distributed Denial of
Service (DDoS) Open Threat Signaling (DOTS) protocols enabling Service (DDoS) Open Threat Signaling (DOTS) protocols enabling
coordinated response to DDoS attacks. coordinated response to DDoS attacks.
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
skipping to change at page 1, line 35 skipping to change at page 1, line 35
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 July 27, 2018. This Internet-Draft will expire on July 29, 2018.
Copyright Notice Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the Copyright (c) 2018 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 2, line 22 skipping to change at page 2, line 22
2. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 5 2. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 5
2.1. General Requirements . . . . . . . . . . . . . . . . . . 6 2.1. General Requirements . . . . . . . . . . . . . . . . . . 6
2.2. Signal Channel Requirements . . . . . . . . . . . . . . . 7 2.2. Signal Channel Requirements . . . . . . . . . . . . . . . 7
2.3. Data Channel Requirements . . . . . . . . . . . . . . . . 12 2.3. Data Channel Requirements . . . . . . . . . . . . . . . . 12
2.4. Security Requirements . . . . . . . . . . . . . . . . . . 13 2.4. Security Requirements . . . . . . . . . . . . . . . . . . 13
2.5. Data Model Requirements . . . . . . . . . . . . . . . . . 14 2.5. Data Model Requirements . . . . . . . . . . . . . . . . . 14
3. Congestion Control Considerations . . . . . . . . . . . . . . 15 3. Congestion Control Considerations . . . . . . . . . . . . . . 15
3.1. Signal Channel . . . . . . . . . . . . . . . . . . . . . 15 3.1. Signal Channel . . . . . . . . . . . . . . . . . . . . . 15
3.2. Data Channel . . . . . . . . . . . . . . . . . . . . . . 15 3.2. Data Channel . . . . . . . . . . . . . . . . . . . . . . 15
4. Security Considerations . . . . . . . . . . . . . . . . . . . 16 4. Security Considerations . . . . . . . . . . . . . . . . . . . 16
5. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 17 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 17 6. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 17
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 17 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 17
7.1. Normative References . . . . . . . . . . . . . . . . . . 17 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 17
7.2. Informative References . . . . . . . . . . . . . . . . . 19 8.1. Normative References . . . . . . . . . . . . . . . . . . 17
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20 8.2. Informative References . . . . . . . . . . . . . . . . . 19
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19
1. Introduction 1. Introduction
1.1. Context and Motivation 1.1. Context and Motivation
Distributed Denial of Service (DDoS) attacks afflict networks of all Distributed Denial of Service (DDoS) attacks afflict networks of all
kinds, plaguing network operators at service providers and kinds, plaguing network operators at service providers and
enterprises around the world. High-volume attacks saturating inbound enterprises around the world. High-volume attacks saturating inbound
links are now common, as attack scale and frequency continue to links are now common, as attack scale and frequency continue to
increase. increase.
skipping to change at page 6, line 14 skipping to change at page 6, line 14
clients need to justify withdrawing help requests: the decision is clients need to justify withdrawing help requests: the decision is
local to the DOTS clients' domain. Multi-homed DOTS clients must be local to the DOTS clients' domain. Multi-homed DOTS clients must be
able to select the appropriate DOTS server(s) to which a mitigation able to select the appropriate DOTS server(s) to which a mitigation
request is to be sent. The method for selecting the appropriate DOTS request is to be sent. The method for selecting the appropriate DOTS
server in a multi-homed environment is out of scope. server in a multi-homed environment is out of scope.
DOTS protocol implementations face competing operational goals when DOTS protocol implementations face competing operational goals when
maintaining this bidirectional communication stream. On the one maintaining this bidirectional communication stream. On the one
hand, DOTS must include protections ensuring message confidentiality, hand, DOTS must include protections ensuring message confidentiality,
integrity and authenticity to keep the protocols from becoming integrity and authenticity to keep the protocols from becoming
additional vectors for the very attadcks it is meant to help fight additional vectors for the very attacks it is meant to help fight
off. On the other hand, the protocol must be resilient under off. On the other hand, the protocol must be resilient under
extremely hostile network conditions, providing continued contact extremely hostile network conditions, providing continued contact
between DOTS agents even as attack traffic saturates the link. Such between DOTS agents even as attack traffic saturates the link. Such
resiliency may be developed several ways, but characteristics such as resiliency may be developed several ways, but characteristics such as
small message size, asynchronous, redundant message delivery and small message size, asynchronous, redundant message delivery and
minimal connection overhead (when possible given local network minimal connection overhead (when possible given local network
policy) will tend to contribute to the robustness demanded by a policy) will tend to contribute to the robustness demanded by a
viable DOTS protocol. Operators of peer DOTS-enabled domains may viable DOTS protocol. Operators of peer DOTS-enabled domains may
enable quality- or class-of-service traffic tagging to increase the enable quality- or class-of-service traffic tagging to increase the
probability of successful DOTS signal delivery, but DOTS does not probability of successful DOTS signal delivery, but DOTS does not
require such policies be in place, and should be viable in their require such policies be in place, and should be viable in their
absence. absence.
The DOTS server and client must also have some standardized method of The DOTS server and client must also have some standardized method of
defining the scope of any mitigation, and negotiating related defining the scope of any mitigation, as well as managing other
mitigation communication and actions and communications. mitigation-related configuration.
Finally, DOTS should be sufficiently extensible to meet future needs Finally, DOTS should be sufficiently extensible to meet future needs
in coordinated attack defense, although this consideration is in coordinated attack defense, although this consideration is
necessarily superseded by the other operational requirements. necessarily superseded by the other operational requirements.
2.1. General Requirements 2.1. General Requirements
GEN-001 Extensibility: Protocols and data models developed as part GEN-001 Extensibility: Protocols and data models developed as part
of DOTS MUST be extensible in order to keep DOTS adaptable to of DOTS MUST be extensible in order to keep DOTS adaptable to
operational and proprietary DDoS defenses. Future extensions MUST operational and proprietary DDoS defenses. Future extensions MUST
skipping to change at page 10, line 6 skipping to change at page 10, line 6
deployment- specific, but SHOULD be sufficiently long to absorb deployment- specific, but SHOULD be sufficiently long to absorb
latency incurred by route propagation. If the client requests latency incurred by route propagation. If the client requests
mitigation again before the initial active-but-terminating period mitigation again before the initial active-but-terminating period
elapses, the DOTS server MAY exponentially increase the active- elapses, the DOTS server MAY exponentially increase the active-
but-terminating period up to a maximum of 300 seconds (5 minutes). but-terminating period up to a maximum of 300 seconds (5 minutes).
After the active-but-terminating period elapses, the DOTS server After the active-but-terminating period elapses, the DOTS server
MUST treat the mitigation as terminated, as the DOTS client is no MUST treat the mitigation as terminated, as the DOTS client is no
longer responsible for the mitigation. longer responsible for the mitigation.
SIG-006 Mitigation Lifetime: DOTS servers MUST support mitigations SIG-006 Mitigation Lifetime: DOTS servers MUST support mitigations
for a negotiated time interval or lifetime, and MUST terminate a for a negotiated time interval, and MUST terminate a mitigation
mitigation when the lifetime elapses. DOTS servers also MUST when the lifetime elapses. DOTS servers also MUST support renewal
support renewal of mitigation lifetimes in mitigation requests of mitigation lifetimes in mitigation requests from DOTS clients,
from DOTS clients, allowing clients to extend mitigation as allowing clients to extend mitigation as necessary for the
necessary for the duration of an attack. duration of an attack.
DOTS servers MUST treat a mitigation terminated due to lifetime DOTS servers MUST treat a mitigation terminated due to lifetime
expiration exactly as if the DOTS client originating the expiration exactly as if the DOTS client originating the
mitigation had asked to end the mitigation, including the active- mitigation had asked to end the mitigation, including the active-
but-terminating period, as described above in SIG-005. but-terminating period, as described above in SIG-005.
DOTS clients MUST include a mitigation lifetime in all mitigation DOTS clients MUST include a mitigation lifetime in all mitigation
requests. requests.
DOTS servers SHOULD support indefinite mitigation lifetimes, DOTS servers SHOULD support indefinite mitigation lifetimes,
skipping to change at page 11, line 46 skipping to change at page 11, line 46
error, or compromised DOTS clients. DOTS servers in the same error, or compromised DOTS clients. DOTS servers in the same
administrative domain attempting to honor conflicting requests may administrative domain attempting to honor conflicting requests may
flap network route or DNS information, degrading the networks flap network route or DNS information, degrading the networks
attempting to participate in attack response with the DOTS attempting to participate in attack response with the DOTS
clients. DOTS servers in a single administrative domain SHALL clients. DOTS servers in a single administrative domain SHALL
detect such conflicting requests, and SHALL notify the DOTS detect such conflicting requests, and SHALL notify the DOTS
clients in conflict. The notification SHOULD indicate the nature clients in conflict. The notification SHOULD indicate the nature
and scope of the conflict, for example, the overlapping prefix and scope of the conflict, for example, the overlapping prefix
range in a conflicting mitigation request. range in a conflicting mitigation request.
SIG-010: Network Address Translator Traversal: DOTS clients may be SIG-010 Network Address Translator Traversal: DOTS clients may be
deployed behind a Network Address Translator (NAT), and need to deployed behind a Network Address Translator (NAT), and need to
communicate with DOTS servers through the NAT. DOTS protocols communicate with DOTS servers through the NAT. DOTS protocols
MUST therefore be capable of traversing NATs. MUST therefore be capable of traversing NATs.
If UDP is used as the transport for the DOTS signal channel, all If UDP is used as the transport for the DOTS signal channel, all
considerations in "Middlebox Traversal Guidelines" in [RFC8085] considerations in "Middlebox Traversal Guidelines" in [RFC8085]
apply to DOTS. Regardless of transport, DOTS protocols MUST apply to DOTS. Regardless of transport, DOTS protocols MUST
follow established best common practices established in BCP 127 follow established best common practices established in BCP 127
for NAT traversal [RFC4787][RFC6888][RFC7857]. for NAT traversal [RFC4787][RFC6888][RFC7857].
skipping to change at page 14, line 28 skipping to change at page 14, line 28
or deletion of scope aliases and black-/white-lists when the DOTS or deletion of scope aliases and black-/white-lists when the DOTS
client is unauthorized. client is unauthorized.
The modes of authorization are implementation-specific. The modes of authorization are implementation-specific.
2.5. Data Model Requirements 2.5. Data Model Requirements
A well-structured DOTS data model is critical to the development of A well-structured DOTS data model is critical to the development of
successful DOTS protocols. successful DOTS protocols.
DM-001: Structure: The data model structure for the DOTS protocol DM-001 Structure: The data model structure for the DOTS protocol MAY
MAY be described by a single module, or be divided into related be described by a single module, or be divided into related
collections of hierarchical modules and sub-modules. If the data collections of hierarchical modules and sub-modules. If the data
model structure is split across modules, those distinct modules model structure is split across modules, those distinct modules
MUST allow references to describe the overall data model's MUST allow references to describe the overall data model's
structural dependencies. structural dependencies.
DM-002: Versioning: To ensure interoperability between DOTS protocol DM-002 Versioning: To ensure interoperability between DOTS protocol
implementations, data models MUST be versioned. How the protocols implementations, data models MUST be versioned. How the protocols
represent data model versions is not defined in this document. represent data model versions is not defined in this document.
DM-003: Mitigation Status Representation: The data model MUST DM-003 Mitigation Status Representation: The data model MUST provide
provide the ability to represent a request for mitigation and the the ability to represent a request for mitigation and the
withdrawal of such a request. The data model MUST also support a withdrawal of such a request. The data model MUST also support a
representation of currently requested mitigation status, including representation of currently requested mitigation status, including
failures and their causes. failures and their causes.
DM-004: Mitigation Scope Representation: The data model MUST support DM-004 Mitigation Scope Representation: The data model MUST support
representation of a requested mitigation's scope. As mitigation representation of a requested mitigation's scope. As mitigation
scope may be represented in several different ways, per SIG-007 scope may be represented in several different ways, per SIG-007
above, the data model MUST be capable of flexible representation above, the data model MUST be capable of flexible representation
of mitigation scope. of mitigation scope.
DM-005: Mitigation Lifetime Representation: The data model MUST DM-005 Mitigation Lifetime Representation: The data model MUST
support representation of a mitigation request's lifetime, support representation of a mitigation request's lifetime,
including mitigations with no specified end time. including mitigations with no specified end time.
DM-006: Mitigation Efficacy Representation: The data model MUST DM-006 Mitigation Efficacy Representation: The data model MUST
support representation of a DOTS client's understanding of the support representation of a DOTS client's understanding of the
efficacy of a mitigation enabled through a mitigation request. efficacy of a mitigation enabled through a mitigation request.
DM-007: Acceptable Signal Loss Representation: The data model MUST DM-007 Acceptable Signal Loss Representation: The data model MUST be
be able to represent the DOTS agent's preference for acceptable able to represent the DOTS agent's preference for acceptable
signal loss when establishing a signal channel, as described in signal loss when establishing a signal channel, as described in
GEN-002. GEN-002.
DM-008: Heartbeat Interval Representation: The data model MUST be DM-008 Heartbeat Interval Representation: The data model MUST be
able to represent the DOTS agent's preferred heartbeat interval, able to represent the DOTS agent's preferred heartbeat interval,
which the client may include when establishing the signal channel, which the client may include when establishing the signal channel,
as described in SIG-003. as described in SIG-003.
DM-009: Relationship to Transport: The DOTS data model MUST NOT DM-009 Relationship to Transport: The DOTS data model MUST NOT
depend on the specifics of any transport to represent fields in depend on the specifics of any transport to represent fields in
the model. the model.
3. Congestion Control Considerations 3. Congestion Control Considerations
3.1. Signal Channel 3.1. Signal Channel
As part of a protocol expected to operate over links affected by DDoS As part of a protocol expected to operate over links affected by DDoS
attack traffic, the DOTS signal channel MUST NOT contribute attack traffic, the DOTS signal channel MUST NOT contribute
significantly to link congestion. To meet the signal channel significantly to link congestion. To meet the signal channel
requirements above, DOTS signal channel implementations SHOULD requirements above, DOTS signal channel implementations SHOULD
support connectionless transports. However, some connectionless support connectionless transports. However, some connectionless
transports when deployed naively can be a source of network transports when deployed naively can be a source of network
congestion, as discussed in [RFC5405]. Signal channel congestion, as discussed in [RFC8085]. Signal channel
implementations using such connectionless transports, such as UDP, implementations using such connectionless transports, such as UDP,
therefore MUST include a congestion control mechanism. therefore MUST include a congestion control mechanism.
Signal channel implementations using TCP may rely on built-in TCP Signal channel implementations using TCP may rely on built-in TCP
congestion control support. congestion control support.
3.2. Data Channel 3.2. Data Channel
As specified in DATA-001, the data channel requires reliable, in- As specified in DATA-001, the data channel requires reliable, in-
order message delivery. Data channel implementations using TCP may order message delivery. Data channel implementations using TCP may
rely on the TCP implementation's built-in congestion control rely on the TCP implementation's built-in congestion control
mechanisms. mechanisms.
4. Security Considerations 4. Security Considerations
This document informs future protocols under development, and so does This document informs future protocols under development, and so does
not have its security considerations of its own. However, naive DOTS not have security considerations of its own. However, operators
deployment potentially exposes networks to new attack vectors. The should be aware of potential risks involved in deploying DOTS. DOTS
three primary attack vectors are DOTS agent impersonation, traffic agent impersonation and signal blocking are discussed here.
injection, and signal blocking. Additional DOTS security considerations may be found in
[I-D.ietf-dots-architecture] and DOTS protocol documents.
Impersonation of either DOTS server or DOTS client could have Impersonation of either DOTS server or DOTS client could have
catastrophic impact on operations in either domain. Should an catastrophic impact on operations in either domain. If an attacker
attacker develop the ability to impersonate a DOTS client, that has the ability to impersonate a DOTS client, that attacker can
attacker can affect policy on the network path to the DOTS client's affect policy on the network path to the DOTS client's domain, up to
domain, up to and including instantiation of blacklists blocking all and including instantiation of blacklists blocking all inbound
inbound traffic to networks for which the DOTS client is authorized traffic to networks for which the DOTS client is authorized to
to request mitigation. Similarly, an impersonated DOTS server may be request mitigation.
able to act as a sort of malicious DOTS gateway, intercepting
requests from the downstream DOTS client, modifying them to inflict
the desired impact on traffic to or from the DOTS client's domain.
Among other things, this malicious DOTS gateway might receive
mitigation requests from the DOTS client, and simply discard them,
ensuring no mitigation is ever applied.
Traffic injection into a naive DOTS deployment could allow an
attacker to affect DOTS operations selectively. Rather than
impersonating a DOTS agent directly, the attacker crafts DOTS signal
or data channel messages in such a way that the targeted DOTS agent
treats them as if they originated with a legitimate DOTS agent, for
example, by spoofing the sender's IP address. As with agent
impersonation, the attacker capable of injecting traffic can affect
the network path to addresses for which the DOTS client is authorized
to request mitigation.
Blocking communication between DOTS agents-signal blocking-has the Similarly, an impersonated DOTS server may be able to act as a sort
potential to disrupt the core function of DOTS, which is to request of malicious DOTS gateway, intercepting requests from the downstream
mitigation of active or expected DDoS attacks. The DOTS signal DOTS client, and modifying them before transmission to the DOTS
channel is expected to operate over congested inbound links, and, as server to inflict the desired impact on traffic to or from the DOTS
described in Section 2.2, the signal channel protocol must be client's domain. Among other things, this malicious DOTS gateway
designed for minimal data transfer to reduce the incidence of signal might receive and discard mitigation requests from the DOTS client,
blocking. ensuring no requested mitigation is ever applied.
As detailed in Section 2.4, DOTS implementations require mutual As detailed in Section 2.4, DOTS implementations require mutual
authentication of DOTS agents in order to make agent impersonation authentication of DOTS agents in order to make agent impersonation
and traffic injection more difficult. However, impersonation or more difficult. However, impersonation may still be possible as a
traffic injection may still be possible as a result of credential result of credential theft, implementation flaws, or compromise of
theft, implementation flaws, or compromise of DOTS agents. Operators DOTS agents. To detect misuse, DOTS operators should carefully
should take steps to reduce attack surfaces through current secure monitor and audit DOTS agents, while employing current secure network
network communications best practices. communications best practices to reduce attack surface.
5. Contributors Blocking communication between DOTS agents has the potential to
disrupt the core function of DOTS, which is to request mitigation of
active or expected DDoS attacks. The DOTS signal channel is expected
to operate over congested inbound links, and, as described in
Section 2.2, the signal channel protocol must be designed for minimal
data transfer to reduce the incidence of signal blocking.
5. IANA Considerations
This document does not require any IANA action.
6. Contributors
Mohamed Boucadair Mohamed Boucadair
Orange Orange
mohamed.boucadair@orange.com mohamed.boucadair@orange.com
Flemming Andreasen Flemming Andreasen
Cisco Systems, Inc. Cisco Systems, Inc.
fandreas@cisco.com fandreas@cisco.com
Dave Dolson Dave Dolson
Sandvine Sandvine
ddolson@sandvine.com ddolson@sandvine.com
6. Acknowledgments 7. Acknowledgments
Thanks to Roman Danyliw and Matt Richardson for careful reading and Thanks to Roman Danyliw and Matt Richardson for careful reading and
feedback. feedback.
7. References 8. References
7.1. Normative References 8.1. Normative References
[RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768,
DOI 10.17487/RFC0768, August 1980, DOI 10.17487/RFC0768, August 1980,
<https://www.rfc-editor.org/info/rfc768>. <https://www.rfc-editor.org/info/rfc768>.
[RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791,
DOI 10.17487/RFC0791, September 1981, DOI 10.17487/RFC0791, September 1981,
<https://www.rfc-editor.org/info/rfc791>. <https://www.rfc-editor.org/info/rfc791>.
[RFC0793] Postel, J., "Transmission Control Protocol", STD 7, [RFC0793] Postel, J., "Transmission Control Protocol", STD 7,
skipping to change at page 18, line 37 skipping to change at page 18, line 37
[RFC4787] Audet, F., Ed. and C. Jennings, "Network Address [RFC4787] Audet, F., Ed. and C. Jennings, "Network Address
Translation (NAT) Behavioral Requirements for Unicast Translation (NAT) Behavioral Requirements for Unicast
UDP", BCP 127, RFC 4787, DOI 10.17487/RFC4787, January UDP", BCP 127, RFC 4787, DOI 10.17487/RFC4787, January
2007, <https://www.rfc-editor.org/info/rfc4787>. 2007, <https://www.rfc-editor.org/info/rfc4787>.
[RFC4821] Mathis, M. and J. Heffner, "Packetization Layer Path MTU [RFC4821] Mathis, M. and J. Heffner, "Packetization Layer Path MTU
Discovery", RFC 4821, DOI 10.17487/RFC4821, March 2007, Discovery", RFC 4821, DOI 10.17487/RFC4821, March 2007,
<https://www.rfc-editor.org/info/rfc4821>. <https://www.rfc-editor.org/info/rfc4821>.
[RFC5405] Eggert, L. and G. Fairhurst, "Unicast UDP Usage Guidelines
for Application Designers", RFC 5405,
DOI 10.17487/RFC5405, November 2008,
<https://www.rfc-editor.org/info/rfc5405>.
[RFC6888] Perreault, S., Ed., Yamagata, I., Miyakawa, S., Nakagawa, [RFC6888] Perreault, S., Ed., Yamagata, I., Miyakawa, S., Nakagawa,
A., and H. Ashida, "Common Requirements for Carrier-Grade A., and H. Ashida, "Common Requirements for Carrier-Grade
NATs (CGNs)", BCP 127, RFC 6888, DOI 10.17487/RFC6888, NATs (CGNs)", BCP 127, RFC 6888, DOI 10.17487/RFC6888,
April 2013, <https://www.rfc-editor.org/info/rfc6888>. April 2013, <https://www.rfc-editor.org/info/rfc6888>.
[RFC7857] Penno, R., Perreault, S., Boucadair, M., Ed., Sivakumar, [RFC7857] Penno, R., Perreault, S., Boucadair, M., Ed., Sivakumar,
S., and K. Naito, "Updates to Network Address Translation S., and K. Naito, "Updates to Network Address Translation
(NAT) Behavioral Requirements", BCP 127, RFC 7857, (NAT) Behavioral Requirements", BCP 127, RFC 7857,
DOI 10.17487/RFC7857, April 2016, DOI 10.17487/RFC7857, April 2016,
<https://www.rfc-editor.org/info/rfc7857>. <https://www.rfc-editor.org/info/rfc7857>.
[RFC8085] Eggert, L., Fairhurst, G., and G. Shepherd, "UDP Usage [RFC8085] Eggert, L., Fairhurst, G., and G. Shepherd, "UDP Usage
Guidelines", BCP 145, RFC 8085, DOI 10.17487/RFC8085, Guidelines", BCP 145, RFC 8085, DOI 10.17487/RFC8085,
March 2017, <https://www.rfc-editor.org/info/rfc8085>. March 2017, <https://www.rfc-editor.org/info/rfc8085>.
[RFC5952] Kawamura, S. and M. Kawashima, "A Recommendation for IPv6 [RFC5952] Kawamura, S. and M. Kawashima, "A Recommendation for IPv6
Address Text Representation", RFC 5952, Address Text Representation", RFC 5952,
DOI 10.17487/RFC5952, August 2010, DOI 10.17487/RFC5952, August 2010,
<https://www.rfc-editor.org/info/rfc5952>. <https://www.rfc-editor.org/info/rfc5952>.
7.2. Informative References 8.2. Informative References
[I-D.ietf-dots-architecture] [I-D.ietf-dots-architecture]
Mortensen, A., Andreasen, F., Reddy, T., Mortensen, A., Andreasen, F., Reddy, T.,
christopher_gray3@cable.comcast.com, c., Compton, R., and christopher_gray3@cable.comcast.com, c., Compton, R., and
N. Teague, "Distributed-Denial-of-Service Open Threat N. Teague, "Distributed-Denial-of-Service Open Threat
Signaling (DOTS) Architecture", draft-ietf-dots- Signaling (DOTS) Architecture", draft-ietf-dots-
architecture-05 (work in progress), October 2017. architecture-05 (work in progress), October 2017.
[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.,
 End of changes. 29 change blocks. 
80 lines changed or deleted 72 lines changed or added

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