draft-ietf-6man-overlap-fragment-02.txt		draft-ietf-6man-overlap-fragment-03.txt
	6man Working Group S. Krishnan		6man Working Group S. Krishnan
	Internet-Draft Ericsson		Internet-Draft Ericsson
	Updates: 2460 (if approved) March 8, 2009		Updates: 2460 (if approved) July 2, 2009
	Intended status: Standards Track		Intended status: Standards Track
	Expires: September 9, 2009		Expires: January 3, 2010
	Handling of overlapping IPv6 fragments		Handling of overlapping IPv6 fragments
	draft-ietf-6man-overlap-fragment-02		draft-ietf-6man-overlap-fragment-03
	Status of this Memo		Status of this Memo
	This Internet-Draft is submitted to IETF in full conformance with the		This Internet-Draft is submitted to IETF in full conformance with the
	provisions of BCP 78 and BCP 79.		provisions of BCP 78 and 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
	other groups may also distribute working documents as Internet-		other groups may also distribute working documents as Internet-
	Drafts.		Drafts.
	skipping to change at page 1, line 33		skipping to change at page 1, line 33
	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 September 9, 2009.		This Internet-Draft will expire on January 3, 2010.
	Copyright Notice		Copyright Notice
	Copyright (c) 2009 IETF Trust and the persons identified as the		Copyright (c) 2009 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 in effect on the date of		Provisions Relating to IETF Documents in effect on the date of
	publication of this document (http://trustee.ietf.org/license-info).		publication of this document (http://trustee.ietf.org/license-info).
	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 16		skipping to change at page 2, line 16
	fragments.		fragments.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
	1.1. Conventions used in this document . . . . . . . . . . . . . 3		1.1. Conventions used in this document . . . . . . . . . . . . . 3
	2. Overlapping Fragments . . . . . . . . . . . . . . . . . . . . . 3		2. Overlapping Fragments . . . . . . . . . . . . . . . . . . . . . 3
	3. The attack . . . . . . . . . . . . . . . . . . . . . . . . . . 4		3. The attack . . . . . . . . . . . . . . . . . . . . . . . . . . 4
	4. Recommendation . . . . . . . . . . . . . . . . . . . . . . . . 6		4. Recommendation . . . . . . . . . . . . . . . . . . . . . . . . 6
	5. Security Considerations . . . . . . . . . . . . . . . . . . . . 6		5. Security Considerations . . . . . . . . . . . . . . . . . . . . 6
	6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6		6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 6
	7. Normative References . . . . . . . . . . . . . . . . . . . . . 6		7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7
			8. Normative References . . . . . . . . . . . . . . . . . . . . . 7
	Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 7		Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 7
	1. Introduction		1. Introduction
	Fragmentation is used in IPv6 when the IPv6 packet will not fit		Fragmentation is used in IPv6 when the IPv6 packet will not fit
	inside the path MTU to its destination. When fragmentation is		inside the path MTU to its destination. When fragmentation is
	performed an IPv6 node uses a fragment header as specified in section		performed an IPv6 node uses a fragment header as specified in section
	4.5 of the IPv6 base specification [RFC2460] to break down the		4.5 of the IPv6 base specification [RFC2460] to break down the
	datagram into smaller fragments that will fit in the path MTU. The		datagram into smaller fragments that will fit in the path MTU. The
	destination node receives these fragments and reassembles them. The		destination node receives these fragments and reassembles them. The
	skipping to change at page 5, line 30		skipping to change at page 5, line 30
	| Sequence Number |		| Sequence Number |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Acknowledgment Number |		| Acknowledgment Number |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Offset| Reserved |U|A|P|R|S|F| Window |		| Offset| Reserved |U|A|P|R|S|F| Window |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Figure 3: First Fragment		Figure 3: First Fragment
	The TCP header has the following values of the flags S(YN)=1 and		The TCP header has the following values of the flags S(YN)=1 and
	A(CK)=1. This makes an inspecting stateful firewall think that it is		A(CK)=1. This may make an inspecting stateful firewall think that it
	a response packet for a connection request initiated from the trusted		is a response packet for a connection request initiated from the
	side of the firewall. Hence it will allow the fragment to pass. It		trusted side of the firewall. Hence it will allow the fragment to
	will also allow the following fragments with the same Fragment		pass. It will also allow the following fragments with the same
	Identification value in the fragment header to pass through.		Fragment Identification value in the fragment header to pass through.
	A malicious node can form a second fragment with a TCP header that		A malicious node can form a second fragment with a TCP header that
	changes the flags and sets S(YN)=1 and A(CK)=0. This would change		changes the flags and sets S(YN)=1 and A(CK)=0. This can change the
	the packet on the receiving end to consider the packet as a		packet on the receiving end to consider the packet as a connection
	connection request instead of a response. By doing this the		request instead of a response. By doing this the malicious node has
	malicious node has bypassed the firewall's access control to initiate		bypassed the firewall's access control to initiate a connection
	a connection request to a node protected by a firewall.		request to a node protected by a firewall.
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<==FH		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<==FH
	|NextHdr=DOH(60)| Reserved | FragmentOffset = 10 |Res|0|		|NextHdr=DOH(60)| Reserved | FragmentOffset = 10 |Res|0|
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Identification=aaaabbbb |		| Identification=aaaabbbb |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<==TCP		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<==TCP
	| Source Port | Destination Port |		| Source Port | Destination Port |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Sequence Number |		| Sequence Number |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	skipping to change at page 6, line 29		skipping to change at page 6, line 29
	Figure 4: Second Fragment		Figure 4: Second Fragment
	Note that this attack is much more serious in IPv6 than in IPv4. In		Note that this attack is much more serious in IPv6 than in IPv4. In
	IPv4 the overlapping part of the TCP header did not include the		IPv4 the overlapping part of the TCP header did not include the
	source and destination ports. In IPv6 the attack can easily work to		source and destination ports. In IPv6 the attack can easily work to
	replace the source or destination port with an overlapping fragment.		replace the source or destination port with an overlapping fragment.
	4. Recommendation		4. Recommendation
	IPv6 nodes transmitting datagrams that need to be fragmented MUST NOT		IPv6 nodes transmitting datagrams that need to be fragmented MUST NOT
	create overlapping fragments. IPv6 nodes that receive a fragment		create overlapping fragments. When reassembling an IPv6 datagram, if
	that overlaps with a previously received fragment MUST cease the		one or more its constituent fragments is determined to be an
	reassembly process and MUST discard the previously received fragments		overlapping fragment, the entire datagram (and any constituent
	with the same IPv6 Source Address, IPv6 Destination Address and		fragments, including those not yet received), MUST be silently
	Fragment Identification.		discarded.
	5. Security Considerations		5. Security Considerations
	This document discusses an attack that can be used to bypass IPv6		This document discusses an attack that can be used to bypass IPv6
	firewalls using overlapping fragments. It recommends disallowing		firewalls using overlapping fragments. It recommends disallowing
	overlapping fragments in order to prevent this attack.		overlapping fragments in order to prevent this attack.
	6. IANA Considerations		6. Acknowledgements
			The author would like to thank Thomas Narten, Doug Montgomery,
			Gabriel Montenegro, Remi Denis-Courmont, Marla Azinger, Arnaud
			Ebalard, Seiichi Kawamura, Behcet Sarikaya, Vishwas Manral, Christian
			Vogt, and Alfred Hoenes for their reviews and suggestions that made
			this document better.
			7. IANA Considerations
	This document does not require any action from the IANA.		This document does not require any action from the IANA.
	7. Normative References		8. Normative References
	[RFC1858] Ziemba, G., Reed, D., and P. Traina, "Security		[RFC1858] Ziemba, G., Reed, D., and P. Traina, "Security
	Considerations for IP Fragment Filtering", RFC 1858,		Considerations for IP Fragment Filtering", RFC 1858,
	October 1995.		October 1995.
	[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, March 1997.		Requirement Levels", BCP 14, RFC 2119, March 1997.
	[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.
End of changes. 10 change blocks.
	23 lines changed or deleted		32 lines changed or added
This html diff was produced by rfcdiff 1.35. The latest version is available from http://tools.ietf.org/tools/rfcdiff/