< draft-ietf-dots-requirements-17.txt   draft-ietf-dots-requirements-18.txt >
DOTS A. Mortensen DOTS A. Mortensen
Internet-Draft Arbor Networks Internet-Draft Arbor Networks
Intended status: Informational R. Moskowitz Intended status: Informational T. Reddy
Expires: August 4, 2019 Huawei Expires: August 6, 2019 McAfee
T. Reddy R. Moskowitz
McAfee Huawei
January 31, 2019 February 2, 2019
Distributed Denial of Service (DDoS) Open Threat Signaling Requirements Distributed Denial of Service (DDoS) Open Threat Signaling Requirements
draft-ietf-dots-requirements-17 draft-ietf-dots-requirements-18
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 August 4, 2019. This Internet-Draft will expire on August 6, 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 2, line 34 skipping to change at page 2, line 34
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 18 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 18
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 18 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 18
8.1. Normative References . . . . . . . . . . . . . . . . . . 18 8.1. Normative References . . . . . . . . . . . . . . . . . . 18
8.2. Informative References . . . . . . . . . . . . . . . . . 20 8.2. Informative References . . . . . . . . . . . . . . . . . 20
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21
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
kinds, plaguing network operators at service providers and connected to the Internet, plaguing network operators at service
enterprises around the world. High-volume attacks saturating inbound providers and enterprises around the world. High-volume attacks
links are now common, as attack scale and frequency continue to saturating inbound links are now common, as attack scale and
increase. frequency continue to increase.
The prevalence and impact of these DDoS attacks has led to an The prevalence and impact of these DDoS attacks has led to an
increased focus on coordinated attack response. However, many increased focus on coordinated attack response. However, many
enterprises lack the resources or expertise to operate on-premises enterprises lack the resources or expertise to operate on-premises
attack mitigation solutions themselves, or are constrained by local attack mitigation solutions themselves, or are constrained by local
bandwidth limitations. To address such gaps, service providers have bandwidth limitations. To address such gaps, service providers have
begun to offer on-demand traffic scrubbing services, which are begun to offer on-demand traffic scrubbing services, which are
designed to separate the DDoS attack traffic from legitimate traffic designed to separate the DDoS attack traffic from legitimate traffic
and forward only the latter. and forward only the latter.
Today, these services offer proprietary interfaces for subscribers to Today, these services offer proprietary interfaces for subscribers to
request attack mitigation. Such proprietary interfaces tie a request attack mitigation. Such proprietary interfaces tie a
subscriber to a service while also limiting the network elements subscriber to a service and limit the abilities of network elements
capable of participating in the attack mitigation. As a result of that would otherwise be capable of participating in attack
signaling interface incompatibility, attack responses may be mitigation. As a result of signaling interface incompatibility,
fragmented or otherwise incomplete, leaving operators in the attack attack responses may be fragmented or otherwise incomplete, leaving
path unable to assist in the defense. operators in the attack path unable to assist in the defense.
A standardized method to coordinate a real-time response among A standardized method to coordinate a real-time response among
involved operators will increase the speed and effectiveness of DDoS involved operators will increase the speed and effectiveness of DDoS
attack mitigation, and reduce the impact of these attacks. This attack mitigation, and reduce the impact of these attacks. This
document describes the required characteristics of protocols that document describes the required characteristics of protocols that
enable attack response coordination and mitigation of DDoS attacks. enable attack response coordination and mitigation of DDoS attacks.
DDoS Open Threat Signaling (DOTS) communicates the need for defensive DDoS Open Threat Signaling (DOTS) communicates the need for defensive
action in anticipation of or in response to an attack, but does not action in anticipation of or in response to an attack, but does not
dictate the implementation of these actions. The requirements in dictate the implementation of these actions. The requirements in
skipping to change at page 3, line 37 skipping to change at page 3, line 37
This document adopts the following terms: This document adopts the following terms:
DDoS: A distributed denial-of-service attack, in which traffic DDoS: A distributed denial-of-service attack, in which traffic
originating from multiple sources is directed at a target on a originating from multiple sources is directed at a target on a
network. DDoS attacks are intended to cause a negative impact on network. DDoS attacks are intended to cause a negative impact on
the availability and/or other functionality of an attack target. the availability and/or other functionality of an attack target.
Denial-of-service considerations are discussed in detail in Denial-of-service considerations are discussed in detail in
[RFC4732]. [RFC4732].
DDoS attack target: A network connected entity with a finite set of DDoS attack target: A network connected entity that is the target of
resources, such as network bandwidth, memory or CPU, that is the a DDoS attack. Potential targets include (but are not limited to)
target of a DDoS attack. Potential targets include (but are not network elements, network links, servers, and services.
limited to) network elements, network links, servers, and
services.
DDoS attack telemetry: Collected measurements and behavioral DDoS attack telemetry: Collected measurements and behavioral
characteristics defining the nature of a DDoS attack. characteristics defining the nature of a DDoS attack.
Countermeasure: An action or set of actions focused on recognizing Countermeasure: An action or set of actions focused on recognizing
and filtering out specific types of DDoS attack traffic while and filtering out specific types of DDoS attack traffic while
passing legitimate traffic to the attack target. Distinct passing legitimate traffic to the attack target. Distinct
countermeasures can be layered to defend against attacks combining countermeasures can be layered to defend against attacks combining
multiple DDoS attack types. multiple DDoS attack types.
skipping to change at page 4, line 41 skipping to change at page 4, line 38
DOTS gateway: A DOTS-aware software module resulting from the DOTS gateway: A DOTS-aware software module resulting from the
logical concatenation of the functionality of a DOTS server and a logical concatenation of the functionality of a DOTS server and a
DOTS client into a single DOTS agent. This functionality is DOTS client into a single DOTS agent. This functionality is
analogous to a Session Initiation Protocol (SIP) [RFC3261] Back- analogous to a Session Initiation Protocol (SIP) [RFC3261] Back-
to-Back User Agent (B2BUA) [RFC7092]. A DOTS gateway has a to-Back User Agent (B2BUA) [RFC7092]. A DOTS gateway has a
client-facing side, which behaves as a DOTS server for downstream client-facing side, which behaves as a DOTS server for downstream
clients, and a server-facing side, which performs the role of DOTS clients, and a server-facing side, which performs the role of DOTS
client for upstream DOTS servers. Client-domain DOTS gateways are client for upstream DOTS servers. Client-domain DOTS gateways are
DOTS gateways that are in the DOTS client's domain, while server- DOTS gateways that are in the DOTS client's domain, while server-
domain DOTS gateways denote DOTS gateways that are in the DOTS domain DOTS gateways denote DOTS gateways that are in the DOTS
server's domain. DOTS gateways are described further in server's domain. A DOTS gateway may terminate multiple discrete
DOTS client connections and may aggregate these into a single or
multiple connections. DOTS gateways are described further in
[I-D.ietf-dots-architecture]. [I-D.ietf-dots-architecture].
Signal channel: A bidirectional, mutually authenticated Signal channel: A bidirectional, mutually authenticated
communication channel between DOTS agents that is resilient even communication channel between DOTS agents that is resilient even
in conditions leading to severe packet loss, such as a volumetric in conditions leading to severe packet loss, such as a volumetric
DDoS attack causing network congestion. DDoS attack causing network congestion.
DOTS signal: A concise status/control message transmitted over the DOTS signal: A status/control message transmitted over the
authenticated signal channel between DOTS agents, used to indicate authenticated signal channel between DOTS agents, used to indicate
the client's need for mitigation, or to convey the status of any the client's need for mitigation, or to convey the status of any
requested mitigation. requested mitigation.
Heartbeat: A message transmitted between DOTS agents over the signal Heartbeat: A message transmitted between DOTS agents over the signal
channel, used as a keep-alive and to measure peer health. channel, used as a keep-alive and to measure peer health.
Data channel: A bidirectional, mutually authenticated communication Data channel: A bidirectional, mutually authenticated communication
channel between two DOTS agents used for infrequent but reliable channel between two DOTS agents used for infrequent but reliable
bulk exchange of data not easily or appropriately communicated bulk exchange of data not easily or appropriately communicated
skipping to change at page 5, line 31 skipping to change at page 5, line 31
Accept-list: A list of filters indicating sources from which traffic Accept-list: A list of filters indicating sources from which traffic
should always be allowed, regardless of contradictory data gleaned should always be allowed, regardless of contradictory data gleaned
in a detected attack. in a detected attack.
Multi-homed DOTS client: A DOTS client exchanging messages with Multi-homed DOTS client: A DOTS client exchanging messages with
multiple DOTS servers, each in a separate administrative domain. multiple DOTS servers, each in a separate administrative domain.
2. Requirements 2. Requirements
The expected layout and interactions amongst DOTS entities is
described in the DOTS Architecture [I-D.ietf-dots-architecture].
The goal of the DOTS requirements specification is to specify the The goal of the DOTS requirements specification is to specify the
requirements for DOTS signal channel and data channel protocols that requirements for DOTS signal channel and data channel protocols that
have different application and transport layer requirements. This have different application and transport layer requirements. This
section describes the required features and characteristics of the section describes the required features and characteristics of the
DOTS protocols. DOTS protocols.
The DOTS protocols enable and manage mitigation on behalf of a The goal of DOTS protocols is to enable and manage mitigation on
network domain or resource which is or may become the focus of a DDoS behalf of a network domain or resource which is or may become the
attack. An active DDoS attack against the entity controlling the focus of a DDoS attack. An active DDoS attack against the entity
DOTS client need not be present before establishing a communication controlling the DOTS client need not be present before establishing a
channel between DOTS agents. Indeed, establishing a relationship communication channel between DOTS agents. Indeed, establishing a
with peer DOTS agents during normal network conditions provides the relationship with peer DOTS agents during normal network conditions
foundation for more rapid attack response against future attacks, as provides the foundation for more rapid attack response against future
all interactions setting up DOTS, including any business or service attacks, as all interactions setting up DOTS, including any business
level agreements, are already complete. Reachability information of or service level agreements, are already complete. Reachability
peer DOTS agents is provisioned to a DOTS client using a variety of information of peer DOTS agents is provisioned to a DOTS client using
manual or dynamic methods. Once a relationship between DOTS agents a variety of manual or dynamic methods. Once a relationship between
is established, regular communication between DOTS clients and DOTS agents is established, regular communication between DOTS
servers enables a common understanding of the DOTS agents' health and clients and servers enables a common understanding of the DOTS
activity. agents' health and activity.
The DOTS protocol must at a minimum make it possible for a DOTS The DOTS protocol must at a minimum make it possible for a DOTS
client to request aid mounting a defense against a suspected attack. client to request aid mounting a defense against a suspected attack.
This defense could be coordinated by a DOTS server and include This defense could be coordinated by a DOTS server and include
signaling within or between domains as requested by local operators. signaling within or between domains as requested by local operators.
DOTS clients should similarly be able to withdraw aid requests. DOTS DOTS clients should similarly be able to withdraw aid requests. DOTS
requires no justification from DOTS clients for requests for help, requires no justification from DOTS clients for requests for help,
nor do DOTS clients need to justify withdrawing help requests: the nor do DOTS clients need to justify withdrawing help requests: the
decision is local to the DOTS clients' domain. Multi-homed DOTS decision is local to the DOTS clients' domain. Multi-homed DOTS
clients must be able to select the appropriate DOTS server(s) to clients must be able to select the appropriate DOTS server(s) to
skipping to change at page 6, line 48 skipping to change at page 6, line 50
mitigation-related configuration. 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 proprietary DDoS defenses. Future extensions MUST be backward
be backward compatible. Implementations of older protocol compatible. Implementations of older protocol versions MUST
versions MUST ignore optional information added to DOTS messages ignore optional information added to DOTS messages as part of
as part of newer protocol versions. Implementations of older newer protocol versions. Implementations of older protocol
protocol versions MUST reject mandatory information added to DOTS versions MUST reject mandatory information added to DOTS messages
messages as part of newer protocol versions. as part of newer protocol versions.
GEN-002 Resilience and Robustness: The signaling protocol MUST be GEN-002 Resilience and Robustness: The signaling protocol MUST be
designed to maximize the probability of signal delivery even under designed to maximize the probability of signal delivery even under
the severely constrained network conditions caused by attack the severely constrained network conditions caused by attack
traffic. Additional means to enhance the resilience of DOTS traffic. Additional means to enhance the resilience of DOTS
protocols, including when multiple DOTS servers are provisioned to protocols, including when multiple DOTS servers are provisioned to
the DOTS clients, SHOULD be considered. The protocol MUST be the DOTS clients, SHOULD be considered. The protocol MUST be
resilient, that is, continue operating despite message loss and resilient, that is, continue operating despite message loss and
out-of-order or redundant message delivery. In support of out-of-order or redundant message delivery. In support of
signaling protocol robustness, DOTS signals SHOULD be conveyed signaling protocol robustness, DOTS signals SHOULD be conveyed
skipping to change at page 14, line 41 skipping to change at page 14, line 41
document, but should follow current industry best practices with document, but should follow current industry best practices with
respect to any cryptographic mechanisms to authenticate the remote respect to any cryptographic mechanisms to authenticate the remote
peer. peer.
SEC-002 Message Confidentiality, Integrity and Authenticity: DOTS SEC-002 Message Confidentiality, Integrity and Authenticity: DOTS
protocols MUST take steps to protect the confidentiality, protocols MUST take steps to protect the confidentiality,
integrity and authenticity of messages sent between client and integrity and authenticity of messages sent between client and
server. While specific transport- and message-level security server. While specific transport- and message-level security
options are not specified, the protocols MUST follow current options are not specified, the protocols MUST follow current
industry best practices for encryption and message authentication. industry best practices for encryption and message authentication.
Client-domain DOTS gateways are more trusted than DOTS clients,
while server-domain DOTS gateways and DOTS servers share the same
level of trust. A security mechanism at the network layer (e.g.,
TLS) is thus adequate to provide hop-by-hop security. In other
words, end-to-end security is not required for DOTS protocols.
In order for DOTS protocols to remain secure despite advancements In order for DOTS protocols to remain secure despite advancements
in cryptanalysis and traffic analysis, DOTS agents MUST support in cryptanalysis and traffic analysis, DOTS agents MUST support
secure negotiation of the terms and mechanisms of protocol secure negotiation of the terms and mechanisms of protocol
security, subject to the interoperability and signal message size security, subject to the interoperability and signal message size
requirements in Section 2.2. requirements in Section 2.2.
While the interfaces between downstream DOTS server and upstream While the interfaces between downstream DOTS server and upstream
DOTS client within a DOTS gateway are implementation-specific, DOTS client within a DOTS gateway are implementation-specific,
those interfaces nevertheless MUST provide security equivalent to those interfaces nevertheless MUST provide security equivalent to
skipping to change at page 16, line 9 skipping to change at page 16, line 13
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 provide DM-003 Mitigation Status Representation: The data model MUST 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-008
above, the data model MUST include extensible representation of above, the data model MUST include extensible representation of
mitigation scope. 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 be DM-007 Acceptable Signal Loss Representation: The data model MUST 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. Measurements of
GEN-002. Measurements of loss might include, but are not loss might include, but are not restricted to, number of
restricted to, number of consecutive missed heartbeat messages, consecutive missed heartbeat messages, retransmission count, or
retransmission count, or request timeouts. request timeouts.
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 make
depend on the specifics of any transport to represent fields in any assumptions about specific characteristics of any given
the model. transport into the data model, but instead, represent the fields
in the model explicitly.
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
skipping to change at page 17, line 41 skipping to change at page 17, line 43
request mitigation. request mitigation.
Similarly, an impersonated DOTS server may be able to act as a sort Similarly, an impersonated DOTS server may be able to act as a sort
of malicious DOTS gateway, intercepting requests from the downstream of malicious DOTS gateway, intercepting requests from the downstream
DOTS client, and modifying them before transmission to the DOTS DOTS client, and modifying them before transmission to the DOTS
server to inflict the desired impact on traffic to or from the DOTS server to inflict the desired impact on traffic to or from the DOTS
client's domain. Among other things, this malicious DOTS gateway client's domain. Among other things, this malicious DOTS gateway
might receive and discard mitigation requests from the DOTS client, might receive and discard mitigation requests from the DOTS client,
ensuring no requested mitigation is ever applied. ensuring no requested mitigation is ever applied.
As detailed in Section 2.4, DOTS implementations require mutual To detect misuse, as detailed in Section 2.4, DOTS implementations
authentication of DOTS agents in order to make agent impersonation require mutual authentication of DOTS agents in order to make agent
more difficult. However, impersonation may still be possible as a impersonation more difficult. However, impersonation may still be
result of credential theft, implementation flaws, or compromise of possible as a result of credential theft, implementation flaws, or
DOTS agents. To detect misuse, DOTS operators should carefully compromise of DOTS agents.
monitor and audit DOTS agents, while employing current secure network
communications best practices to reduce attack surface. To detect compromised DOTS agents, DOTS operators should carefully
monitor and audit DOTS agents to detect misbehavior and to deter
misuse, while employing current secure network communications best
practices to reduce attack surface.
Blocking communication between DOTS agents has the potential to Blocking communication between DOTS agents has the potential to
disrupt the core function of DOTS, which is to request mitigation of disrupt the core function of DOTS, which is to request mitigation of
active or expected DDoS attacks. The DOTS signal channel is expected active or expected DDoS attacks. The DOTS signal channel is expected
to operate over congested inbound links, and, as described in to operate over congested inbound links, and, as described in
Section 2.2, the signal channel protocol must be designed for minimal Section 2.2, the signal channel protocol must be designed for minimal
data transfer to reduce the incidence of signal loss. data transfer to reduce the incidence of signal loss.
5. IANA Considerations 5. IANA Considerations
skipping to change at page 18, line 30 skipping to change at page 18, line 37
fandreas@cisco.com fandreas@cisco.com
Dave Dolson Dave Dolson
Sandvine Sandvine
ddolson@sandvine.com ddolson@sandvine.com
7. Acknowledgments 7. Acknowledgments
Thanks to Roman Danyliw, Matt Richardson, Joe Touch, Scott Bradner Thanks to Roman Danyliw, Matt Richardson, Joe Touch, Scott Bradner,
and Jon Shallow for careful reading and feedback. Robert Sparks, Brian Weis, Benjamin Kaduk and Jon Shallow for careful
reading and feedback.
8. References 8. References
8.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,
skipping to change at page 21, line 13 skipping to change at page 21, line 22
<https://www.rfc-editor.org/info/rfc4949>. <https://www.rfc-editor.org/info/rfc4949>.
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
United States United States
Email: amortensen@arbor.net Email: andrewmortensen@gmail.com
Robert Moskowitz
Huawei
Oak Park, MI 42837
United States
Email: rgm@htt-consult.com
Tirumaleswar Reddy Tirumaleswar Reddy
McAfee McAfee
Embassy Golf Link Business Park Embassy Golf Link Business Park
Bangalore, Karnataka 560071 Bangalore, Karnataka 560071
India India
Email: TirumaleswarReddy_Konda@McAfee.com Email: TirumaleswarReddy_Konda@McAfee.com
Robert Moskowitz
Huawei
Oak Park, MI 42837
United States
Email: rgm@htt-consult.com
 End of changes. 19 change blocks. 
69 lines changed or deleted 75 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/