draft-ietf-dots-architecture-00.txt   draft-ietf-dots-architecture-01.txt 
DOTS A. Mortensen DOTS A. Mortensen
Internet-Draft Arbor Networks, Inc. Internet-Draft Arbor Networks, Inc.
Intended status: Informational F. Andreasen Intended status: Informational F. Andreasen
Expires: January 6, 2017 T. Reddy Expires: May 4, 2017 T. Reddy
Cisco Systems, Inc. Cisco Systems, Inc.
C. Gray C. Gray
Comcast, Inc. Comcast, Inc.
R. Compton R. Compton
Charter Communications, Inc. Charter Communications, Inc.
N. Teague N. Teague
Verisign, Inc. Verisign, Inc.
July 05, 2016 October 31, 2016
Distributed-Denial-of-Service Open Threat Signaling (DOTS) Architecture Distributed-Denial-of-Service Open Threat Signaling (DOTS) Architecture
draft-ietf-dots-architecture-00 draft-ietf-dots-architecture-01
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 43 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 http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on January 6, 2017. This Internet-Draft will expire on May 4, 2017.
Copyright Notice Copyright Notice
Copyright (c) 2016 IETF Trust and the persons identified as the Copyright (c) 2016 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
(http://trustee.ietf.org/license-info) in effect on the date of (http://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 40 skipping to change at page 2, line 40
2.3.1. Gatewayed signaling . . . . . . . . . . . . . . . . . 13 2.3.1. Gatewayed signaling . . . . . . . . . . . . . . . . . 13
3. Concepts . . . . . . . . . . . . . . . . . . . . . . . . . . 15 3. Concepts . . . . . . . . . . . . . . . . . . . . . . . . . . 15
3.1. Signaling Sessions . . . . . . . . . . . . . . . . . . . 15 3.1. Signaling Sessions . . . . . . . . . . . . . . . . . . . 15
3.1.1. Preconditions . . . . . . . . . . . . . . . . . . . . 16 3.1.1. Preconditions . . . . . . . . . . . . . . . . . . . . 16
3.1.2. Establishing the Signaling Session . . . . . . . . . 16 3.1.2. Establishing the Signaling Session . . . . . . . . . 16
3.1.3. Maintaining the Signaling Session . . . . . . . . . . 17 3.1.3. Maintaining the Signaling Session . . . . . . . . . . 17
3.2. Modes of Signaling . . . . . . . . . . . . . . . . . . . 17 3.2. Modes of Signaling . . . . . . . . . . . . . . . . . . . 17
3.2.1. Direct Signaling . . . . . . . . . . . . . . . . . . 17 3.2.1. Direct Signaling . . . . . . . . . . . . . . . . . . 17
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.3. Triggering Requests for Mitigation . . . . . . . . . . . 21 3.2.4. Anycast Signaling . . . . . . . . . . . . . . . . . . 21
3.3.1. Manual Mitigation Request . . . . . . . . . . . . . . 21 3.3. Triggering Requests for Mitigation . . . . . . . . . . . 23
3.3.2. Automated Threshold-Based Mitigation Request . . . . 22 3.3.1. Manual Mitigation Request . . . . . . . . . . . . . . 23
3.3.3. Automated Mitigation on Loss of Signal . . . . . . . 23 3.3.2. Automated Conditional Mitigation Request . . . . . . 24
4. Security Considerations . . . . . . . . . . . . . . . . . . . 24 3.3.3. Automated Mitigation on Loss of Signal . . . . . . . 25
5. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 24 4. Security Considerations . . . . . . . . . . . . . . . . . . . 26
6. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 25 5. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 26
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 25 6. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 26
7.1. Normative References . . . . . . . . . . . . . . . . . . 25 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 27
7.2. Informative References . . . . . . . . . . . . . . . . . 25 7.1. Normative References . . . . . . . . . . . . . . . . . . 27
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 26 7.2. Informative References . . . . . . . . . . . . . . . . . 27
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 28
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 7, line 23 skipping to change at page 7, line 23
Examples of such information include, but are not limited to: Examples of such information include, but are not limited to:
o Creating identifiers, such as names or aliases, for resources for o Creating identifiers, such as names or aliases, for resources for
which mitigation may be requested. Such identifiers may then be which mitigation may be requested. Such identifiers may then be
used in subsequent signal channel exchanges to refer more used in subsequent signal channel exchanges to refer more
efficiently to the resources under attack, as seen in Figure 3 efficiently to the resources under attack, as seen in Figure 3
below, using JSON to serialize the data: below, using JSON to serialize the data:
{ {
"https1": [ "https1": [
"172.16.168.254:443", "192.0.2.1:443",
"172.16.169.254:443", "198.51.100.2:443",
], ],
"proxies": [ "proxies": [
"10.0.0.10:3128", "203.0.113.3:3128",
"[2001:db9::1/128]:3128" "[2001:DB8:AC10::1]:3128"
], ],
"api_urls": "https://apiserver.local/api/v1", "api_urls": "https://apiserver.example.com/api/v1",
} }
Figure 3: Protected resource identifiers Figure 3: Protected resource identifiers
o Black-list management, which enables a DOTS client to inform the o Black-list management, which enables a DOTS client to inform the
DOTS server about sources to suppress. DOTS server about sources to suppress.
o White-list management, which enables a DOTS client to inform the o White-list management, which enables a DOTS client to inform the
DOTS server about sources from which traffic should always be DOTS server about sources from which traffic should always be
accepted. accepted.
skipping to change at page 13, line 8 skipping to change at page 13, line 8
Figure 6 below. Operational considerations relating to co-ordinating Figure 6 below. Operational considerations relating to co-ordinating
multiple provider responses are beyond the scope of DOTS. multiple provider responses are beyond the scope of DOTS.
[[EDITOR'S NOTE: we request working group feedback and discussion of [[EDITOR'S NOTE: we request working group feedback and discussion of
operational considerations relating to coordinating multiple provider operational considerations relating to coordinating multiple provider
responses to a mitigation request.]] responses to a mitigation request.]]
DOTS Client DOTS Servers DOTS Client DOTS Servers
+---+ +---+
------------| S | ------------| S |
/ +---+ / +---+
example.net dots1.example.net
/ /
+---+/ +---+ +---+/ +---+
| c |---------------| S | | c |---------------| S |
+---+\ +---+ +---+\ +---+
example.org dots.example.org
\ \
\ +---+ \ +---+
------------| S | ------------| S |
+---+ +---+
example.com example.xyz example.com dots2.example.net
Figure 6: Multi-Homed DOTS Client Figure 6: Multi-Homed DOTS Client
2.3.1. Gatewayed signaling 2.3.1. Gatewayed signaling
As discussed above in Section 2.2.3, a DOTS gateway is a logical As discussed above in Section 2.2.3, a DOTS gateway is a logical
function chaining signaling sessions through concatenation of a DOTS function chaining signaling sessions through concatenation of a DOTS
server and DOTS client. server and DOTS client.
An example scenario, as shown in Figure 7 and Figure 8 below, is for An example scenario, as shown in Figure 7 and Figure 8 below, is for
skipping to change at page 17, line 9 skipping to change at page 17, line 9
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 data channel as messages with the DOTS server over both signal and data channel as
soon as possible to confirm that both channels are operational. soon as possible to confirm that both channels are operational.
As described in [I-D.ietf-dots-requirements], the DOTS client can
configure preferred values for acceptable signal loss, mitigation
lifetime, and heartbeat intervals when establishing the signaling
session. A signaling session is not active until DOTS agents have
agreed on the values for these signaling session parameters, a
process defined by the protocol.
Once the DOTS client begins receiving DOTS server signals, the Once the DOTS client begins receiving DOTS server signals, the
signaling session is active. At any time during the signaling signaling session is active. At any time during the signaling
session, the DOTS client MAY use the data channel to adjust initial session, the DOTS client MAY use the data channel to adjust initial
configuration, manage black- and white-listed prefixes or addresses, configuration, manage black- and white-listed prefixes or addresses,
leverage vendor-specific extensions, and so on. Note that unlike the leverage vendor-specific extensions, and so on. Note that unlike the
signal channel, there is no requirement that the data channel remain signal channel, there is no requirement that the data channel remain
operational in attack conditions (See Data Channel Requirements, operational in attack conditions (See Data Channel Requirements,
[I-D.ietf-dots-requirements]). [I-D.ietf-dots-requirements]).
3.1.3. Maintaining the Signaling Session 3.1.3. Maintaining the Signaling Session
skipping to change at page 21, line 23 skipping to change at page 21, line 28
requirements ([I-D.ietf-dots-requirements]). Service or business requirements ([I-D.ietf-dots-requirements]). Service or business
agreements between recursing domains are not in scope for this agreements between recursing domains are not in scope for this
document. document.
[[EDITOR'S NOTE: Recursive signaling raises questions about [[EDITOR'S NOTE: Recursive signaling raises questions about
operational and data privacy, as well as what level of visibility a operational and data privacy, as well as what level of visibility a
client has into the recursed mitigation. We ask the working group client has into the recursed mitigation. We ask the working group
for feedback and additional discussion of these issues to help settle for feedback and additional discussion of these issues to help settle
the way forward.]] the way forward.]]
3.2.4. Anycast Signaling
The DOTS architecture does not assume the availability of anycast
within a DOTS deployment, but neither does the architecture exclude
it. Domains operating DOTS servers MAY deploy DOTS servers with an
anycast Service Address as described in BCP 126 [RFC4786]. In such a
deployment, DOTS clients connecting to the DOTS Service Address may
be communicating with distinct DOTS servers, depending on the network
configuration at the time the DOTS clients connect. Among other
benefits, anycasted signaling potentially offers the following:
o Simplified DOTS client configuration, including service discovery
through the methods described in [RFC7094]. In this scenario, the
"instance discovery" message would be a DOTS client initiating a
signaling session to the DOTS server anycast Service Address, to
which the DOTS server would reply with a redirection to the DOTS
server unicast address the client should use for DOTS.
o Region- or customer-specific deployments, in which the DOTS
Service Addresses route to distinct DOTS servers depending on the
client region or the customer network in which a DOTS client
resides.
o Operational resiliency, spreading DOTS signaling traffic across
the DOTS server domain's networks, and thereby also reducing the
potential attack surface, as described in BCP 126 [RFC4786].
3.2.4.1. Anycast Signaling Considerations
As long as network configuration remains stable, anycast DOTS
signaling is to the individual DOTS client indistinct from direct
signaling. However, the operational challenges inherent in anycast
signaling are anything but negligible, and DOTS server operators must
carefully weigh the risks against the benefits before deploying.
While the DOTS signal channel primarily operates over UDP per
[I-D.ietf-dots-requirements], the signal channel also requires mutual
authentication between DOTS agents, with associated security state on
both ends. The resulting considerations therefore superficially
resemble the deployment of anycast DNS over DTLS, as described in
[I-D.ietf-dprive-dnsodtls], but the similiarities only go so far.
Network instability is of particular concern with anycast signaling,
as DOTS signaling sessions are expected to be long-lived, and
potentially operating under congested network conditions caused by a
volumetric DDoS attack.
For example, a network configuration altering the route to the DOTS
server during active anycast signaling may cause the DOTS client to
send messages to a DOTS server other than the one with which it
initially established a signaling session. That second DOTS server
may not have the security state of the existing session, forcing the
DOTS client to initialize a new signaling session. This challenge
may in part be mitigated by use of pre-shared keys, as described in
[I-D.ietf-tls-tls13], but keying material must be available to all
DOTS servers sharing the anycast Service Address in that case.
While the DOTS client will try to establish a new signaling session
with the DOTS server now acting as the anycast DOTS Service Address,
the link between DOTS client and server may be congested with attack
traffic, making signal session establishment difficult. In such a
scenario, anycast Service Address instability becomes a sort of
signal session flapping, with obvious negative consequences for the
DOTS deployment.
Anycast signaling deployments similarly must also take into account
active mitigations. Active mitigations initiated through a signaling
session may involve diverting traffic to a scrubbing center. If the
signaling session flaps due to anycast changes as described above,
mitigation may also flap as the DOTS servers sharing the anycast DOTS
service address toggles mitigation on detecting signaling session
loss, depending on whether the client has configured mitigation on
loss of signal.
[[EDITOR'S NOTE: We request feedback from the working group regarding
the complexities inherent in an anycast DOTS deployment. Outside of
using anycast for service discovery, significant challenges need to
be overcome, particularly when dealing with security and mitigation
state, and the resulting operational complexity may outweigh the
expected benefits.]]
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 22, line 42 skipping to change at page 24, line 33
o Notice of an attack delivered via e-mail or alternative messaging o Notice of an attack delivered via e-mail or alternative messaging
o Notice of an attack delivered via phone call o Notice of an attack delivered via phone call
o Notice of an attack delivered through the interface(s) of o Notice of an attack delivered through the interface(s) of
networking monitoring software deployed in the operator's domain networking monitoring software deployed in the operator's domain
o Manual monitoring of network behavior through network monitoring o Manual monitoring of network behavior through network monitoring
software software
3.3.2. Automated Threshold-Based Mitigation Request 3.3.2. Automated Conditional Mitigation Request
Unlike manual mitigation requests, which depend entirely on the DOTS Unlike manual mitigation requests, which depend entirely on the DOTS
client operator's capacity to react with speed and accuracy to every client operator's capacity to react with speed and accuracy to every
detected or detectable attack, mitigation requests triggered by detected or detectable attack, mitigation requests triggered by
detected attack thresholds reduce the operational burden on the DOTS detected attack conditions reduce the operational burden on the DOTS
client operator, and minimize the latency between attack detection client operator, and minimize the latency between attack detection
and the start of mitigation. and the start of mitigation.
Mitigation requests are triggered in this scenario by violations of Mitigation requests are triggered in this scenario by operator-
operator-specified attack thresholds. Attack detection is specified network conditions. Attack detection is deployment-
deployment-specific, and not constrained by this architecture. specific, and not constrained by this architecture. Similarly the
Similarly the specifics of a threshold are left to the discretion of specifics of a condition are left to the discretion of the operator,
the operator, though common threshold types include the following: though common conditions meriting mitigation include the following:
o Detected attack exceeding a rate in packets per second (pps). o Detected attack exceeding a rate in packets per second (pps).
o Detected attack exceeding a rate in bytes per second (bps). o Detected attack exceeding a rate in bytes per second (bps).
o Detected resource exhaustion in an attack target. o Detected resource exhaustion in an attack target.
o Detected resource exhaustion in the local domain's mitigator. o Detected resource exhaustion in the local domain's mitigator.
o Number of open connections to an attack target. o Number of open connections to an attack target.
o Number of attack sources in a given attack. o Number of attack sources in a given attack.
o Number of active attacks against targets in the operator's domain. o Number of active attacks against targets in the operator's domain.
o Thresholds developed through arbitrary statistical analysis or o Conditional detection developed through arbitrary statistical
deep learning techniques. analysis or deep learning techniques.
When automated threshold-based mitigation requests are enabled, o Any combination of the above.
violations of any of the above thresholds, or any additional
operator-defined threshold, will trigger a mitigation request from When automated conditional mitigation requests are enabled,
violations of any of the above conditions, or any additional
operator-defined conditions, will trigger a mitigation request from
the DOTS client to the DOTS server. The interfaces between the the DOTS client to the DOTS server. The interfaces between the
application detecting the threshold violation and the DOTS client are application detecting the condition violation and the DOTS client are
implementation-specific. implementation-specific.
3.3.3. Automated Mitigation on Loss of Signal 3.3.3. Automated Mitigation on Loss of Signal
To maintain a signaling session, the DOTS client and the DOTS server To maintain a signaling session, the DOTS client and the DOTS server
exchange regular but infrequent messages across the signaling exchange regular but infrequent messages across the signaling
channel. In the absence of an attack, the probability of message channel. In the absence of an attack, the probability of message
loss in the signaling channel should be extremely low. Under attack 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. traffic congests the link, depending on the attack type.
skipping to change at page 25, line 23 skipping to change at page 27, line 19
[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,
<http://www.rfc-editor.org/info/rfc2119>. <http://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 T. Reddy, "Distributed
Denial of Service (DDoS) Open Threat Signaling Denial of Service (DDoS) Open Threat Signaling
Requirements", draft-ietf-dots-requirements-01 (work in Requirements", draft-ietf-dots-requirements-02 (work in
progress), March 2016. progress), July 2016.
[I-D.ietf-dots-use-cases] [I-D.ietf-dots-use-cases]
Dobbins, R., Fouant, S., Migault, D., Moskowitz, R., Dobbins, R., Fouant, S., Migault, D., Moskowitz, R.,
Teague, N., and L. Xia, "Use cases for DDoS Open Threat Teague, N., and L. Xia, "Use cases for DDoS Open Threat
Signaling", draft-ietf-dots-use-cases-01 (work in Signaling", draft-ietf-dots-use-cases-01 (work in
progress), March 2016. progress), March 2016.
[I-D.ietf-dprive-dnsodtls]
Reddy, T., Wing, D., and P. Patil, "Specification for DNS
over Datagram Transport Layer Security (DTLS)", draft-
ietf-dprive-dnsodtls-12 (work in progress), September
2016.
[I-D.ietf-tls-tls13]
Rescorla, E., "The Transport Layer Security (TLS) Protocol
Version 1.3", draft-ietf-tls-tls13-18 (work in progress),
October 2016.
[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,
<http://www.rfc-editor.org/info/rfc768>. <http://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,
<http://www.rfc-editor.org/info/rfc793>. <http://www.rfc-editor.org/info/rfc793>.
[RFC1034] Mockapetris, P., "Domain names - concepts and facilities", [RFC1034] Mockapetris, P., "Domain names - concepts and facilities",
STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987, STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987,
skipping to change at page 26, line 21 skipping to change at page 28, line 26
[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,
<http://www.rfc-editor.org/info/rfc4271>. <http://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,
<http://www.rfc-editor.org/info/rfc4732>. <http://www.rfc-editor.org/info/rfc4732>.
[RFC4786] Abley, J. and K. Lindqvist, "Operation of Anycast
Services", BCP 126, RFC 4786, DOI 10.17487/RFC4786,
December 2006, <http://www.rfc-editor.org/info/rfc4786>.
[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,
<http://www.rfc-editor.org/info/rfc6763>. <http://www.rfc-editor.org/info/rfc6763>.
[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,
<http://www.rfc-editor.org/info/rfc7092>. <http://www.rfc-editor.org/info/rfc7092>.
[RFC7094] McPherson, D., Oran, D., Thaler, D., and E. Osterweil,
"Architectural Considerations of IP Anycast", RFC 7094,
DOI 10.17487/RFC7094, January 2014,
<http://www.rfc-editor.org/info/rfc7094>.
Authors' Addresses Authors' Addresses
Andrew Mortensen Andrew Mortensen
Arbor Networks, Inc. Arbor Networks, Inc.
2727 S. State St 2727 S. State St
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 Systems, Inc. Cisco Systems, Inc.
United States United States
EMail: fandreas@cisco.com EMail: fandreas@cisco.com
Tirumaleswar Reddy Tirumaleswar Reddy
Cisco Systems, Inc. Cisco Systems, Inc.
Cessna Business Park, Varthur Hobli Cessna Business Park, Varthur Hobli
Sarjapur Marathalli Outer Ring Road Sarjapur Marathalli Outer Ring Road
Bangalore, Karnataka 560103 Bangalore, Karnataka 560103
India India
EMail: tireddy@cisco.com EMail: tireddy@cisco.com
Christopher Gray Christopher Gray
 End of changes. 25 change blocks. 
39 lines changed or deleted 150 lines changed or added

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