< draft-ietf-v6ops-ipv6-ehs-packet-drops-03.txt		draft-ietf-v6ops-ipv6-ehs-packet-drops-04.txt >
	IPv6 Operations Working Group (v6ops) F. Gont		IPv6 Operations Working Group (v6ops) F. Gont
	Internet-Draft SI6 Networks		Internet-Draft SI6 Networks
	Intended status: Informational N. Hilliard		Intended status: Informational N. Hilliard
	Expires: July 6, 2021 INEX		Expires: August 14, 2021 INEX
	G. Doering		G. Doering
	SpaceNet AG		SpaceNet AG
	W. Kumari		W. Kumari
	Google		Google
	G. Huston		G. Huston
	APNIC		APNIC
	W. Liu		W. Liu
	Huawei Technologies		Huawei Technologies
	January 2, 2021		February 10, 2021
	Operational Implications of IPv6 Packets with Extension Headers		Operational Implications of IPv6 Packets with Extension Headers
	draft-ietf-v6ops-ipv6-ehs-packet-drops-03		draft-ietf-v6ops-ipv6-ehs-packet-drops-04
	Abstract		Abstract
	This document summarizes the operational implications of IPv6		This document summarizes the operational implications of IPv6
	extension headers specified in the IPv6 protocol specification		extension headers specified in the IPv6 protocol specification
	(RFC8200), and attempts to analyze reasons why packets with IPv6		(RFC8200), and attempts to analyze reasons why packets with IPv6
	extension headers are often dropped in the public Internet.		extension headers are often dropped in the public Internet.
	Status of This Memo		Status of This Memo
	skipping to change at page 1, line 42 ¶		skipping to change at page 1, line 42 ¶
	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 July 6, 2021.		This Internet-Draft will expire on August 14, 2021.
	Copyright Notice		Copyright Notice
	Copyright (c) 2021 IETF Trust and the persons identified as the		Copyright (c) 2021 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 7, line 7 ¶		skipping to change at page 7, line 7 ¶
	containing IPv6 EHs are dropped in the public Internet.		containing IPv6 EHs are dropped in the public Internet.
	o [RFC7872] presents more comprehensive results and documents the		o [RFC7872] presents more comprehensive results and documents the
	methodology used to obtain these results.		methodology used to obtain these results.
	o [Huston-2017] and [Huston-2020] measured packet drops resulting		o [Huston-2017] and [Huston-2020] measured packet drops resulting
	from IPv6 fragmentation when communicating with DNS servers.		from IPv6 fragmentation when communicating with DNS servers.
	5. Packet Forwarding Engine Constraints		5. Packet Forwarding Engine Constraints
	Most contemporary routers use dedicated hardware (e.g. ASICs or		Most contemporary routers use dedicated hardware (e.g., ASICs or
	NPUs) to determine how to forward packets across their internal		NPUs) to determine how to forward packets across their internal
	fabrics (see [IEPG94-Scudder] and [APNIC-Scudder] for details). One		fabrics (see [IEPG94-Scudder] and [APNIC-Scudder] for details). One
	of the common methods of handling next-hop lookup is to send a small		of the common methods of handling next-hop lookup is to send a small
	portion of the ingress packet to a lookup engine with specialised		portion of the ingress packet to a lookup engine with specialised
	hardware (e.g. ternary CAM or RLDRAM) to determine the packet's next-		hardware (e.g., ternary CAM or RLDRAM) to determine the packet's
	hop. Technical constraints mean that there is a trade-off between		next-hop. Technical constraints mean that there is a trade-off
	the amount of data sent to the lookup engine and the overall		between the amount of data sent to the lookup engine and the overall
	performance of the lookup engine. If more data is sent, the lookup		performance of the lookup engine. If more data is sent, the lookup
	engine can inspect further into the packet, but the overall		engine can inspect further into the packet, but the overall
	performance of the system will be reduced. If less data is sent, the		performance of the system will be reduced. If less data is sent, the
	overall performance of the router will be increased but the packet		overall performance of the router will be increased but the packet
	lookup engine may not be able to inspect far enough into a packet to		lookup engine may not be able to inspect far enough into a packet to
	determine how it should be handled.		determine how it should be handled.
	NOTE:		NOTE:
	For example, contemporary high-end routers can use up to 192 bytes		For example, some contemporary high-end routers are known to use
	of header (Cisco ASR9000 Typhoon) or 384 bytes of header (Juniper		up to 192 bytes or 384 bytes of header.
	MX Trio).
	If a hardware forwarding engine on a contemporary router cannot make		If a hardware forwarding engine on a contemporary router cannot make
	a forwarding decision about a packet because critical information is		a forwarding decision about a packet because critical information is
	not sent to the look-up engine, then the router will normally drop		not sent to the look-up engine, then the router will normally drop
	the packet.		the packet. Section 6 discusses some of the reasons for which a
			contemporary router might need to access layer-4 information to make
	NOTE:		a forwarding decision.
	Section 6 discusses some of the reasons for which a contemporary
	router might need to access layer-4 information to make a
	forwarding decision.
	Historically, some packet forwarding engines punted packets of this		Historically, some packet forwarding engines punted packets of this
	form to the control plane for more in-depth analysis, but this is		form to the control plane for more in-depth analysis, but this is
	unfeasible on most contemporary router architectures as a result of		unfeasible on most contemporary router architectures as a result of
	the vast difference between the hardware forwarding capacity of the		the vast difference between the hardware forwarding capacity of the
	router and processing capacity of the control plane and the size of		router and processing capacity of the control plane and the size of
	the management link which connects the control plane to the		the management link which connects the control plane to the
	forwarding plane.		forwarding plane. Other platforms may have a separate software
			forwarding plane that is distinct both from the hardware forwarding
			plane and the control plane. However, the limited CPU resources of
			this software-based forwarding plane, as well as the limited
			bandwidth of the associated link results in similar throughput
			constraints.
	If an IPv6 header chain is sufficiently long that it exceeds the		If an IPv6 header chain is sufficiently long that it exceeds the
	packet look-up capacity of the router, the router could resort to		packet look-up capacity of the router, the router might be unable to
	dropping the packet, as a result of being unable to determine how the		determine how the packet should be handled, and thus could resort to
	packet should be handled.		dropping the packet.
	5.1. Recirculation		5.1. Recirculation
	Although TLV chains are amenable to iterative processing on		Although TLV chains are amenable to iterative processing on
	architectures that have packet look-up engines with deep inspection		architectures that have packet look-up engines with deep inspection
	capabilities, some packet forwarding engines manage IPv6 Extension		capabilities, some packet forwarding engines manage IPv6 Extension
	Header chains using recirculation. This approach processes Extension		Header chains using recirculation. This approach processes Extension
	Headers one at a time: when processing on one Extension Header is		Headers one at a time: when processing on one Extension Header is
	completed, the packet is looped back through the processing engine		completed, the packet is looped back through the processing engine
	again. This recirculation process continues repeatedly until there		again. This recirculation process continues repeatedly until there
	skipping to change at page 10, line 33 ¶		skipping to change at page 10, line 33 ¶
	Use of extension headers can be problematic for NIDS/IPS, since:		Use of extension headers can be problematic for NIDS/IPS, since:
	o Extension headers increase the complexity of resulting traffic,		o Extension headers increase the complexity of resulting traffic,
	and the associated work and system requirements to process it.		and the associated work and system requirements to process it.
	o Use of unknown extension headers can prevent an NIDS/IPS from		o Use of unknown extension headers can prevent an NIDS/IPS from
	processing layer-4 information		processing layer-4 information
	o Use of IPv6 fragmentation requires a stateful fragment-reassembly		o Use of IPv6 fragmentation requires a stateful fragment-reassembly
	operation, even for decoy traffic employing forged source		operation, even for decoy traffic employing forged source
	addresses (see e.g. [nmap]).		addresses (see e.g., [nmap]).
	As a result, in order to increase the efficiency or effectiveness of		As a result, in order to increase the efficiency or effectiveness of
	these systems, packets employing IPv6 extension headers are often		these systems, packets employing IPv6 extension headers are often
	dropped at the network ingress point(s) of networks that deploy these		dropped at the network ingress point(s) of networks that deploy these
	systems.		systems.
	6.5. Firewalling		6.5. Firewalling
	Firewalls enforce security policies by means of packet filtering.		Firewalls enforce security policies by means of packet filtering.
	These systems usually inspect layer-3 and layer-4 traffic, but can		These systems usually inspect layer-3 and layer-4 traffic, but can
	often also examine application-layer traffic flows.		often also examine application-layer traffic flows.
	As with NIDS/IPS (Section 6.4), use of IPv6 extension headers can		As with NIDS/IPS (Section 6.4), use of IPv6 extension headers can
	represent a challenge to network firewalls, since:		represent a challenge to network firewalls, since:
	o Extension headers increase the complexity of resulting traffic,		o Extension headers increase the complexity of resulting traffic,
	and the associated work and system requirements to process it (see		and the associated work and system requirements to process it (see
	e.g. [Zack-FW-Benchmark]).		e.g., [Zack-FW-Benchmark]).
	o Use of unknown extension headers can prevent firewalls from		o Use of unknown extension headers can prevent firewalls from
	processing layer-4 information.		processing layer-4 information.
	o Use of IPv6 fragmentation requires a stateful fragment-reassembly		o Use of IPv6 fragmentation requires a stateful fragment-reassembly
	operation, even for decoy traffic employing forged source		operation, even for decoy traffic employing forged source
	addresses (see e.g. [nmap]).		addresses (see e.g., [nmap]).
	Additionally, a common firewall filtering policy is the so-called		Additionally, a common firewall filtering policy is the so-called
	"default deny", where all traffic is blocked (by default), and only		"default deny", where all traffic is blocked (by default), and only
	expected traffic is added to an "allow/accept list".		expected traffic is added to an "allow/accept list".
	As a result, whether because of the challenges represented by		As a result, packets employing IPv6 extension headers are often
	extension headers or because the use of IPv6 extension headers has		dropped by network firewalls, either because of the challenges
	not been explicitly allowed, packets employing IPv6 extension headers		represented by extension headers or because the use of IPv6 extension
	are often dropped by network firewalls.		headers has not been explicitly allowed.
	7. Operational Implications		7. Operational Implications
	7.1. Inability to Find Layer-4 Information		7.1. Inability to Find Layer-4 Information
	As discussed in Section 6, routers and middle-boxes that need to find		As discussed in Section 6, routers and middle-boxes that need to find
	the layer-4 header must process the entire IPv6 extension header		the layer-4 header must process the entire IPv6 extension header
	chain. When such devices are unable to obtain the required		chain. When such devices are unable to obtain the required
	information, the forwarding device has the option to drop the packet		information, the forwarding device has the option to drop the packet
	unconditionally, forward the packet unconditionally, or process the		unconditionally, forward the packet unconditionally, or process the
	packet outside the normal forwarding path. Forwarding packets		packet outside the normal forwarding path. Forwarding packets
	unconditionally will usually allow for the circumvention of security		unconditionally will usually allow for the circumvention of security
	controls (see e.g. Section 6.5), while processing packets outside of		controls (see e.g., Section 6.5), while processing packets outside of
	the normal forwarding path will usually open the door to DoS attacks		the normal forwarding path will usually open the door to DoS attacks
	(see e.g. Section 5). Thus, in these scenarios, devices often		(see e.g., Section 5). Thus, in these scenarios, devices often
	simply resort to dropping such packets unconditionally.		simply resort to dropping such packets unconditionally.
	7.2. Route-Processor Protection		7.2. Route-Processor Protection
	Most contemporary routers have a fast hardware-assisted forwarding		Most contemporary routers have a fast hardware-assisted forwarding
	plane and a loosely coupled control plane, connected together with a		plane and a loosely coupled control plane, connected together with a
	link that has much less capacity than the forwarding plane could		link that has much less capacity than the forwarding plane could
	handle. Traffic differentiation cannot be performed by the control		handle. Traffic differentiation cannot be performed by the control
	plane, because this would overload the internal link connecting the		plane, because this would overload the internal link connecting the
	forwarding plane to the control plane.		forwarding plane to the control plane.
	skipping to change at page 12, line 12 ¶		skipping to change at page 12, line 12 ¶
	IPv6 packets containing this extension header. [RFC6192] provides		IPv6 packets containing this extension header. [RFC6192] provides
	advice regarding protection of a router's control plane.		advice regarding protection of a router's control plane.
	7.3. Inability to Perform Fine-grained Filtering		7.3. Inability to Perform Fine-grained Filtering
	Some router implementations do not have support for fine-grained		Some router implementations do not have support for fine-grained
	filtering of IPv6 extension headers. For example, an operator that		filtering of IPv6 extension headers. For example, an operator that
	wishes to drop packets containing Routing Header Type 0 (RHT0), may		wishes to drop packets containing Routing Header Type 0 (RHT0), may
	only be able to filter on the extension header type (Routing Header).		only be able to filter on the extension header type (Routing Header).
	This could result in an operator enforcing a more coarse filtering		This could result in an operator enforcing a more coarse filtering
	policy (e.g. "drop all packets containing a Routing Header" vs. "only		policy (e.g., "drop all packets containing a Routing Header" vs.
	drop packets that contain a Routing Header Type 0").		"only drop packets that contain a Routing Header Type 0").
	7.4. Security Concerns Associated with IPv6 Extension Headers		7.4. Security Concerns Associated with IPv6 Extension Headers
	The security implications of IPv6 Extension Headers generally fall		The security implications of IPv6 Extension Headers generally fall
	into one or more of these categories:		into one or more of these categories:
	o Evasion of security controls		o Evasion of security controls
	o DoS due to processing requirements		o DoS due to processing requirements
	skipping to change at page 13, line 22 ¶		skipping to change at page 13, line 22 ¶
	information, thereby causing the packet to be processed in the		information, thereby causing the packet to be processed in the
	slow path [Cisco-EH-Cons]. We note that, for obvious reasons, the		slow path [Cisco-EH-Cons]. We note that, for obvious reasons, the
	aforementioned performance issues can affect other devices such as		aforementioned performance issues can affect other devices such as
	firewalls, Network Intrusion Detection Systems (NIDS), etc.		firewalls, Network Intrusion Detection Systems (NIDS), etc.
	[Zack-FW-Benchmark]. The extent to which performance is affected		[Zack-FW-Benchmark]. The extent to which performance is affected
	on these devices is implementation-dependent.		on these devices is implementation-dependent.
	IPv6 implementations, like all other software, tend to mature with		IPv6 implementations, like all other software, tend to mature with
	time and wide-scale deployment. While the IPv6 protocol itself has		time and wide-scale deployment. While the IPv6 protocol itself has
	existed for over 20 years, serious bugs related to IPv6 Extension		existed for over 20 years, serious bugs related to IPv6 Extension
	Header processing continue to be discovered (see e.g. [Cisco-Frag1],		Header processing continue to be discovered (see e.g., [Cisco-Frag1],
	[Cisco-Frag2], and [FreeBSD-SA]). Because there is currently little		[Cisco-Frag2], [Microsoft-SA], and [FreeBSD-SA]). Because there is
	operational reliance on IPv6 Extension headers, the corresponding		currently little operational reliance on IPv6 Extension headers, the
	code paths are rarely exercised, and there is the potential for bugs		corresponding code paths are rarely exercised, and there is the
	that still remain to be discovered in some implementations.		potential for bugs that still remain to be discovered in some
			implementations.
	IPv6 Fragment Headers are employed to allow fragmentation of IPv6		IPv6 Fragment Headers are employed to allow fragmentation of IPv6
	packets. While many of the security implications of the		packets. While many of the security implications of the
	fragmentation / reassembly mechanism are known from the IPv4 world,		fragmentation / reassembly mechanism are known from the IPv4 world,
	several related issues have crept into IPv6 implementations. These		several related issues have crept into IPv6 implementations. These
	range from denial of service attacks to information leakage, as		range from denial of service attacks to information leakage, as
	discussed in [RFC7739], [Bonica-NANOG58] and [Atlasis2012]).		discussed in [RFC7739], [Bonica-NANOG58] and [Atlasis2012]).
	8. IANA Considerations		8. IANA Considerations
	skipping to change at page 13, line 52 ¶		skipping to change at page 14, line 4 ¶
	The security implications of IPv6 extension headers are discussed in		The security implications of IPv6 extension headers are discussed in
	Section 7.4. This document does not introduce any new security		Section 7.4. This document does not introduce any new security
	issues.		issues.
	10. Acknowledgements		10. Acknowledgements
	The authors would like to thank (in alphabetical order) Mikael		The authors would like to thank (in alphabetical order) Mikael
	Abrahamsson, Fred Baker, Dale W. Carder, Brian Carpenter, Tim Chown,		Abrahamsson, Fred Baker, Dale W. Carder, Brian Carpenter, Tim Chown,
	Owen DeLong, Gorry Fairhurst, Tom Herbert, Lee Howard, Tom Petch,		Owen DeLong, Gorry Fairhurst, Tom Herbert, Lee Howard, Tom Petch,
	Sander Steffann, Eduard Vasilenko, Eric Vyncke, Jingrong Xie, and		Sander Steffann, Eduard Vasilenko, Eric Vyncke, Rob Wilton, Jingrong
	Andrew Yourtchenko, for providing valuable comments on earlier		Xie, and Andrew Yourtchenko, for providing valuable comments on
	versions of this document.		earlier versions of this document.
	Fernando Gont would like to thank Jan Zorz / Go6 Lab		Fernando Gont would like to thank Jan Zorz / Go6 Lab
	<https://go6lab.si/>, Jared Mauch, and Sander Steffann		<https://go6lab.si/>, Jared Mauch, and Sander Steffann
	<https://steffann.nl/>, for providing access to systems and networks		<https://steffann.nl/>, for providing access to systems and networks
	that were employed to perform experiments and measurements involving		that were employed to perform experiments and measurements involving
	packets with IPv6 Extension Headers.		packets with IPv6 Extension Headers.
	11. References		11. References
	11.1. Normative References		11.1. Normative References
	skipping to change at page 16, line 37 ¶		skipping to change at page 16, line 37 ¶
	fragmentation-dns/>.		fragmentation-dns/>.
	[Huston-2020]		[Huston-2020]
	Huston, G., "Measurement of IPv6 Extension Header		Huston, G., "Measurement of IPv6 Extension Header
	Support", NPS/CAIDA 2020 Virtual IPv6 Workshop, 2020,		Support", NPS/CAIDA 2020 Virtual IPv6 Workshop, 2020,
	<https://www.cmand.org/workshops/202006-v6/		<https://www.cmand.org/workshops/202006-v6/
	slides/2020-06-16-xtn-hdrs.pdf>.		slides/2020-06-16-xtn-hdrs.pdf>.
	[I-D.ietf-opsec-ipv6-eh-filtering]		[I-D.ietf-opsec-ipv6-eh-filtering]
	Gont, F. and W. LIU, "Recommendations on the Filtering of		Gont, F. and W. LIU, "Recommendations on the Filtering of
	IPv6 Packets Containing IPv6 Extension Headers", draft-		IPv6 Packets Containing IPv6 Extension Headers at Transit
	ietf-opsec-ipv6-eh-filtering-06 (work in progress), July		Routers", draft-ietf-opsec-ipv6-eh-filtering-07 (work in
	2018.		progress), January 2021.
	[I-D.kampanakis-6man-ipv6-eh-parsing]		[I-D.kampanakis-6man-ipv6-eh-parsing]
	Kampanakis, P., "Implementation Guidelines for parsing		Kampanakis, P., "Implementation Guidelines for parsing
	IPv6 Extension Headers", draft-kampanakis-6man-ipv6-eh-		IPv6 Extension Headers", draft-kampanakis-6man-ipv6-eh-
	parsing-01 (work in progress), August 2014.		parsing-01 (work in progress), August 2014.
	[I-D.taylor-v6ops-fragdrop]		[I-D.taylor-v6ops-fragdrop]
	Jaeggli, J., Colitti, L., Kumari, W., Vyncke, E., Kaeo,		Jaeggli, J., Colitti, L., Kumari, W., Vyncke, E., Kaeo,
	M., and T. Taylor, "Why Operators Filter Fragments and		M., and T. Taylor, "Why Operators Filter Fragments and
	What It Implies", draft-taylor-v6ops-fragdrop-02 (work in		What It Implies", draft-taylor-v6ops-fragdrop-02 (work in
	skipping to change at page 17, line 29 ¶		skipping to change at page 17, line 29 ¶
	DNS", APNIC Blog, 2018,		DNS", APNIC Blog, 2018,
	<https://blog.apnic.net/2018/01/11/ipv6-flow-label-misuse-		<https://blog.apnic.net/2018/01/11/ipv6-flow-label-misuse-
	hashing/>.		hashing/>.
	[Linkova-Gont-IEPG90]		[Linkova-Gont-IEPG90]
	Linkova, J. and F. Gont, "IPv6 Extension Headers in the		Linkova, J. and F. Gont, "IPv6 Extension Headers in the
	Real World v2.0", IEPG 90. Toronto, ON, Canada. July 20,		Real World v2.0", IEPG 90. Toronto, ON, Canada. July 20,
	2014, <http://www.iepg.org/2014-07-20-ietf90/iepg-		2014, <http://www.iepg.org/2014-07-20-ietf90/iepg-
	ietf90-ipv6-ehs-in-the-real-world-v2.0.pdf>.		ietf90-ipv6-ehs-in-the-real-world-v2.0.pdf>.
			[Microsoft-SA]
			Microsoft, "Windows TCP/IP Remote Code Execution
			Vulnerability (CVE-2021-24094)", February 2021,
			<https://msrc.microsoft.com/update-guide/vulnerability/
			CVE-2021-24094>.
	[nmap] Fyodor, "Dealing with IPv6 fragmentation in the		[nmap] Fyodor, "Dealing with IPv6 fragmentation in the
	DNS", Firewall/IDS Evasion and Spoofing,		DNS", Firewall/IDS Evasion and Spoofing,
	<https://nmap.org/book/man-bypass-firewalls-ids.html>.		<https://nmap.org/book/man-bypass-firewalls-ids.html>.
	[PMTUD-Blackholes]		[PMTUD-Blackholes]
	De Boer, M. and J. Bosma, "Discovering Path MTU black		De Boer, M. and J. Bosma, "Discovering Path MTU black
	holes on the Internet using RIPE Atlas", July 2012,		holes on the Internet using RIPE Atlas", July 2012,
	<http://www.nlnetlabs.nl/downloads/publications/pmtu-		<http://www.nlnetlabs.nl/downloads/publications/pmtu-
	black-holes-msc-thesis.pdf>.		black-holes-msc-thesis.pdf>.
End of changes. 21 change blocks.
	43 lines changed or deleted		51 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/