< draft-ietf-dots-multihoming-10.txt		draft-ietf-dots-multihoming-11.txt >
	Network Working Group M. Boucadair		Network Working Group M. Boucadair
	Internet-Draft Orange		Internet-Draft Orange
	Intended status: Informational T. Reddy		Intended status: Informational T. Reddy.K
	Expires: 8 July 2022 McAfee		Expires: 14 August 2022 Akamai
	W. Pan		W. Pan
	Huawei Technologies		Huawei Technologies
	4 January 2022		10 February 2022
	Multi-homing Deployment Considerations for Distributed-Denial-of-Service		Multi-homing Deployment Considerations for Distributed-Denial-of-Service
	Open Threat Signaling (DOTS)		Open Threat Signaling (DOTS)
	draft-ietf-dots-multihoming-10		draft-ietf-dots-multihoming-11
	Abstract		Abstract
	This document discusses multi-homing considerations for Distributed-		This document discusses multi-homing considerations for Distributed-
	Denial-of-Service Open Threat Signaling (DOTS). The goal is to		Denial-of-Service Open Threat Signaling (DOTS). The goal is to
	provide some guidance for DOTS clients and client-domain DOTS		provide some guidance for DOTS clients and client-domain DOTS
	gateways when multihomed.		gateways when multihomed.
	Status of This Memo		Status of This Memo
	skipping to change at page 1, line 37 ¶		skipping to change at page 1, line 37 ¶
	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 8 July 2022.		This Internet-Draft will expire on 14 August 2022.
	Copyright Notice		Copyright Notice
	Copyright (c) 2022 IETF Trust and the persons identified as the		Copyright (c) 2022 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 (https://trustee.ietf.org/		Provisions Relating to IETF Documents (https://trustee.ietf.org/
	license-info) in effect on the date of publication of this document.		license-info) in effect on the date of publication of this document.
	Please review these documents carefully, as they describe your rights		Please review these documents carefully, as they describe your rights
	skipping to change at page 2, line 32 ¶		skipping to change at page 2, line 32 ¶
	ISPs . . . . . . . . . . . . . . . . . . . . . . . . . . 6		ISPs . . . . . . . . . . . . . . . . . . . . . . . . . . 6
	4.3. Multi-homed Enterprise: Multiple CPEs, Multiple Upstream		4.3. Multi-homed Enterprise: Multiple CPEs, Multiple Upstream
	ISPs . . . . . . . . . . . . . . . . . . . . . . . . . . 7		ISPs . . . . . . . . . . . . . . . . . . . . . . . . . . 7
	4.4. Multi-homed Enterprise with the Same ISP . . . . . . . . 7		4.4. Multi-homed Enterprise with the Same ISP . . . . . . . . 7
	5. DOTS Multi-homing Deployment Considerations . . . . . . . . . 8		5. DOTS Multi-homing Deployment Considerations . . . . . . . . . 8
	5.1. Residential CPE . . . . . . . . . . . . . . . . . . . . . 8		5.1. Residential CPE . . . . . . . . . . . . . . . . . . . . . 8
	5.2. Multi-Homed Enterprise: Single CPE, Multiple Upstream		5.2. Multi-Homed Enterprise: Single CPE, Multiple Upstream
	ISPs . . . . . . . . . . . . . . . . . . . . . . . . . . 10		ISPs . . . . . . . . . . . . . . . . . . . . . . . . . . 10
	5.3. Multi-Homed Enterprise: Multiple CPEs, Multiple Upstream		5.3. Multi-Homed Enterprise: Multiple CPEs, Multiple Upstream
	ISPs . . . . . . . . . . . . . . . . . . . . . . . . . . 12		ISPs . . . . . . . . . . . . . . . . . . . . . . . . . . 12
	5.4. Multi-Homed Enterprise: Single ISP . . . . . . . . . . . 13		5.4. Multi-Homed Enterprise: Single ISP . . . . . . . . . . . 14
	6. Security Considerations . . . . . . . . . . . . . . . . . . . 13		6. Security Considerations . . . . . . . . . . . . . . . . . . . 14
	7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14		7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
	8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14		8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14
	9. References . . . . . . . . . . . . . . . . . . . . . . . . . 14		9. References . . . . . . . . . . . . . . . . . . . . . . . . . 15
	9.1. Normative References . . . . . . . . . . . . . . . . . . 14		9.1. Normative References . . . . . . . . . . . . . . . . . . 15
	9.2. Informative References . . . . . . . . . . . . . . . . . 14		9.2. Informative References . . . . . . . . . . . . . . . . . 15
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16
	1. Introduction		1. Introduction
	In many deployments, it may not be possible for a network to		In many deployments, it may not be possible for a network to
	determine the cause of a distributed Denial-of-Service (DoS) attack		determine the cause of a distributed Denial-of-Service (DoS) attack
	[RFC4732]. Rather, the network may just realize that some resources		[RFC4732]. Rather, the network may just realize that some resources
	appear to be under attack. To help with such situations, the IETF		appear to be under attack. To help with such situations, the IETF
	has specified the DDoS Open Threat Signaling (DOTS) architecture		has specified the DDoS Open Threat Signaling (DOTS) architecture
	[RFC8811], where a DOTS client can inform an upstream DOTS server		[RFC8811], where a DOTS client can inform an upstream DOTS server
	skipping to change at page 4, line 29 ¶		skipping to change at page 4, line 29 ¶
	- One vs. multiple interconnect routers		- One vs. multiple interconnect routers
	- Provider-Independent (PI) vs. Provider-Aggregatable (PA) IP		- Provider-Independent (PI) vs. Provider-Aggregatable (PA) IP
	addresses		addresses
	* Describe the recommended behavior of DOTS clients and client-		* Describe the recommended behavior of DOTS clients and client-
	domain DOTS gateways for each case.		domain DOTS gateways for each case.
	Multi-homed DOTS agents are assumed to make use of the protocols		Multi-homed DOTS agents are assumed to make use of the protocols
	defined in [RFC9132] and [RFC8783]; no specific extension is required		defined in [RFC9132] and [RFC8783]. This document does not require
	to the base DOTS protocols for deploying DOTS in a multi-homed		any specific extension to the base DOTS protocols for deploying DOTS
	context.		in a multi-homed context.
	2. Requirements Language		2. Requirements Language
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and		"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
	"OPTIONAL" in this document are to be interpreted as described in BCP		"OPTIONAL" in this document are to be interpreted as described in BCP
	14 [RFC2119][RFC8174] when, and only when, they appear in all		14 [RFC2119][RFC8174] when, and only when, they appear in all
	capitals, as shown here.		capitals, as shown here.
	3. Terminology		3. Terminology
	skipping to change at page 7, line 16 ¶		skipping to change at page 7, line 16 ¶
	IP addresses/prefixes to the enterprise network.		IP addresses/prefixes to the enterprise network.
	+------+ +------+		+------+ +------+
	| ISP1 | | ISP2 |		| ISP1 | | ISP2 |
	+---+--+ +--+---+		+---+--+ +--+---+
	| | Service Providers		| | Service Providers
	............|....................|.......................		............|....................|.......................
	+---------++---------+ Enterprise Network		+---------++---------+ Enterprise Network
	||		||
	+--++-+		+--++-+
	| rtr |		| CPE |
	+-----+		+-----+
	... (Internal Network)		... (Internal Network)
	Figure 3: Multi-homed Enterprise Network (Single CPE connected to		Figure 3: Multi-homed Enterprise Network (Single CPE connected to
	Multiple Networks)		Multiple Networks)
	4.3. Multi-homed Enterprise: Multiple CPEs, Multiple Upstream ISPs		4.3. Multi-homed Enterprise: Multiple CPEs, Multiple Upstream ISPs
	This scenario is similar to the one described in Section 4.2; the		This scenario is similar to the one described in Section 4.2; the
	main difference is that dedicated routers are used to connect to each		main difference is that dedicated routers (rtr1 and rtr2) are used to
	provisioning domain.		connect to each provisioning domain.
	+------+ +------+		+------+ +------+
	| ISP1 | | ISP2 |		| ISP1 | | ISP2 |
	+---+--+ +--+---+		+---+--+ +--+---+
	| | Service Providers		| | Service Providers
	......................|..........|.......................		......................|..........|.......................
	| | Enterprise Network		| | Enterprise Network
	+---+--+ +--+---+		+---+--+ +--+---+
	| rtr1 | | rtr2 |		| rtr1 | | rtr2 |
	+------+ +------+		+------+ +------+
	skipping to change at page 8, line 37 ¶		skipping to change at page 8, line 37 ¶
	Table 1: Sample Deployment Cases		Table 1: Sample Deployment Cases
	These deployment schemes are further discussed in the following		These deployment schemes are further discussed in the following
	subsections.		subsections.
	5.1. Residential CPE		5.1. Residential CPE
	Figure 5 depicts DOTS sessions that need to be established between a		Figure 5 depicts DOTS sessions that need to be established between a
	DOTS client (C) and two DOTS servers (S1, S2) within the context of		DOTS client (C) and two DOTS servers (S1, S2) within the context of
	the scenario described in Section 4.1.		the scenario described in Section 4.1. As listed in Table 1, the
			DOTS client is hosted by the residential CPE.
	For each provisioning domain, the DOTS client MUST resolve the DOTS		The DOTS client MUST resolve the DOTS server's name provided by each
	server's name provided by a provisioning domain [RFC8973] using the		provisioning domain using either the DNS servers learned from the
	DNS servers learned from the respective provisioning domain (or the		respective provisioning domain or from the DNS servers associated
	DNS servers associated with the interface(s) for which a DOTS server		with the interface(s) for which a DOTS server was explicitly
	was explicitly configured). IPv6-capable DOTS clients MUST use the		configured (Section 4). IPv6-capable DOTS clients MUST use the
	source address selection algorithm defined in [RFC6724] to select the		source address selection algorithm defined in [RFC6724] to select the
	candidate source addresses to contact each of these DOTS servers.		candidate source addresses to contact each of these DOTS servers.
	DOTS sessions MUST be established and MUST be maintained with each of		DOTS sessions MUST be established and MUST be maintained with each of
	the DOTS servers because the mitigation scope of each of these		the DOTS servers because the mitigation scope of each of these
	servers is restricted. The DOTS client SHOULD use the certificate		servers is restricted. The DOTS client SHOULD use the certificate
	provisioned by a provisioning domain to authenticate itself to the		provided by a provisioning domain to authenticate itself to the DOTS
	DOTS server(s) provided by the same provisioning domain.		server(s) provided by the same provisioning domain. How such a
			certificate is provided to the DOTS client is out of the scope of
			this document.
	When conveying a mitigation request to protect the attack target(s),		When conveying a mitigation request to protect the attack target(s),
	the DOTS client MUST select an available DOTS server whose network		the DOTS client MUST select an available DOTS server whose network
	has assigned the IP prefixes from which target prefixes/addresses are		has assigned the IP prefixes from which target prefixes/addresses are
	derived. This implies that if no appropriate DOTS server is found,		derived. This implies that if no appropriate DOTS server is found,
	the DOTS client MUST NOT send the mitigation request to any other		the DOTS client MUST NOT send the mitigation request to any other
	available DOTS server.		available DOTS server.
	For example, a mitigation request to protect target resources bound		For example, a mitigation request to protect target resources bound
	to a PA IP address/prefix cannot be satisfied by a provisioning		to a PA IP address/prefix cannot be satisfied by a provisioning
	domain other than the one that owns those addresses/prefixes.		domain other than the one that owns those addresses/prefixes.
	Consequently, if a CPE detects a DDoS attack that spreads over all		Consequently, if a CPE detects a DDoS attack that spreads over all
	its network attachments, it MUST contact all DOTS servers for		its network attachments, it MUST contact all DOTS servers for
	mitigation purposes.		mitigation purposes.
	The DOTS client MUST be able to associate a DOTS server with each		The DOTS client MUST be able to associate a DOTS server with each
	provisioning domain. For example, if the DOTS client is provisioned		provisioning domain it serves. For example, if the DOTS client is
	with S1 using DHCP when attaching to a first network and with S2		provisioned with S1 using DHCP when attaching to a first network and
	using Protocol Configuration Option (PCO) [TS.24008] when attaching		with S2 using Protocol Configuration Option (PCO) [TS.24008] when
	to a second network, the DOTS client must record the interface from		attaching to a second network, the DOTS client must record the
	which a DOTS server was provisioned. DOTS signaling session to a		interface from which a DOTS server was provisioned. DOTS signaling
	given DOTS server must be established using the interface from which		session to a given DOTS server must be established using the
	the DOTS server was provisioned. If a DOTS server is explicitly		interface from which the DOTS server was provisioned. If a DOTS
	configured, DOTS signaling with that server must be established via		server is explicitly configured, DOTS signaling with that server must
	the interfaces that are indicated in the explicit configuration or		be established via the interfaces that are indicated in the explicit
	via any active interface if no interface is configured.		configuration or via any active interface if no interface is
			configured.
	+--+		+--+
	----------|S1|		----------|S1|
	/ +--+		/ +--+
	/ DOTS Server Domain #1		/ DOTS Server Domain #1
	/		/
	+---+/		+---+/
	| C |		| C |
	+---+\		+---+\
	\		CPE \
	\		\
	\ +--+		\ +--+
	----------|S2|		----------|S2|
	+--+		+--+
	DOTS Server Domain #2		DOTS Server Domain #2
	Figure 5: DOTS Associations for a Multihomed Residential CPE		Figure 5: DOTS Associations for a Multihomed Residential CPE
	5.2. Multi-Homed Enterprise: Single CPE, Multiple Upstream ISPs		5.2. Multi-Homed Enterprise: Single CPE, Multiple Upstream ISPs
	Figure 6 illustrates a first set of DOTS sessions that can be		Figure 6 illustrates the DOTS sessions that can be established with a
	established with a client-domain DOTS gateway, which is enabled		client-domain DOTS gateway (hosted within the CPE as per Table 1),
	within the context of the scenario described in Section 4.2. This		which is enabled within the context of the scenario described in
	deployment is characterized as follows:		Section 4.2. This deployment is characterized as follows:
	* One of more DOTS clients are enabled in hosts located in the		* One of more DOTS clients are enabled in hosts located in the
	internal network.		internal network.
	* A client-domain DOTS gateway is enabled to aggregate and then		* A client-domain DOTS gateway is enabled to aggregate and then
	relay the requests towards upstream DOTS servers.		relay the requests towards upstream DOTS servers.
	+--+		+--+
	----------|S1|		----------|S1|
	+---+ / +--+		+---+ / +--+
	| C1|----+ / DOTS Server Domain #1		| C1|----+ / DOTS Server Domain #1
	+---+ | /		+---+ | /
	+---+ +-+-+/		| /
	| C3|------| G |		+---+ +-+-+/
	+---+ +-+-+\		| C3|------| G |
	+---+ | \		+---+ +-+-+\
	| C2|----+ \		CPE \
	+---+ \ +--+		+---+ | \
			| C2|----+ \
			+---+ \ +--+
	----------|S2|		----------|S2|
	+--+		+--+
	DOTS Server Domain #2		DOTS Server Domain #2
	Figure 6: Multiple DOTS Clients, Single DOTS Gateway, Multiple		Figure 6: Multiple DOTS Clients, Single DOTS Gateway, Multiple
	DOTS Servers		DOTS Servers
	When PA addresses/prefixes are in use, the same considerations		When PA addresses/prefixes are in use, the same considerations
	discussed in Section 5.1 need to be followed by the client-domain		discussed in Section 5.1 need to be followed by the client-domain
	DOTS gateway to contact its DOTS server(s). The client-domain DOTS		DOTS gateway to contact its DOTS server(s). The client-domain DOTS
	gateways can be reachable from DOTS clients by using an unicast		gateways can be reachable from DOTS clients by using an unicast
	address or an anycast address (Section 3.2.4 of [RFC8811]).		address or an anycast address (Section 3.2.4 of [RFC8811]).
	skipping to change at page 11, line 36 ¶		skipping to change at page 12, line 15 ¶
	If PI addresses/prefixes are in use, the DOTS client MUST send a		If PI addresses/prefixes are in use, the DOTS client MUST send a
	mitigation request to all the DOTS servers. The use of anycast		mitigation request to all the DOTS servers. The use of anycast
	addresses to reach these DOTS servers is NOT RECOMMENDED. If a well-		addresses to reach these DOTS servers is NOT RECOMMENDED. If a well-
	known anycast address is used to reach multiple DOTS servers, the CPE		known anycast address is used to reach multiple DOTS servers, the CPE
	may not be able to select the appropriate provisioning domain to		may not be able to select the appropriate provisioning domain to
	which the mitigation request should be forwarded. As a consequence,		which the mitigation request should be forwarded. As a consequence,
	the request may not be forwarded to the appropriate DOTS server.		the request may not be forwarded to the appropriate DOTS server.
	If PA addresses/prefixes are used, the same considerations discussed		If PA addresses/prefixes are used, the same considerations discussed
	in Section 5.1 need to be followed by the DOTS clients. Because DOTS		in Section 5.1 need to be followed by the DOTS clients. Because DOTS
	clients are not embedded in the CPE and multiple addreses/prefixes		clients are not embedded in the CPE and multiple addresses/prefixes
	may not be assigned to the DOTS client (typically in an IPv4		may not be assigned to the DOTS client (typically in an IPv4
	context), some issues may arise in how to steer traffic towards the		context), some issues may arise in how to steer traffic towards the
	appropriate DOTS server by using the appropriate source IP address.		appropriate DOTS server by using the appropriate source IP address.
	These complications discussed in [RFC4116] are not specific to DOTS.		These complications discussed in [RFC4116] are not specific to DOTS.
	Another deployment approach is to enable many DOTS clients; each of		Another deployment approach is to enable many DOTS clients; each of
	them is responsible for handling communications with a specific DOTS		them is responsible for handling communications with a specific DOTS
	server (see Figure 8).		server (see Figure 8).
	..........		..........
	skipping to change at page 12, line 22 ¶		skipping to change at page 12, line 42 ¶
	..........		..........
	DOTS Client		DOTS Client
	Domain		Domain
	Figure 8: Single Homed DOTS Clients		Figure 8: Single Homed DOTS Clients
	For both deployments depicted in Figures 7 and 8, each DOTS client		For both deployments depicted in Figures 7 and 8, each DOTS client
	SHOULD be provided with policies (e.g., a prefix filter that will be		SHOULD be provided with policies (e.g., a prefix filter that will be
	against DDoS detection alarms) that will trigger DOTS communications		against DDoS detection alarms) that will trigger DOTS communications
	with the DOTS servers. Such policies will help the DOTS client to		with the DOTS servers. Such policies will help the DOTS client to
	select the appropriate destination DOTS server.		select the appropriate destination DOTS server. The CPE MUST select
			the appropriate source IP address when forwarding DOTS messages
	The CPE MUST select the appropriate source IP address when forwarding		received from an internal DOTS client.
	DOTS messages received from an internal DOTS client.
	5.3. Multi-Homed Enterprise: Multiple CPEs, Multiple Upstream ISPs		5.3. Multi-Homed Enterprise: Multiple CPEs, Multiple Upstream ISPs
	The deployments depicted in Figures 7 and 8 also apply to the		The deployments depicted in Figures 7 and 8 also apply to the
	scenario described in Section 4.3. One specific problem for this		scenario described in Section 4.3. One specific problem for this
	scenario is to select the appropriate exit router when contacting a		scenario is to select the appropriate exit router when contacting a
	given DOTS server.		given DOTS server.
	An alternative deployment scheme is shown in Figure 9:		An alternative deployment scheme is shown in Figure 9:
	* DOTS clients are enabled in hosts located in the internal network.		* DOTS clients are enabled in hosts located in the internal network.
	* A client-domain DOTS gateway is enabled in each CPE (rtr1, rtr2).		* A client-domain DOTS gateway is enabled in each CPE (rtr1 and rtr2
			per Table 1).
	* Each of these client-domain DOTS gateways communicates with the		* Each of these client-domain DOTS gateways communicates with the
	DOTS server of the provisioning domain.		DOTS server of the provisioning domain.
	+---+		+---+
	+------------| C1|----+		+------------| C1|----+
	| +---+ |		| +---+ |
			| |
	+--+ +-+-+ +---+ +-+-+ +--+		+--+ +-+-+ +---+ +-+-+ +--+
	|S2|------|G2 |------| C3|------|G1 |------|S1|		|S2|------|G2 |------| C3|------|G1 |------|S1|
	+--+ +-+-+ +---+ +-+-+ +--+		+--+ +-+-+ +---+ +-+-+ +--+
			rtr2 rtr1
	| +---+ |		| +---+ |
	+------------| C2|----+		+------------| C2|----+
	+---+		+---+
	Figure 9: Multiple DOTS Clients, Multiple DOTS Gateways, Multiple		Figure 9: Multiple DOTS Clients, Multiple DOTS Gateways, Multiple
	DOTS Servers		DOTS Servers
	When PI addresses/prefixes are used, DOTS clients MUST contact all		When PI addresses/prefixes are used, DOTS clients MUST contact all
	the client-domain DOTS gateways to send a DOTS message. Client-		the client-domain DOTS gateways to send a DOTS message. Client-
	domain DOTS gateways will then relay the request to the DOTS servers		domain DOTS gateways will then relay the request to the DOTS servers
	skipping to change at page 14, line 29 ¶		skipping to change at page 14, line 51 ¶
	8. Acknowledgements		8. Acknowledgements
	Thanks to Roland Dobbins, Nik Teague, Jon Shallow, Dan Wing, and		Thanks to Roland Dobbins, Nik Teague, Jon Shallow, Dan Wing, and
	Christian Jacquenet for sharing their comments on the mailing list.		Christian Jacquenet for sharing their comments on the mailing list.
	Thanks to Kirill Kasavchenko for the comments.		Thanks to Kirill Kasavchenko for the comments.
	Thanks to Kathleen Moriarty for the secdir review and Joel Jaeggli		Thanks to Kathleen Moriarty for the secdir review and Joel Jaeggli
	for the opsdir review.		for the opsdir review.
			Many thanks to Roman Danyliw for the careful AD review.
	9. References		9. References
	9.1. Normative References		9.1. Normative References
	[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate		[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
	Requirement Levels", BCP 14, RFC 2119,		Requirement Levels", BCP 14, RFC 2119,
	DOI 10.17487/RFC2119, March 1997,		DOI 10.17487/RFC2119, March 1997,
	<https://www.rfc-editor.org/info/rfc2119>.		<https://www.rfc-editor.org/info/rfc2119>.
	[RFC6724] Thaler, D., Ed., Draves, R., Matsumoto, A., and T. Chown,		[RFC6724] Thaler, D., Ed., Draves, R., Matsumoto, A., and T. Chown,
	skipping to change at page 16, line 24 ¶		skipping to change at page 16, line 49 ¶
	Authors' Addresses		Authors' Addresses
	Mohamed Boucadair		Mohamed Boucadair
	Orange		Orange
	35000 Rennes		35000 Rennes
	France		France
	Email: mohamed.boucadair@orange.com		Email: mohamed.boucadair@orange.com
	Tirumaleswar Reddy		Tirumaleswar Reddy.K
	McAfee, Inc.		Akamai
	Embassy Golf Link Business Park		Embassy Golf Link Business Park
	Bangalore 560071		Bangalore 560071
	Karnataka		Karnataka
	India		India
	Email: TirumaleswarReddy_Konda@McAfee.com		Email: kondtir@gmail.com
	Wei Pan		Wei Pan
	Huawei Technologies		Huawei Technologies
	Email: william.panwei@huawei.com		Email: william.panwei@huawei.com
End of changes. 25 change blocks.
	58 lines changed or deleted		68 lines changed or added
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/