draft-ietf-v6ops-security-overview-05.txt		draft-ietf-v6ops-security-overview-06.txt
	IPv6 Operations E. Davies		IPv6 Operations E. Davies
	Internet-Draft Consultant		Internet-Draft Consultant
	Intended status: Informational S. Krishnan		Intended status: Informational S. Krishnan
	Expires: March 4, 2007 Ericsson		Expires: April 25, 2007 Ericsson
	P. Savola		P. Savola
	CSC/Funet		CSC/Funet
	August 31, 2006		October 22, 2006
	IPv6 Transition/Co-existence Security Considerations		IPv6 Transition/Co-existence Security Considerations
	draft-ietf-v6ops-security-overview-05.txt		draft-ietf-v6ops-security-overview-06.txt
	Status of this Memo		Status of this Memo
	By submitting this Internet-Draft, each author represents that any		By submitting this Internet-Draft, each author represents that any
	applicable patent or other IPR claims of which he or she is aware		applicable patent or other IPR claims of which he or she is aware
	have been or will be disclosed, and any of which he or she becomes		have been or will be disclosed, and any of which he or she becomes
	aware will be disclosed, in accordance with Section 6 of BCP 79.		aware will be disclosed, in accordance with Section 6 of BCP 79.
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF), its areas, and its working groups. Note that		Task Force (IETF), its areas, and its working groups. Note that
	skipping to change at page 1, line 37		skipping to change at page 1, line 37
	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."
	The list of current Internet-Drafts can be accessed at		The list of current Internet-Drafts can be accessed at
	http://www.ietf.org/ietf/1id-abstracts.txt.		http://www.ietf.org/ietf/1id-abstracts.txt.
	The list of Internet-Draft Shadow Directories can be accessed at		The list of Internet-Draft Shadow Directories can be accessed at
	http://www.ietf.org/shadow.html.		http://www.ietf.org/shadow.html.
	This Internet-Draft will expire on March 4, 2007.		This Internet-Draft will expire on April 25, 2007.
	Copyright Notice		Copyright Notice
	Copyright (C) The Internet Society (2006).		Copyright (C) The Internet Society (2006).
	Abstract		Abstract
	The transition from a pure IPv4 network to a network where IPv4 and		The transition from a pure IPv4 network to a network where IPv4 and
	IPv6 co-exist brings a number of extra security considerations that		IPv6 co-exist brings a number of extra security considerations that
	need to be taken into account when deploying IPv6 and operating the		need to be taken into account when deploying IPv6 and operating the
	skipping to change at page 2, line 21		skipping to change at page 2, line 21
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
	2. Issues Due to IPv6 Protocol . . . . . . . . . . . . . . . . . 4		2. Issues Due to IPv6 Protocol . . . . . . . . . . . . . . . . . 4
	2.1. IPv6 Protocol-specific Issues . . . . . . . . . . . . . . 5		2.1. IPv6 Protocol-specific Issues . . . . . . . . . . . . . . 5
	2.1.1. Routing Headers and Hosts . . . . . . . . . . . . . . 5		2.1.1. Routing Headers and Hosts . . . . . . . . . . . . . . 5
	2.1.2. Routing Headers for Mobile IPv6 and Other Purposes . . 6		2.1.2. Routing Headers for Mobile IPv6 and Other Purposes . . 6
	2.1.3. Site-scope Multicast Addresses . . . . . . . . . . . . 7		2.1.3. Site-scope Multicast Addresses . . . . . . . . . . . . 7
	2.1.4. ICMPv6 and Multicast . . . . . . . . . . . . . . . . . 7		2.1.4. ICMPv6 and Multicast . . . . . . . . . . . . . . . . . 7
	2.1.5. Bogus Errored Packets in ICMPv6 Error Messages . . . . 8		2.1.5. Bogus Errored Packets in ICMPv6 Error Messages . . . . 8
	2.1.6. Anycast Traffic Identification and Security . . . . . 9		2.1.6. Anycast Traffic Identification and Security . . . . . 9
	2.1.7. Address Privacy Extensions Interact with DDoS		2.1.7. Address Privacy Extensions Interact with DDoS
	Defenses . . . . . . . . . . . . . . . . . . . . . . . 9		Defenses . . . . . . . . . . . . . . . . . . . . . . . 10
	2.1.8. Dynamic DNS: Stateless Address Auto-Configuration,		2.1.8. Dynamic DNS: Stateless Address Auto-Configuration,
	Privacy Extensions and SEND . . . . . . . . . . . . . 10		Privacy Extensions and SEND . . . . . . . . . . . . . 10
	2.1.9. Extension Headers . . . . . . . . . . . . . . . . . . 11		2.1.9. Extension Headers . . . . . . . . . . . . . . . . . . 11
	2.1.10. Fragmentation: Reassembly and Deep Packet		2.1.10. Fragmentation: Reassembly and Deep Packet
	Inspection . . . . . . . . . . . . . . . . . . . . . . 14		Inspection . . . . . . . . . . . . . . . . . . . . . . 14
	2.1.11. Fragmentation Related DoS Attacks . . . . . . . . . . 15		2.1.11. Fragmentation Related DoS Attacks . . . . . . . . . . 15
	2.1.12. Link-Local Addresses and Securing Neighbor		2.1.12. Link-Local Addresses and Securing Neighbor
	Discovery . . . . . . . . . . . . . . . . . . . . . . 15		Discovery . . . . . . . . . . . . . . . . . . . . . . 15
	2.1.13. Securing Router Advertisements . . . . . . . . . . . . 17		2.1.13. Securing Router Advertisements . . . . . . . . . . . . 17
	2.1.14. Host to Router Load Sharing . . . . . . . . . . . . . 17		2.1.14. Host to Router Load Sharing . . . . . . . . . . . . . 18
	2.1.15. Mobile IPv6 . . . . . . . . . . . . . . . . . . . . . 18		2.1.15. Mobile IPv6 . . . . . . . . . . . . . . . . . . . . . 18
	2.2. IPv4-mapped IPv6 Addresses . . . . . . . . . . . . . . . . 18		2.2. IPv4-mapped IPv6 Addresses . . . . . . . . . . . . . . . . 18
	2.3. Increased End-to-End Transparency . . . . . . . . . . . . 20		2.3. Increased End-to-End Transparency . . . . . . . . . . . . 20
	2.3.1. IPv6 Networks without NATs . . . . . . . . . . . . . . 20		2.3.1. IPv6 Networks without NATs . . . . . . . . . . . . . . 20
	2.3.2. Enterprise Network Security Model for IPv6 . . . . . . 20		2.3.2. Enterprise Network Security Model for IPv6 . . . . . . 20
	2.4. IPv6 in IPv6 Tunnels . . . . . . . . . . . . . . . . . . . 22		2.4. IPv6 in IPv6 Tunnels . . . . . . . . . . . . . . . . . . . 22
	3. Issues Due to Transition Mechanisms . . . . . . . . . . . . . 22		3. Issues Due to Transition Mechanisms . . . . . . . . . . . . . 22
	3.1. IPv6 Transition/Co-existence Mechanism-specific Issues . . 22		3.1. IPv6 Transition/Co-existence Mechanism-specific Issues . . 22
	3.2. Automatic Tunneling and Relays . . . . . . . . . . . . . . 23		3.2. Automatic Tunneling and Relays . . . . . . . . . . . . . . 23
	3.3. Tunneling IPv6 Through IPv4 Networks May Break IPv4		3.3. Tunneling IPv6 Through IPv4 Networks May Break IPv4
	Network Security Assumptions . . . . . . . . . . . . . . . 23		Network Security Assumptions . . . . . . . . . . . . . . . 24
	4. Issues Due to IPv6 Deployment . . . . . . . . . . . . . . . . 25		4. Issues Due to IPv6 Deployment . . . . . . . . . . . . . . . . 25
	4.1. Avoiding the Trap of Insecure IPv6 Service Piloting . . . 25		4.1. Avoiding the Trap of Insecure IPv6 Service Piloting . . . 25
	4.2. DNS Server Problems . . . . . . . . . . . . . . . . . . . 27		4.2. DNS Server Problems . . . . . . . . . . . . . . . . . . . 27
	4.3. Addressing Schemes and Securing Routers . . . . . . . . . 27		4.3. Addressing Schemes and Securing Routers . . . . . . . . . 27
	4.4. Consequences of Multiple Addresses in IPv6 . . . . . . . . 27		4.4. Consequences of Multiple Addresses in IPv6 . . . . . . . . 27
	4.5. Deploying ICMPv6 . . . . . . . . . . . . . . . . . . . . . 28		4.5. Deploying ICMPv6 . . . . . . . . . . . . . . . . . . . . . 28
	4.5.1. Problems Resulting from ICMPv6 Transparency . . . . . 29		4.5.1. Problems Resulting from ICMPv6 Transparency . . . . . 29
	4.6. IPsec Transport Mode . . . . . . . . . . . . . . . . . . . 29		4.6. IPsec Transport Mode . . . . . . . . . . . . . . . . . . . 29
	4.7. Reduced Functionality Devices . . . . . . . . . . . . . . 30		4.7. Reduced Functionality Devices . . . . . . . . . . . . . . 30
	4.8. Operational Factors when Enabling IPv6 in the Network . . 30		4.8. Operational Factors when Enabling IPv6 in the Network . . 30
	4.9. Ingress Filtering Issues Due to Privacy Addresses . . . . 31		4.9. Security Issues Due to Neighbor Discovery Proxies . . . . 31
	4.10. Security Issues Due to Neighbor Discovery Proxies . . . . 31
	5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 31		5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 31
	6. Security Considerations . . . . . . . . . . . . . . . . . . . 32		6. Security Considerations . . . . . . . . . . . . . . . . . . . 31
	7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 32		7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 31
	8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 32		8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 32
	8.1. Normative References . . . . . . . . . . . . . . . . . . . 32		8.1. Normative References . . . . . . . . . . . . . . . . . . . 32
	8.2. Informative References . . . . . . . . . . . . . . . . . . 33		8.2. Informative References . . . . . . . . . . . . . . . . . . 33
	Appendix A. IPv6 Probing/Mapping Considerations . . . . . . . . . 36		Appendix A. IPv6 Probing/Mapping Considerations . . . . . . . . . 36
	Appendix B. IPv6 Privacy Considerations . . . . . . . . . . . . . 37		Appendix B. IPv6 Privacy Considerations . . . . . . . . . . . . . 37
	B.1. Exposing MAC Addresses . . . . . . . . . . . . . . . . . . 37		B.1. Exposing MAC Addresses . . . . . . . . . . . . . . . . . . 37
	B.2. Exposing Multiple Devices . . . . . . . . . . . . . . . . 38		B.2. Exposing Multiple Devices . . . . . . . . . . . . . . . . 38
	B.3. Exposing the Site by a Stable Prefix . . . . . . . . . . . 38		B.3. Exposing the Site by a Stable Prefix . . . . . . . . . . . 38
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 39		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 39
	Intellectual Property and Copyright Statements . . . . . . . . . . 40		Intellectual Property and Copyright Statements . . . . . . . . . . 40
	skipping to change at page 5, line 49		skipping to change at page 5, line 49
	enabled. The Requirements for Internet Hosts [RFC1122] permits		enabled. The Requirements for Internet Hosts [RFC1122] permits
	implementations to perform "local source routing", that is forwarding		implementations to perform "local source routing", that is forwarding
	a packet with a routing header through the same interface on which it		a packet with a routing header through the same interface on which it
	was received: no restrictions are placed on this operation even on		was received: no restrictions are placed on this operation even on
	hosts. In combination, these rules can result in hosts forwarding		hosts. In combination, these rules can result in hosts forwarding
	received traffic to another node if there are segments left in the		received traffic to another node if there are segments left in the
	Routing Header when it arrives at the host.		Routing Header when it arrives at the host.
	A number of potential security issues associated with this behavior		A number of potential security issues associated with this behavior
	have been identified. Some of these issues have been resolved (a		have been identified. Some of these issues have been resolved (a
	separate routing header (Type 2) is now used for Mobile IPv6		separate routing header (Type 2) has been standardized for Mobile
	[RFC3775] and ICMP Traceback has not been standardized), but two		IPv6 [RFC3775] and ICMP Traceback has not been standardized), but two
	issues remain:		issues remain:
	o Routing headers can be used to evade access controls based on		o Both existing types of routing header can be used to evade access
	destination addresses. This could be achieved by sending a packet		controls based on destination addresses. This could be achieved
	ostensibly to a publicly accessible host address but with a		by sending a packet ostensibly to a publicly accessible host
	routing header containing a 'forbidden' address. If the publicly		address but with a routing header containing a 'forbidden'
	accessible host is processing routing headers it will forward the		address. If the publicly accessible host is processing routing
	packet to the destination address in the routing header that would		headers it will forward the packet to the destination address in
	have been forbidden by the packet filters if the address had been		the routing header that would have been forbidden by the packet
	in the destination field when the packet was checked.		filters if the address had been in the destination field when the
	o If the packet source address in the previous case can be spoofed,		packet was checked.
	any host could be used to mediate an anonymous reflection denial-		o If the packet source address can be spoofed when using a Type 0
	of-service attack by having any publicly accessible host redirect		routing header, the mechanism described in the previous bullet
	the attack packets.		could be used with any host to mediate an anonymous reflection
			denial-of-service attack by having any publicly accessible host
			redirect the attack packets. (This attack cannot use Type 2
			routing headers because the packet cannot be forwarded outside the
			host that processes the routing header, i.e., the original
			destination of the packet.)
	To counteract these threats, if a device is enforcing access controls		To counteract these threats, if a device is enforcing access controls
	based on destination addresses, it needs to examine both the		based on destination addresses, it needs to examine both the
	destination address in the base IPv6 header and any waypoint		destination address in the base IPv6 header and any waypoint
	destinations in a routing header that have not yet been reached by		destinations in a routing header that have not yet been reached by
	the packet at the point where it is being checked.		the packet at the point where it is being checked.
	Various forms of amplification attack on routers and firewalls using		Various forms of amplification attack on routers and firewalls using
	the routing header could be envisaged. A simple form involves		the routing header could be envisaged. A simple form involves
	repeating the address of a waypoint several times in the routing		repeating the address of a waypoint several times in the routing
	header. More complex forms could involve alternating waypoint		header. More complex forms could involve alternating waypoint
	skipping to change at page 10, line 10		skipping to change at page 10, line 17
	The purpose of the privacy extensions for stateless address auto-		The purpose of the privacy extensions for stateless address auto-
	configuration [I-D.ietf-ipv6-privacy-addrs-v2] is to change the		configuration [I-D.ietf-ipv6-privacy-addrs-v2] is to change the
	interface identifier (and hence the global scope addresses generated		interface identifier (and hence the global scope addresses generated
	from it) from time to time. By varying the addresses used,		from it) from time to time. By varying the addresses used,
	eavesdroppers and other information collectors find it more difficult		eavesdroppers and other information collectors find it more difficult
	to identify which transactions actually relate to a specific node.		to identify which transactions actually relate to a specific node.
	A security issue may result from this if the frequency of node		A security issue may result from this if the frequency of node
	address change is sufficiently great to achieve the intended aim of		address change is sufficiently great to achieve the intended aim of
	the privacy extensions: with a relatively high rate of change, the		the privacy extensions: with a relatively high rate of change, the
	observed behavior of the node could look very like that of a		observed behavior has some characteristics of a node or nodes
	compromised node that was the source of a Distributed Denial-of-		involved in a Distributed Denial-of-Service (DDoS) attack. It should
	Service (DDoS) attack. It would thus be difficult for any future		be noted, however, that addresses created in this way are
	defenses against DDoS attacks to distinguish between a high rate of		topologically correct and that the other characteristics of the
	change of addresses resulting from genuine use of the privacy		traffic may reveal that there is no malicious intent.
	extensions and a compromised node being used as the source of a DDoS
	with 'in-prefix' spoofed source addresses as described in
	[I-D.ietf-ipv6-privacy-addrs-v2].
	Even if a node is well behaved, the change in the address could make		This issue can be addressed in most cases by tuning the rate of
	it harder for a security administrator to define a policy rule (e.g.,		change in an appropriate manner.
	access control list) that takes into account a specific node.
			Note that even if a node is well behaved, a change in the address
			could make it harder for a security administrator to define an
			address-based policy rule (e.g., access control list). However,
			nodes that employ privacy addresses do not have to use them for all
			communications.
	2.1.8. Dynamic DNS: Stateless Address Auto-Configuration, Privacy		2.1.8. Dynamic DNS: Stateless Address Auto-Configuration, Privacy
	Extensions and SEND		Extensions and SEND
	The introduction of Stateless Address Auto-Configuration (SLAAC)		The introduction of Stateless Address Auto-Configuration (SLAAC)
	[RFC2462] with IPv6 provides an additional challenge to the security		[RFC2462] with IPv6 provides an additional challenge to the security
	of Dynamic Domain Name System (DDNS). With manual addressing or the		of Dynamic Domain Name System (DDNS). With manual addressing or the
	use of DHCP, the number of security associations that need to be		use of DHCP, the number of security associations that need to be
	maintained to secure access to the Domain Name Service (DNS) server		maintained to secure access to the Domain Name Service (DNS) server
	is limited, assuming any necessary updates are carried out by the		is limited, assuming any necessary updates are carried out by the
	skipping to change at page 31, line 15		skipping to change at page 31, line 20
	Many operator networks have to run interior routing protocols for		Many operator networks have to run interior routing protocols for
	both IPv4 and IPv6. It is possible to run the both in one routing		both IPv4 and IPv6. It is possible to run the both in one routing
	protocol, or have two separate routing protocols; either approach has		protocol, or have two separate routing protocols; either approach has
	its tradeoffs [RFC4029]. If multiple routing protocols are used, one		its tradeoffs [RFC4029]. If multiple routing protocols are used, one
	should note that this causes double the amount of processing when		should note that this causes double the amount of processing when
	links flap or recalculation is otherwise needed -- which might more		links flap or recalculation is otherwise needed -- which might more
	easily overload the router's CPU, causing slightly slower convergence		easily overload the router's CPU, causing slightly slower convergence
	time.		time.
	4.9. Ingress Filtering Issues Due to Privacy Addresses		4.9. Security Issues Due to Neighbor Discovery Proxies
	[I-D.ietf-ipv6-privacy-addrs-v2] describes a method for creating
	temporary addresses on IPv6 nodes to address privacy issues created
	by the use of a constant identifier. In a large network implementing
	such a mechanism new temporary addresses may be created at a fairly
	high rate. As discussed in Section 2.1.7, this might make it hard
	for ingress filtering mechanisms to distinguish between legitimately
	changing temporary addresses and spoofed source addresses, which are
	"in-prefix" (i.e., they use a topologically correct prefix and non-
	existent interface ID). This can be addressed by using finer grained
	access control mechanisms on a per address basis at the network
	egress point as suggested in the Security Considerations section of
	[I-D.ietf-ipv6-privacy-addrs-v2].
	4.10. Security Issues Due to Neighbor Discovery Proxies
	In order to span a single subnet over multiple physical links, a new		In order to span a single subnet over multiple physical links, a new
	experimental capability is being trialled in IPv6 to proxy Neighbor		experimental capability is being trialled in IPv6 to proxy Neighbor
	Discovery messages. A node with this capability will be called an		Discovery messages. A node with this capability will be called an
	NDProxy (see [RFC4389]. NDProxies are susceptible to the same		NDProxy (see [RFC4389]. NDProxies are susceptible to the same
	security issues as the ones faced by hosts using unsecured Neighbor		security issues as the ones faced by hosts using unsecured Neighbor
	Discovery or ARP. These proxies may process unsecured messages, and		Discovery or ARP. These proxies may process unsecured messages, and
	update the neighbor cache as a result of such processing, thus		update the neighbor cache as a result of such processing, thus
	allowing a malicious node to divert or hijack traffic. This may		allowing a malicious node to divert or hijack traffic. This may
	undermine the advantages of using SEND [RFC3971].		undermine the advantages of using SEND [RFC3971].
	skipping to change at page 32, line 43		skipping to change at page 32, line 32
	the issues with the base IPv6 specification which are documented		the issues with the base IPv6 specification which are documented
	here.		here.
	8. References		8. References
	8.1. Normative References		8.1. Normative References
	[I-D.ietf-ipv6-privacy-addrs-v2]		[I-D.ietf-ipv6-privacy-addrs-v2]
	Narten, T., "Privacy Extensions for Stateless Address		Narten, T., "Privacy Extensions for Stateless Address
	Autoconfiguration in IPv6",		Autoconfiguration in IPv6",
	draft-ietf-ipv6-privacy-addrs-v2-04 (work in progress),		draft-ietf-ipv6-privacy-addrs-v2-05 (work in progress),
	December 2005.		October 2006.
	[RFC1122] Braden, R., "Requirements for Internet Hosts -		[RFC1122] Braden, R., "Requirements for Internet Hosts -
	Communication Layers", STD 3, RFC 1122, October 1989.		Communication Layers", STD 3, RFC 1122, October 1989.
	[RFC2375] Hinden, R. and S. Deering, "IPv6 Multicast Address		[RFC2375] Hinden, R. and S. Deering, "IPv6 Multicast Address
	Assignments", RFC 2375, July 1998.		Assignments", RFC 2375, July 1998.
	[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6		[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6
	(IPv6) Specification", RFC 2460, December 1998.		(IPv6) Specification", RFC 2460, December 1998.
	skipping to change at page 34, line 15		skipping to change at page 34, line 6
	draft-ietf-tcpm-icmp-attacks-00 (work in progress),		draft-ietf-tcpm-icmp-attacks-00 (work in progress),
	February 2006.		February 2006.
	[I-D.ietf-v6ops-icmpv6-filtering-recs]		[I-D.ietf-v6ops-icmpv6-filtering-recs]
	Davies, E. and J. Mohacsi, "Recommendations for Filtering		Davies, E. and J. Mohacsi, "Recommendations for Filtering
	ICMPv6 Messages in Firewalls",		ICMPv6 Messages in Firewalls",
	draft-ietf-v6ops-icmpv6-filtering-recs-02 (work in		draft-ietf-v6ops-icmpv6-filtering-recs-02 (work in
	progress), July 2006.		progress), July 2006.
	[I-D.ietf-v6ops-nap]		[I-D.ietf-v6ops-nap]
	Velde, G., "IPv6 Network Architecture Protection",		Velde, G., "Network Architecture Protection for IPv6",
	draft-ietf-v6ops-nap-03 (work in progress), July 2006.		draft-ietf-v6ops-nap-04 (work in progress), October 2006.
	[I-D.ietf-v6ops-natpt-to-exprmntl]		[I-D.ietf-v6ops-natpt-to-exprmntl]
	Aoun, C. and E. Davies, "Reasons to Move NAT-PT to		Aoun, C. and E. Davies, "Reasons to Move NAT-PT to
	Experimental", draft-ietf-v6ops-natpt-to-exprmntl-03 (work		Experimental", draft-ietf-v6ops-natpt-to-exprmntl-03 (work
	in progress), October 2005.		in progress), October 2005.
	[I-D.ietf-v6ops-scanning-implications]		[I-D.ietf-v6ops-scanning-implications]
	Chown, T., "IPv6 Implications for Network Scanning",		Chown, T., "IPv6 Implications for Network Scanning",
	draft-ietf-v6ops-scanning-implications-00 (work in		draft-ietf-v6ops-scanning-implications-00 (work in
	progress), June 2006.		progress), June 2006.
End of changes. 16 change blocks.
	56 lines changed or deleted		47 lines changed or added
This html diff was produced by rfcdiff 1.33. The latest version is available from http://tools.ietf.org/tools/rfcdiff/