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/