draft-ietf-6man-overlap-fragment-00.txt   draft-ietf-6man-overlap-fragment-01.txt 
IPv6 Working Group S. Krishnan 6man Working Group S. Krishnan
Internet-Draft Ericsson Internet-Draft Ericsson
Updates: 2460 (if approved) September 22, 2008 Updates: 2460 (if approved) November 3, 2008
Intended status: Standards Track Intended status: Standards Track
Expires: March 26, 2009 Expires: May 7, 2009
Handling of overlapping IPv6 fragments Handling of overlapping IPv6 fragments
draft-ietf-6man-overlap-fragment-00 draft-ietf-6man-overlap-fragment-01
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 35 skipping to change at page 1, line 35
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 26, 2009. This Internet-Draft will expire on May 7, 2009.
Abstract Abstract
The fragmentation and reassembly algorithm specified in the base IPv6 The fragmentation and reassembly algorithm specified in the base IPv6
specification allows fragments to overlap. This document specification allows fragments to overlap. This document
demonstrates the security issues with allowing overlapping fragments demonstrates the security issues with allowing overlapping fragments
and updates the IPv6 specification to explicitly forbid overlapping and updates the IPv6 specification to explicitly forbid overlapping
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 . . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. The attack . . . . . . . . . . . . . . . . . . . . . . . . . . 3
4. Recommendation . . . . . . . . . . . . . . . . . . . . . . . . 5 4. Recommendation . . . . . . . . . . . . . . . . . . . . . . . . 5
5. Security Considerations . . . . . . . . . . . . . . . . . . . . 5 5. Security Considerations . . . . . . . . . . . . . . . . . . . . 5
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6
7. Normative References . . . . . . . . . . . . . . . . . . . . . 6 7. Normative References . . . . . . . . . . . . . . . . . . . . . 6
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 6 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 6
Intellectual Property and Copyright Statements . . . . . . . . . . 7 Intellectual Property and Copyright Statements . . . . . . . . . . 7
1. Introduction 1. Introduction
skipping to change at page 3, line 24 skipping to change at page 3, line 24
the fragments from overlapping, and this can lead to some security the fragments from overlapping, and this can lead to some security
issues with firewalls [RFC4942]. This document explores the issues issues with firewalls [RFC4942]. This document explores the issues
that can be caused by overlapping fragments. that can be caused by overlapping fragments.
1.1. Conventions used in this document 1.1. Conventions used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL","SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL","SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
2. Overlapping fragments 2. Overlapping Fragments
Commonly used firewalls use the algorithm specified in [RFC1858] to Commonly used firewalls use the algorithm specified in [RFC1858] to
weed out malicious packets that try to overwrite parts of the weed out malicious packets that try to overwrite parts of the
transport layer header to bypass inbound connection checks. transport layer header to bypass inbound connection checks.
[RFC1858] prevents an overlapping fragment attack on an upper layer [RFC1858] prevents an overlapping fragment attack on an upper layer
protocol (in this case TCP) by recommending that packets with protocol (in this case TCP) by recommending that packets with
fragment offset 1 be dropped. While this works well for IPv4 fragment offset 1 be dropped. While this works well for IPv4
fragments, it will not work for IPv6 fragments. This is because the fragments, it will not work for IPv6 fragments. This is because the
fragmentable part of the IPv6 packet can contain extension headers fragmentable part of the IPv6 packet can contain extension headers
before the TCP header, making this check less effective. before the TCP header, making this check less effective.
skipping to change at page 4, line 7 skipping to change at page 4, line 7
| Unfragmentable | Fragmentable | | Unfragmentable | Fragmentable |
| Part | Part | | Part | Part |
+------------------+--------------------//-----------------------+ +------------------+--------------------//-----------------------+
Figure 1: Large IPv6 packet Figure 1: Large IPv6 packet
This packet is split into several fragments by the sender so that the This packet is split into several fragments by the sender so that the
packet can fit inside the path MTU. Let's say the packet is split packet can fit inside the path MTU. Let's say the packet is split
into two fragments. into two fragments.
+------------------+--------+--------------+ +------------------+--------+--------------------+
| Unfragmentable |Fragment| first | | Unfragmentable |Fragment| first |
| Part | Header | fragment | | Part | Header | fragment |
+------------------+--------+--------------+ +------------------+--------+--------------------+
+------------------+--------+--------------+ +------------------+--------+--------------------+
| Unfragmentable |Fragment| second | | Unfragmentable |Fragment| second |
| Part | Header | fragment | | Part | Header | fragment |
+------------------+--------+--------------+ +------------------+--------+--------------------+
Figure 2: Fragmented IPv6 packet Figure 2: Fragmented IPv6 packet
Consider the first fragment. Let's say it contains a destination Consider the first fragment. Let's say it contains a destination
options header (DOH) 80 octets long and is followed by a TCP header. options header (DOH) 80 octets long and is followed by a TCP header.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<==FH +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<==FH
|NextHdr=DOH(60)| Reserved | FragmentOffset = 0 |Res|1| |NextHdr=DOH(60)| Reserved | FragmentOffset = 0 |Res|1|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Identification=aaaabbbb | | Identification=aaaabbbb |
skipping to change at page 4, line 46 skipping to change at page 4, line 46
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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)=0 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 makes an inspecting stateful firewall think that it is
a response packet for a connection request initiated from the trusted a response packet for a connection request initiated from the trusted
side of the firewall. Hence it will allow the fragment to pass. It side of the firewall. Hence it will allow the fragment to pass. It
will also let the following fragments with the same Fragment will also allow the following fragments with the same Fragment
Identification value in the fragment header to pass through. 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
reverses 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 would change
the packet on the receiving end to consider the packet as a the packet on the receiving end to consider the packet as a
connection request instead of a response. By doing this the connection request instead of a response. By doing this the
malicious node has bypassed the firewall's access control to initiate malicious node has bypassed the firewall's access control to initiate
a connection request to a node protected by a firewall. a connection 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
skipping to change at page 5, line 31 skipping to change at page 5, line 31
| Acknowledgment Number | | Acknowledgment Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Offset| Reserved |U|A|P|R|S|F| Window | | Offset| Reserved |U|A|P|R|S|F| Window |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 destination ports 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. IPv6 nodes that receive a fragment
that overlaps with a previously received fragment MUST cease the that overlaps with a previously received fragment MUST cease the
reassembly process and MUST ignore further fragments with the same reassembly process and MUST ignore further fragments with the same
IPv6 Source Address, IPv6 Destination Address and Fragment IPv6 Source Address, IPv6 Destination Address and Fragment
Identification. It MUST also discard the previously received Identification. It MUST also discard the previously received
fragments with the same IPv6 Source Address, IPv6 Destination Address fragments with the same IPv6 Source Address, IPv6 Destination Address
 End of changes. 15 change blocks. 
15 lines changed or deleted 15 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/