draft-ietf-idr-bgp-open-policy-10.txt		draft-ietf-idr-bgp-open-policy-11.txt
	Network Working Group A. Azimov		Network Working Group A. Azimov
	Internet-Draft E. Bogomazov		Internet-Draft E. Bogomazov
	Intended status: Standards Track Qrator Labs		Intended status: Standards Track Qrator Labs
	Expires: November 16, 2020 R. Bush		Expires: December 18, 2020 R. Bush
	Internet Initiative Japan & Arrcus, Inc.		Internet Initiative Japan & Arrcus, Inc.
	K. Patel		K. Patel
	Arrcus		Arrcus
	K. Sriram		K. Sriram
	USA NIST		USA NIST
	May 15, 2020		June 16, 2020
	Route Leak Prevention using Roles in Update and Open messages		Route Leak Prevention using Roles in Update and Open messages
	draft-ietf-idr-bgp-open-policy-10		draft-ietf-idr-bgp-open-policy-11
	Abstract		Abstract
	Route leaks are the propagation of BGP prefixes which violate		Route leaks are the propagation of BGP prefixes which violate
	assumptions of BGP topology relationships; e.g. passing a route		assumptions of BGP topology relationships; e.g. passing a route
	learned from one peer to another peer or to a transit provider,		learned from one lateral peer to another lateral peer or a transit
	passing a route learned from one transit provider to another transit		provider, passing a route learned from one transit provider to
	provider or to a peer. Today, approaches to leak prevention rely on		another transit provider or a lateral peer. Existing approaches to
	marking routes by operator configuration, with no check that the		leak prevention rely on marking routes by operator configuration,
	configuration corresponds to that of the BGP neighbor, or enforcement		with no check that the configuration corresponds to that of the eBGP
	that the two BGP speakers agree on the relationship. This document		neighbor, or enforcement that the two eBGP speakers agree on the
	enhances BGP OPEN to establish agreement of the (peer, customer,		relationship. This document enhances BGP OPEN to establish agreement
	provider, Route Server, Route Server client) relationship of two		of the (peer, customer, provider, Route Server, Route Server client)
	neighboring BGP speakers to enforce appropriate configuration on both		relationship of two neighboring eBGP speakers to enforce appropriate
	sides. Propagated routes are then marked with an OTC attribute		configuration on both sides. Propagated routes are then marked with
	according to the agreed relationship, allowing both prevention and		an OTC attribute according to the agreed relationship, allowing both
	detection of route leaks.		prevention and detection of route leaks.
	Requirements Language		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		"OPTIONAL" in this document are to be interpreted as described in
	BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all		BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
	capitals, as shown here.		capitals, as shown here.
	Status of This Memo		Status of This Memo
	skipping to change at page 2, line 12 ¶		skipping to change at page 2, line 12 ¶
	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 November 16, 2020.		This Internet-Draft will expire on December 18, 2020.
	Copyright Notice		Copyright Notice
	Copyright (c) 2020 IETF Trust and the persons identified as the		Copyright (c) 2020 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 40 ¶		skipping to change at page 2, line 40 ¶
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
	2. Peering Relationships . . . . . . . . . . . . . . . . . . . . 3		2. Peering Relationships . . . . . . . . . . . . . . . . . . . . 3
	3. BGP Role . . . . . . . . . . . . . . . . . . . . . . . . . . 4		3. BGP Role . . . . . . . . . . . . . . . . . . . . . . . . . . 4
	4. BGP Role Capability . . . . . . . . . . . . . . . . . . . . . 4		4. BGP Role Capability . . . . . . . . . . . . . . . . . . . . . 4
	5. Role correctness . . . . . . . . . . . . . . . . . . . . . . 5		5. Role correctness . . . . . . . . . . . . . . . . . . . . . . 5
	5.1. Strict mode . . . . . . . . . . . . . . . . . . . . . . . 6		5.1. Strict mode . . . . . . . . . . . . . . . . . . . . . . . 6
	6. BGP Only to Customer (OTC) Attribute . . . . . . . . . . . . 6		6. BGP Only to Customer (OTC) Attribute . . . . . . . . . . . . 6
	7. Enforcement . . . . . . . . . . . . . . . . . . . . . . . . . 7		7. Enforcement . . . . . . . . . . . . . . . . . . . . . . . . . 7
	8. Additional Considerations . . . . . . . . . . . . . . . . . . 7		8. Additional Considerations . . . . . . . . . . . . . . . . . . 7
	9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7		9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
	10. Security Considerations . . . . . . . . . . . . . . . . . . . 8		10. Security Considerations . . . . . . . . . . . . . . . . . . . 8
	11. References . . . . . . . . . . . . . . . . . . . . . . . . . 8		11. References . . . . . . . . . . . . . . . . . . . . . . . . . 8
	11.1. Normative References . . . . . . . . . . . . . . . . . . 8		11.1. Normative References . . . . . . . . . . . . . . . . . . 8
	11.2. Informative References . . . . . . . . . . . . . . . . . 9		11.2. Informative References . . . . . . . . . . . . . . . . . 9
	Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 10		Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 10
	Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 10		Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 10
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10
	1. Introduction		1. Introduction
	A BGP route leak occurs when a route is learned from a transit		A BGP route leak occurs when a route is learned from a transit
	provider or peer and then announced to another provider or peer. See		provider or lateral peer and then announced to another provider or
	[RFC7908]. These are usually the result of misconfigured or absent		lateral peer. See [RFC7908]. These are usually the result of
	BGP route filtering or lack of coordination between two BGP speakers.		misconfigured or absent BGP route filtering or lack of coordination
			between two eBGP speakers.
	The mechanism proposed in		The mechanism proposed in
	[I-D.ietf-grow-route-leak-detection-mitigation] uses large-		[I-D.ietf-grow-route-leak-detection-mitigation] uses large-
	communities to perform detection and mitigation of route leaks.		communities to perform detection and mitigation of route leaks.
	While signaling using communities is easy to implement and deploy		While signaling using communities is easy to implement and deploy
	quickly, it normally relies on operator-maintained policy		quickly, it normally relies on operator-maintained policy
	configuration, which is often vulnerable to misconfiguration and even		configuration, which is often vulnerable to misconfiguration and even
	attack [Streibelt]. There is also the vulnerability that the		attack [Streibelt]. There is also the vulnerability that the
	community signal may be stripped, accidentally or maliciously.		community signal may be stripped, accidentally or maliciously.
	This document provides configuration automation using 'BGP roles',		This document provides configuration automation using 'BGP roles',
	which are negotiated using a new BGP Capability Code in OPEN message		which are negotiated using a new BGP Capability Code in OPEN message
	(see Section 4 in [RFC5492]). Either or both BGP speakers MAY be		(see Section 4 in [RFC5492]). Either or both BGP speakers MAY be
	configured to require that this capability be agreed for the BGP OPEN		configured to require that this capability be agreed for the BGP OPEN
	to succeed.		to succeed.
	A new BGP Path Attribute is specified that SHOULD be automatically		A new BGP Path Attribute is specified that SHOULD be automatically
	configured using BGP roles. This attribute prevents networks from		configured using BGP roles. This attribute prevents networks from
	creating leaks, and detects leaks created by third parties.		creating leaks, and detects leaks created by third parties.
			In the rest of this document, we use the term "peer" to refer to
			"lateral peer" for simplicity.
	2. Peering Relationships		2. Peering Relationships
	Despite the use of terms such as "customer", "peer", etc. in this		Despite the use of terms such as "customer", "peer", etc. in this
	document, these are not necessarily business relationships based on		document, these are not necessarily business relationships based on
	payment agreements. These terms are used to represent restrictions		payment agreements. These terms are used to represent restrictions
	on BGP route propagation, sometimes known as the Gao-Rexford model		on BGP route propagation, sometimes known as the Gao-Rexford model
	[Gao]. The following is a list of various roles in BGP peering and		[Gao]. The following is a list of various roles in eBGP peering and
	the corresponding rules for route propagation:		the corresponding rules for route propagation:
	Provider: MAY send to a customer all available prefixes.		Provider: MAY send to a customer all available prefixes.
	Customer: MAY send to a provider their own prefixes and prefixes		Customer: MAY send to a provider prefixes which the sender
	learned from any of their customers. A customer MUST NOT send to		originates and prefixes learned from any of their customers. A
	a provider prefixes learned from its peers, from other providers,		customer MUST NOT send to a provider prefixes learned from its
	or from Route Servers.		peers, from other providers, or from Route Servers.
	Route Server (RS): MAY send to an Route Server client (RS-client)		Route Server (RS): MAY send to an Route Server client (RS-client)
	all available prefixes.		all available prefixes.
	RS-client: MAY send to an RS its own prefixes and prefixes learned		RS-client: MAY send to an RS prefixes which the sender originates
	from its customers. An RS-client MUST NOT send to an RS prefixes		and prefixes learned from its customers. An RS-client MUST NOT
	learned from its peers or providers, or from another RS.		send to an RS prefixes learned from its peers or providers, or
			from another RS.
	Peer: MAY send to a peer its own prefixes and prefixes learned from		Peer: MAY send to a peer prefixes which the sender originates and
	its customers. A peer MUST NOT send to a peer prefixes learned		prefixes learned from its customers. A peer MUST NOT send to a
	from other peers, from its providers, or from RS(s).		peer prefixes learned from other peers, from its providers, or
			from RS(s).
	Of course, any BGP speaker may apply policy to reduce what is		Of course, any BGP speaker may apply policy to reduce what is
	announced, and a recipient may apply policy to reduce the set of		announced, and a recipient may apply policy to reduce the set of
	routes they accept. Violation of the above rules may result in route		routes they accept. Violation of the above rules may result in route
	leaks and MUST not be allowed. Automatic enforcement of these rules		leaks and MUST not be allowed. Automatic enforcement of these rules
	should significantly reduce route leaks that may otherwise occur due		should significantly reduce route leaks that may otherwise occur due
	to manual configuration mistakes. While enforcing the above rules		to manual configuration mistakes. While enforcing the above rules
	will address most BGP peering scenarios, their configuration is not		will address most BGP peering scenarios, their configuration is not
	part of BGP itself; therefore, configuration of ingress and egress		part of BGP itself; therefore, configuration of ingress and egress
	prefix filters is still strongly advised.		prefix filters is still strongly advised.
	3. BGP Role		3. BGP Role
	BGP Role is new configuration option that SHOULD be configured on		BGP Role is a new configuration option that SHOULD be configured on
	each BGP session. It reflects the real-world agreement between two		each eBGP session between ISPs that carry IPv4 and(or) IPv6 unicast
	BGP speakers about their relationship.		prefixes. It reflects the real-world agreement between two BGP
			speakers about their relationship.
	Allowed Role values for eBGP sessions are:		Allowed Role values for eBGP sessions between ISPs are:
	o Provider - sender is a transit provider to neighbor;		o Provider - sender is a transit provider to neighbor;
	o Customer - sender is a transit customer of neighbor;		o Customer - sender is a transit customer of neighbor;
	o RS - sender is a Route Server, usually at an Internet exchange		o RS - sender is a Route Server, usually at an Internet exchange
	point (IX);		point (IX);
	o RS-client - sender is client of an RS;		o RS-client - sender is client of an RS;
	o Peer - sender and neighbor are peers.		o Peer - sender and neighbor are peers.
	Since BGP Role reflects the relationship between two BGP speakers, it		Since BGP Role reflects the relationship between two BGP speakers, it
	could also be used for other purposes besides route leak mitigation.		could also be used for other purposes besides route leak mitigation.
	4. BGP Role Capability		4. BGP Role Capability
	The TLV (type, length, value) of the BGP Role capability are:		The TLV (type, length, value) of the BGP Role capability are:
	o Type - <TBD1>;		o Type - <TBD1>;
			o Length - 1 (byte);
	o Length - 1 (octet);		o Value - integer corresponding to speaker's BGP Role (see Table 1).
	o Value - integer corresponding to speaker's BGP Role.
	+-------+---------------------+		+-------+---------------------+
	| Value | Role name |		| Value | Role name |
	+-------+---------------------+		+-------+---------------------+
	| 0 | Sender is Provider |		| 0 | Sender is Provider |
	| 1 | Sender is RS |		| 1 | Sender is RS |
	| 2 | Sender is RS-client |		| 2 | Sender is RS-client |
	| 3 | Sender is Customer |		| 3 | Sender is Customer |
	| 4 | Sender is Peer |		| 4 | Sender is Peer |
	+-------+---------------------+		+-------+---------------------+
	Table 1: Predefined BGP Role Values		Table 1: Predefined BGP Role Values
	5. Role correctness		5. Role correctness
	Section 3 described how BGP Role encodes the relationship between two		Section 3 described how BGP Role encodes the relationship between two
	BGP speakers. But the mere presence of BGP Role doesn't		eBGP speakers. But the mere presence of BGP Role doesn't
	automatically guarantee role agreement between two BGP peers.		automatically guarantee role agreement between two BGP peers.
	To enforce correctness, the BGP Role check is applied with a set of		To enforce correctness, the BGP Role check is applied with a set of
	constraints on how speakers' BGP Roles MUST correspond. Of course,		constraints on how speakers' BGP Roles MUST correspond. Of course,
	each speaker MUST announce and accept the BGP Role capability in the		each speaker MUST announce and accept the BGP Role capability in the
	BGP OPEN message exchange.		BGP OPEN message exchange.
	If a speaker receives a BGP Role capability, it MUST check the value		If a speaker receives a BGP Role capability, it MUST check the value
	of the received capability (i.e., the sender's role) with its own BGP		of the received capability (i.e., the sender's role) with its own BGP
	Role. The allowed pairings are as follow:		Role. The allowed pairings are as follow:
	skipping to change at page 5, line 44 ¶		skipping to change at page 5, line 47 ¶
	+---------------+-----------------+		+---------------+-----------------+
	| Provider | Customer |		| Provider | Customer |
	| Customer | Provider |		| Customer | Provider |
	| RS | RS-client |		| RS | RS-client |
	| RS-client | RS |		| RS-client | RS |
	| Peer | Peer |		| Peer | Peer |
	+---------------+-----------------+		+---------------+-----------------+
	Table 2: Allowed Pairs of Role Capabilities		Table 2: Allowed Pairs of Role Capabilities
	If the observed Role pair is not in the above table, then the		If the role of the receiving speaker for the eBGP session in
	receiving speaker MUST reject the BGP connection, send a Role		consideration is included in Table 1 and the observed Role pair is
	Mismatch Notification (code 2, subcode <TBD2>), and also send a		not in the above table, then the receiving speaker MUST reject the
	Connection Rejected Notification [RFC4486] (Notification with error		eBGP connection, send a Role Mismatch Notification (code 2, subcode
	code 6, subcode 5).		<TBD2>), and also send a Connection Rejected Notification [RFC4486]
			(Notification with error code 6, subcode 5).
	5.1. Strict mode		5.1. Strict mode
	A new BGP configuration option "strict mode" is defined with values		A new BGP configuration option "strict mode" is defined with values
	of true or false. If set to true, then the speaker MUST refuse to		of true or false. If set to true, then the speaker MUST refuse to
	establish a BGP session with a neighbor which does not announce the		establish a BGP session with a neighbor which does not announce the
	BGP Role capability in the OPEN message. If a speaker rejects a		BGP Role capability in the OPEN message. If a speaker rejects a
	connection, it MUST send a Connection Rejected Notification [RFC4486]		connection, it MUST send a Connection Rejected Notification [RFC4486]
	(Notification with error code 6, subcode 5). By default, strict mode		(Notification with error code 6, subcode 5). By default, strict mode
	SHOULD be set to false for backward compatibility with BGP speakers		SHOULD be set to false for backward compatibility with BGP speakers
	skipping to change at page 7, line 36 ¶		skipping to change at page 7, line 36 ¶
	peerings can segregate the 'complex' parts of the relationship, the		peerings can segregate the 'complex' parts of the relationship, the
	complex peering roles can be segregated into different normal BGP		complex peering roles can be segregated into different normal BGP
	sessions, and BGP Roles MUST be used on each of the resulting normal		sessions, and BGP Roles MUST be used on each of the resulting normal
	(non-complex) BGP sessions.		(non-complex) BGP sessions.
	No Roles SHOULD be configured on a 'complex' BGP session (assuming it		No Roles SHOULD be configured on a 'complex' BGP session (assuming it
	is not segregated) and in that case, OTC MUST be set by configuration		is not segregated) and in that case, OTC MUST be set by configuration
	on a per-prefix basis. However, there are no built-in measures to		on a per-prefix basis. However, there are no built-in measures to
	check correctness of OTC use if BGP Role is not configured.		check correctness of OTC use if BGP Role is not configured.
			The incorrect setting of BGP Roles and/or OTC attributes may affect
			prefix propagation. Further, this document doesn't specify any
			special handling of incorrect/private ASNs in OTC attribute; such
			errors should not happen with proper configuration.
	As the BGP Role reflects the peering relationship between neighbors,		As the BGP Role reflects the peering relationship between neighbors,
	it might have other uses beyond the route leak solution discussed so		it might have other uses beyond the route leak solution discussed so
	far. For example, BGP Role might affect route priority, or be used		far. For example, BGP Role might affect route priority, or be used
	to distinguish borders of a network if a network consists of multiple		to distinguish borders of a network if a network consists of multiple
	ASs. Though such uses may be worthwhile, they are not the goal of		ASs. Though such uses may be worthwhile, they are not the goal of
	this document. Note that such uses would require local policy		this document. Note that such uses would require local policy
	control.		control.
			The use of BGP Roles are specified for unicast IPv4 and IPv6 address
			families. While BGP roles can be configured on other address
			families its applicability for these cases is out of scope of this
			document.
	As BGP role configuration results in automatic creation of inbound/		As BGP role configuration results in automatic creation of inbound/
	outbound filters, existence of roles should be treated as existence		outbound filters, existence of roles should be treated as existence
	of Import and Export policy [RFC8212].		of Import and Export policy [RFC8212].
	9. IANA Considerations		9. IANA Considerations
	This document defines a new Capability Codes option [to be removed		This document defines a new Capability Codes option [to be removed
	upon publication: https://www.iana.org/assignments/capability-codes/		upon publication: https://www.iana.org/assignments/capability-codes/
	capability-codes.xhtml ] [RFC5492], named "BGP Role" with an assigned		capability-codes.xhtml ] [RFC5492], named "BGP Role" with an assigned
	value <TBD1>. The length of this capability is 1.		value <TBD1>. The length of this capability is 1.
	The BGP Role capability includes a Value field, for which IANA is		The BGP Role capability includes a Value field, for which IANA is
	requested to create and maintain a new sub-registry called "BGP Role		requested to create and maintain a new sub-registry called "BGP Role
	Value". Assignments consist of Value and corresponding Role name.		Value". Assignments consist of Value and corresponding Role name.
	Initially this registry is to be populated with the data in Table 1.		Initially this registry is to be populated with the data in Table 1.
	Future assignments may be made by a standard action procedure		Future assignments may be made by a standard action procedure
	[RFC5226].		[RFC5226]. The allocation policy for new entries up to and including
			value 127 is "Expert Review" [RFC5226]. The allocation policy for
			values 128 through 251 is "First Come First Served". The values from
			252 through 255 are for "Experimental Use".
	This document defines a new subcode, "Role Mismatch" with an assigned		This document defines a new subcode, "Role Mismatch" with an assigned
	value <TBD2> in the OPEN Message Error subcodes registry [to be		value <TBD2> in the OPEN Message Error subcodes registry [to be
	removed upon publication: http://www.iana.org/assignments/bgp-		removed upon publication: http://www.iana.org/assignments/bgp-
	parameters/bgp-parameters.xhtml#bgp-parameters-6] [RFC4271].		parameters/bgp-parameters.xhtml#bgp-parameters-6] [RFC4271].
	This document defines a new optional, transitive BGP Path Attributes		This document defines a new optional, transitive BGP Path Attributes
	option, named "Only to Customer (OTC)" with an assigned value <TBD3>		option, named "Only to Customer (OTC)" with an assigned value <TBD3>
	[To be removed upon publication: http://www.iana.org/assignments/bgp-		[To be removed upon publication: http://www.iana.org/assignments/bgp-
	parameters/bgp-parameters.xhtml#bgp-parameters-2] [RFC4271]. The		parameters/bgp-parameters.xhtml#bgp-parameters-2] [RFC4271]. The
	skipping to change at page 10, line 8 ¶		skipping to change at page 10, line 20 ¶
	[Streibelt]		[Streibelt]
	Streibelt, F., Lichtblau, F., Beverly, R., Feldmann, A.,		Streibelt, F., Lichtblau, F., Beverly, R., Feldmann, A.,
	Cristel, C., Smaragdakis, G., and R. Bush, "BGP		Cristel, C., Smaragdakis, G., and R. Bush, "BGP
	Communities: Even more Worms in the Routing Can",		Communities: Even more Worms in the Routing Can",
	<https://people.mpi-inf.mpg.de/~fstreibelt/preprint/		<https://people.mpi-inf.mpg.de/~fstreibelt/preprint/
	communities-imc2018.pdf>.		communities-imc2018.pdf>.
	Acknowledgements		Acknowledgements
	The authors wish to thank Andrei Robachevsky, Daniel Ginsburg, Jeff		The authors wish to thank Andrei Robachevsky, Daniel Ginsburg, Jeff
	Haas, Ruediger Volk, Sue Hares, and John Scudder for comments,		Haas, Ruediger Volk, Pavel Lunin, Gyan Mishra, Ignas Bagdonas, Sue
	suggestions, and critique.		Hares, and John Scudder for comments, suggestions, and critique.
	Contributors		Contributors
	Brian Dickson		Brian Dickson
	Independent		Independent
	Email: brian.peter.dickson@gmail.com		Email: brian.peter.dickson@gmail.com
	Doug Montgomery		Doug Montgomery
	USA National Institute of Standards and Technology		USA National Institute of Standards and Technology
	Email: dougm@nist.gov		Email: dougm@nist.gov
End of changes. 22 change blocks.
	47 lines changed or deleted		67 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/