draft-ietf-dots-architecture-07.txt   draft-ietf-dots-architecture-08.txt 
DOTS A. Mortensen DOTS A. Mortensen
Internet-Draft Arbor Networks Internet-Draft Arbor Networks
Intended status: Informational F. Andreasen Intended status: Informational F. Andreasen
Expires: March 8, 2019 Cisco Expires: May 31, 2019 Cisco
T. Reddy T. Reddy
McAfee, Inc. McAfee, Inc.
C. Gray
R. Compton
Charter
N. Teague N. Teague
Verisign Verisign
September 04, 2018 R. Compton
Charter
C. Gray
November 27, 2018
Distributed-Denial-of-Service Open Threat Signaling (DOTS) Architecture Distributed-Denial-of-Service Open Threat Signaling (DOTS) Architecture
draft-ietf-dots-architecture-07 draft-ietf-dots-architecture-08
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 44 skipping to change at page 1, line 43
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 March 8, 2019. This Internet-Draft will expire on May 31, 2019.
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 34 skipping to change at page 2, line 29
1.1.1. Key Words . . . . . . . . . . . . . . . . . . . . . . 3 1.1.1. Key Words . . . . . . . . . . . . . . . . . . . . . . 3
1.1.2. Definition of Terms . . . . . . . . . . . . . . . . . 3 1.1.2. Definition of Terms . . . . . . . . . . . . . . . . . 3
1.2. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.2. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.3. Assumptions . . . . . . . . . . . . . . . . . . . . . . . 4 1.3. Assumptions . . . . . . . . . . . . . . . . . . . . . . . 4
2. DOTS Architecture . . . . . . . . . . . . . . . . . . . . . . 5 2. DOTS Architecture . . . . . . . . . . . . . . . . . . . . . . 5
2.1. DOTS Operations . . . . . . . . . . . . . . . . . . . . . 8 2.1. DOTS Operations . . . . . . . . . . . . . . . . . . . . . 8
2.2. Components . . . . . . . . . . . . . . . . . . . . . . . 9 2.2. Components . . . . . . . . . . . . . . . . . . . . . . . 9
2.2.1. DOTS Client . . . . . . . . . . . . . . . . . . . . . 9 2.2.1. DOTS Client . . . . . . . . . . . . . . . . . . . . . 9
2.2.2. DOTS Server . . . . . . . . . . . . . . . . . . . . . 10 2.2.2. DOTS Server . . . . . . . . . . . . . . . . . . . . . 10
2.2.3. DOTS Gateway . . . . . . . . . . . . . . . . . . . . 11 2.2.3. DOTS Gateway . . . . . . . . . . . . . . . . . . . . 11
2.3. DOTS Agent Relationships . . . . . . . . . . . . . . . . 12 2.3. DOTS Agent Relationships . . . . . . . . . . . . . . . . 11
2.3.1. Gatewayed Signaling . . . . . . . . . . . . . . . . . 14 2.3.1. Gatewayed Signaling . . . . . . . . . . . . . . . . . 13
3. Concepts . . . . . . . . . . . . . . . . . . . . . . . . . . 16 3. Concepts . . . . . . . . . . . . . . . . . . . . . . . . . . 15
3.1. DOTS Sessions . . . . . . . . . . . . . . . . . . . . . . 16 3.1. DOTS Sessions . . . . . . . . . . . . . . . . . . . . . . 15
3.1.1. Preconditions . . . . . . . . . . . . . . . . . . . . 16 3.1.1. Preconditions . . . . . . . . . . . . . . . . . . . . 16
3.1.2. Establishing the DOTS Session . . . . . . . . . . . . 16 3.1.2. Establishing the DOTS Session . . . . . . . . . . . . 16
3.1.3. Maintaining the DOTS Session . . . . . . . . . . . . 17 3.1.3. Maintaining the DOTS Session . . . . . . . . . . . . 17
3.2. Modes of Signaling . . . . . . . . . . . . . . . . . . . 18 3.2. Modes of Signaling . . . . . . . . . . . . . . . . . . . 18
3.2.1. Direct Signaling . . . . . . . . . . . . . . . . . . 18 3.2.1. Direct Signaling . . . . . . . . . . . . . . . . . . 18
3.2.2. Redirected Signaling . . . . . . . . . . . . . . . . 18 3.2.2. Redirected Signaling . . . . . . . . . . . . . . . . 18
3.2.3. Recursive Signaling . . . . . . . . . . . . . . . . . 19 3.2.3. Recursive Signaling . . . . . . . . . . . . . . . . . 19
3.2.4. Anycast Signaling . . . . . . . . . . . . . . . . . . 22 3.2.4. Anycast Signaling . . . . . . . . . . . . . . . . . . 22
3.2.5. Signaling Considerations for Network Address 3.2.5. Signaling Considerations for Network Address
Translation . . . . . . . . . . . . . . . . . . . . . 23 Translation . . . . . . . . . . . . . . . . . . . . . 23
3.3. Triggering Requests for Mitigation . . . . . . . . . . . 25 3.3. Triggering Requests for Mitigation . . . . . . . . . . . 26
3.3.1. Manual Mitigation Request . . . . . . . . . . . . . . 26 3.3.1. Manual Mitigation Request . . . . . . . . . . . . . . 26
3.3.2. Automated Conditional Mitigation Request . . . . . . 27 3.3.2. Automated Conditional Mitigation Request . . . . . . 27
3.3.3. Automated Mitigation on Loss of Signal . . . . . . . 27 3.3.3. Automated Mitigation on Loss of Signal . . . . . . . 28
4. Security Considerations . . . . . . . . . . . . . . . . . . . 28 4. Security Considerations . . . . . . . . . . . . . . . . . . . 29
5. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 29 5. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 29
6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 29 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 29
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 29 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 30
7.1. Normative References . . . . . . . . . . . . . . . . . . 29 7.1. Normative References . . . . . . . . . . . . . . . . . . 30
7.2. Informative References . . . . . . . . . . . . . . . . . 29 7.2. Informative References . . . . . . . . . . . . . . . . . 30
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 31
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 32
1. Context and Motivation 1. Context and Motivation
Signaling the need for help defending against an active distributed Signaling the need for help defending against an active distributed
denial of service (DDoS) attack requires a common understanding of denial of service (DDoS) attack requires a common understanding of
mechanisms and roles among the parties coordinating defensive mechanisms and roles among the parties coordinating defensive
response. The signaling layer and supplementary messaging is the response. The signaling layer and supplementary messaging is the
focus of DDoS Open Threat Signaling (DOTS). DOTS defines a method of focus of DDoS Open Threat Signaling (DOTS). DOTS defines a method of
coordinating defensive measures among willing peers to mitigate coordinating defensive measures among willing peers to mitigate
attacks quickly and efficiently, enabling hybrid attack responses attacks quickly and efficiently, enabling hybrid attack responses
skipping to change at page 9, line 52 skipping to change at page 9, line 44
client's desired mitigation scoping, as described in client's desired mitigation scoping, as described in
[I-D.ietf-dots-requirements]. The actual mitigation scope and [I-D.ietf-dots-requirements]. The actual mitigation scope and
countermeasures used in response to the attack are up to the DOTS countermeasures used in response to the attack are up to the DOTS
server and mitigator operators, as the DOTS client may have a narrow server and mitigator operators, as the DOTS client may have a narrow
perspective on the ongoing attack. As such, the DOTS client's perspective on the ongoing attack. As such, the DOTS client's
request for mitigation should be considered advisory: guarantees of request for mitigation should be considered advisory: guarantees of
DOTS server availability or mitigation capacity constitute service DOTS server availability or mitigation capacity constitute service
level agreements and are out of scope for this document. level agreements and are 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
server, and may consider a session terminated in the extended absence server, and may consider a session terminated in the extended absence
of a DOTS server heartbeat. of a DOTS server heartbeat.
skipping to change at page 24, line 24 skipping to change at page 24, line 24
addresses or prefixes to externally routable mitigation scopes by addresses or prefixes to externally routable mitigation scopes by
directly provisioning the mappings of external addresses to internal directly provisioning the mappings of external addresses to internal
protected resources on the DOTS client. When the operator requests protected resources on the DOTS client. When the operator requests
mitigation scoped for internal addresses, directly or through mitigation scoped for internal addresses, directly or through
automated means, the DOTS client looks up the matching external automated means, the DOTS client looks up the matching external
addresses or prefixes, and issues a mitigation request scoped to that addresses or prefixes, and issues a mitigation request scoped to that
externally routable information. externally routable information.
When directly provisioning the address mappings, operators must When directly provisioning the address mappings, operators must
ensure the mappings remain up to date, or risk losing the ability to ensure the mappings remain up to date, or risk losing the ability to
request accurate mitigation scopes. This document does not prescribe request accurate mitigation scopes. To that aim, the DOTS client can
the method by which mappings are maintained once they are provisioned rely on mechanisms, such as [I-D.ietf-opsawg-nat-yang] to retrieve
on the DOTS client. static explicit mappings. This document does not prescribe the
method by which mappings are maintained once they are provisioned on
the DOTS client.
3.2.5.2. Resolving Public Mitigation Scope with Session Traversal 3.2.5.2. Resolving Public Mitigation Scope with Port Control Protocol
(PCP)
Port Control Protocol (PCP) [RFC6887] may be used to retrieve the
external addresses/prefixes and/or port numbers if the NAT function
embeds a PCP server.
A DOTS client can use the information retrieved by means of PCP to
feed the DOTS protocol(s) messages that will be sent to a DOTS
server. These messages will convey the external addresses/prefixes
as set by the NAT.
PCP also enables discovery and configuration of the lifetime of port
mappings instantiated in intermediate NAT devices. Discovery of port
mapping lifetimes can reduce the dependency on heartbeat messages to
maintain mappings, and therefore reduce the load on DOTS servers and
the network.
3.2.5.3. Resolving Public Mitigation Scope with Session Traversal
Utilities (STUN) Utilities (STUN)
Internal resources may discover their external address through a STUN An internal resource, e.g., a Web server, can discover its reflexive
Binding request/response transaction, as described in [RFC5389]. transport address through a STUN Binding request/response
After learning its reflexive transport address from the STUN server, transaction, as described in [RFC5389]. After learning its reflexive
the internal service can export its external/internal address pair to transport address from the STUN server, the internal resource can
the DOTS client, allowing the DOTS client to request mitigation with export its reflexive transport address and internal transport address
the correct external scope, as depicted in Figure 14. The mechanism to the DOTS client, thereby enabling the DOTS client to request
for provisioning the DOTS client with the address pair is mitigation with the correct external scope, as depicted in Figure 14.
unspecified. The mechanism for providing the DOTS client with the reflexive
transport address and internal transport address is unspecified in
this document.
Binding Binding In order to prevent an attacker from modifying the STUN messages in
+--------+ request +---+ request +--------+ transit, the STUN client and server MUST use the message-integrity
| STUN |<----------| N |<----------| STUN | mechanism discussed in Section 10 of [RFC5389] or use STUN over DTLS
| server | | A | | client | [RFC7350] or use STUN over TLS. If the STUN client is behind a NAT
| |---------->| T |---------->| | that performs Endpoint-Dependent Mapping, the internal service cannot
+--------+ Binding +---+ Binding +--------+ provide the DOTS client with the reflexive transport address
response response | discovered using STUN. The behavior of a NAT between the STUN client
| external/internal and the STUN server could be discovered using the techniques
| address pair discussed in [RFC5780].
v
+--------+ Binding Binding
| DOTS | +--------+ request +---+ request +--------+
| client | | STUN |<----------| N |<----------| STUN |
+--------+ | server | | A | | client |
| |---------->| T |---------->| |
+--------+ Binding +---+ Binding +--------+
response response |
| reflexive transport address
| & internal transport address
v
+--------+
| DOTS |
| client |
+--------+
Figure 14: Resolving mitigation scope with STUN Figure 14: Resolving mitigation scope with STUN
3.2.5.3. Resolving Requested Mitigation Scope with DNS 3.2.5.4. Resolving Requested Mitigation Scope with DNS
DOTS supports mitigation scoped to DNS names. As discussed in DOTS supports mitigation scoped to DNS names. As discussed in
[RFC3235], using DNS names instead of IP addresses potentially avoids [RFC3235], using DNS names instead of IP addresses potentially avoids
the address translation problem, as long as the name is internally the address translation problem, as long as the name is internally
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. mitigation. For the reverse DNS lookup, DNS Security Extensions
(DNSSEC) [RFC4033] must be used where the authenticity of response is
critical.
3.3. Triggering Requests for Mitigation 3.3. Triggering Requests for Mitigation
[I-D.ietf-dots-requirements] places no limitation on the [I-D.ietf-dots-requirements] places no limitation on the
circumstances in which a DOTS client operator may request mitigation, circumstances in which a DOTS client operator may request mitigation,
nor does it demand justification for any mitigation request, thereby nor does it demand justification for any mitigation request, thereby
reserving operational control over DDoS defense for the domain reserving operational control over DDoS defense for the domain
requesting mitigation. This architecture likewise does not prescribe requesting mitigation. This architecture likewise does not prescribe
the network conditions and mechanisms triggering a mitigation request the network conditions and mechanisms triggering a mitigation request
from a DOTS client. from a DOTS client.
skipping to change at page 29, line 35 skipping to change at page 30, line 17
7.1. Normative References 7.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>.
7.2. Informative References 7.2. Informative References
[I-D.ietf-dots-requirements] [I-D.ietf-dots-requirements]
Mortensen, A., Moskowitz, R., and T. Reddy, "Distributed Mortensen, A., Moskowitz, R., and R. K, "Distributed
Denial of Service (DDoS) Open Threat Signaling Denial of Service (DDoS) Open Threat Signaling
Requirements", draft-ietf-dots-requirements-15 (work in Requirements", draft-ietf-dots-requirements-16 (work in
progress), August 2018. progress), October 2018.
[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-16 (work Open Threat Signaling", draft-ietf-dots-use-cases-16 (work
in progress), July 2018. in progress), July 2018.
[I-D.ietf-opsawg-nat-yang]
Boucadair, M., Sivakumar, S., Jacquenet, C., Vinapamula,
S., and Q. Wu, "A YANG Module for Network Address
Translation (NAT) and Network Prefix Translation (NPT)",
draft-ietf-opsawg-nat-yang-17 (work in progress),
September 2018.
[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>.
[RFC0793] Postel, J., "Transmission Control Protocol", STD 7, [RFC0793] Postel, J., "Transmission Control Protocol", STD 7,
RFC 793, DOI 10.17487/RFC0793, September 1981, RFC 793, DOI 10.17487/RFC0793, September 1981,
<https://www.rfc-editor.org/info/rfc793>. <https://www.rfc-editor.org/info/rfc793>.
[RFC1035] Mockapetris, P., "Domain names - implementation and [RFC1035] Mockapetris, P., "Domain names - implementation and
specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, specification", STD 13, RFC 1035, DOI 10.17487/RFC1035,
skipping to change at page 30, line 25 skipping to change at page 31, line 16
Application Design Guidelines", RFC 3235, Application Design Guidelines", RFC 3235,
DOI 10.17487/RFC3235, January 2002, DOI 10.17487/RFC3235, January 2002,
<https://www.rfc-editor.org/info/rfc3235>. <https://www.rfc-editor.org/info/rfc3235>.
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
A., Peterson, J., Sparks, R., Handley, M., and E. A., Peterson, J., Sparks, R., Handley, M., and E.
Schooler, "SIP: Session Initiation Protocol", RFC 3261, Schooler, "SIP: Session Initiation Protocol", RFC 3261,
DOI 10.17487/RFC3261, June 2002, DOI 10.17487/RFC3261, June 2002,
<https://www.rfc-editor.org/info/rfc3261>. <https://www.rfc-editor.org/info/rfc3261>.
[RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S.
Rose, "DNS Security Introduction and Requirements",
RFC 4033, DOI 10.17487/RFC4033, March 2005,
<https://www.rfc-editor.org/info/rfc4033>.
[RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A
Border Gateway Protocol 4 (BGP-4)", RFC 4271, Border Gateway Protocol 4 (BGP-4)", RFC 4271,
DOI 10.17487/RFC4271, January 2006, DOI 10.17487/RFC4271, January 2006,
<https://www.rfc-editor.org/info/rfc4271>. <https://www.rfc-editor.org/info/rfc4271>.
[RFC4732] Handley, M., Ed., Rescorla, E., Ed., and IAB, "Internet [RFC4732] Handley, M., Ed., Rescorla, E., Ed., and IAB, "Internet
Denial-of-Service Considerations", RFC 4732, Denial-of-Service Considerations", RFC 4732,
DOI 10.17487/RFC4732, December 2006, DOI 10.17487/RFC4732, December 2006,
<https://www.rfc-editor.org/info/rfc4732>. <https://www.rfc-editor.org/info/rfc4732>.
skipping to change at page 30, line 49 skipping to change at page 31, line 45
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.2", RFC 5246, (TLS) Protocol Version 1.2", RFC 5246,
DOI 10.17487/RFC5246, August 2008, DOI 10.17487/RFC5246, August 2008,
<https://www.rfc-editor.org/info/rfc5246>. <https://www.rfc-editor.org/info/rfc5246>.
[RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, [RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing,
"Session Traversal Utilities for NAT (STUN)", RFC 5389, "Session Traversal Utilities for NAT (STUN)", RFC 5389,
DOI 10.17487/RFC5389, October 2008, DOI 10.17487/RFC5389, October 2008,
<https://www.rfc-editor.org/info/rfc5389>. <https://www.rfc-editor.org/info/rfc5389>.
[RFC5780] MacDonald, D. and B. Lowekamp, "NAT Behavior Discovery
Using Session Traversal Utilities for NAT (STUN)",
RFC 5780, DOI 10.17487/RFC5780, May 2010,
<https://www.rfc-editor.org/info/rfc5780>.
[RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer
Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347,
January 2012, <https://www.rfc-editor.org/info/rfc6347>. January 2012, <https://www.rfc-editor.org/info/rfc6347>.
[RFC6763] Cheshire, S. and M. Krochmal, "DNS-Based Service [RFC6763] Cheshire, S. and M. Krochmal, "DNS-Based Service
Discovery", RFC 6763, DOI 10.17487/RFC6763, February 2013, Discovery", RFC 6763, DOI 10.17487/RFC6763, February 2013,
<https://www.rfc-editor.org/info/rfc6763>. <https://www.rfc-editor.org/info/rfc6763>.
[RFC6887] Wing, D., Ed., Cheshire, S., Boucadair, M., Penno, R., and
P. Selkirk, "Port Control Protocol (PCP)", RFC 6887,
DOI 10.17487/RFC6887, April 2013,
<https://www.rfc-editor.org/info/rfc6887>.
[RFC7092] Kaplan, H. and V. Pascual, "A Taxonomy of Session [RFC7092] Kaplan, H. and V. Pascual, "A Taxonomy of Session
Initiation Protocol (SIP) Back-to-Back User Agents", Initiation Protocol (SIP) Back-to-Back User Agents",
RFC 7092, DOI 10.17487/RFC7092, December 2013, RFC 7092, DOI 10.17487/RFC7092, December 2013,
<https://www.rfc-editor.org/info/rfc7092>. <https://www.rfc-editor.org/info/rfc7092>.
[RFC7094] McPherson, D., Oran, D., Thaler, D., and E. Osterweil, [RFC7094] McPherson, D., Oran, D., Thaler, D., and E. Osterweil,
"Architectural Considerations of IP Anycast", RFC 7094, "Architectural Considerations of IP Anycast", RFC 7094,
DOI 10.17487/RFC7094, January 2014, DOI 10.17487/RFC7094, January 2014,
<https://www.rfc-editor.org/info/rfc7094>. <https://www.rfc-editor.org/info/rfc7094>.
[RFC7350] Petit-Huguenin, M. and G. Salgueiro, "Datagram Transport
Layer Security (DTLS) as Transport for Session Traversal
Utilities for NAT (STUN)", RFC 7350, DOI 10.17487/RFC7350,
August 2014, <https://www.rfc-editor.org/info/rfc7350>.
[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>.
Authors' Addresses Authors' Addresses
Andrew Mortensen Andrew Mortensen
Arbor Networks Arbor Networks
2727 S. State St 2727 S. State St
Ann Arbor, MI 48104 Ann Arbor, MI 48104
skipping to change at page 31, line 38 skipping to change at page 33, line 4
Ann Arbor, MI 48104 Ann Arbor, MI 48104
United States United States
EMail: amortensen@arbor.net EMail: amortensen@arbor.net
Flemming Andreasen Flemming Andreasen
Cisco Cisco
United States United States
EMail: fandreas@cisco.com EMail: fandreas@cisco.com
Tirumaleswar Reddy Tirumaleswar Reddy
McAfee, Inc. McAfee, Inc.
Embassy Golf Link Business Park Embassy Golf Link Business Park
Bangalore, Karnataka 560071 Bangalore, Karnataka 560071
India India
EMail: tireddy@cisco.com EMail: kondtir@gmail.com
Christopher Gray
Nik Teague
Verisign
United States United States
EMail: Christopher_Gray3@cable.comcast.com EMail: nteague@verisign.com
Rich Compton Rich Compton
Charter Charter
EMail: Rich.Compton@charter.com EMail: Rich.Compton@charter.com
Nik Teague Christopher Gray
Verisign
United States United States
EMail: nteague@verisign.com EMail: Christopher_Gray3@cable.comcast.com
 End of changes. 28 change blocks. 
57 lines changed or deleted 118 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/