Subject: I-D Action:draft-ietf-6man-overlap-fragment-00.txt

From: [email-masked]
Date: Wed, 24 Sep 2008 07:30:01 -0700 (PDT)

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the IPv6 Maintenance Working Group of the IETF.

	Title           : Handling of overlapping IPv6 fragments
	Author(s)       : S. Krishnan
	Filename        : draft-ietf-6man-overlap-fragment-00.txt
	Pages           : 7
	Date            : 2008-09-22

The fragmentation and reassembly algorithm specified in the base IPv6
specification allows fragments to overlap.  This document
demonstrates the security issues with allowing overlapping fragments
and updates the IPv6 specification to explicitly forbid overlapping
fragments.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-6man-overlap-fragment-00.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

---

From: Rémi Denis-Courmont <[email-masked]>
Date: Wed, 24 Sep 2008 17:05:34 +0200

> and updates the IPv6 specification to explicitly forbid overlapping

| The TCP header has the following values of the flags S(YN)=0 and
| A(CK)=1.  This makes an inspecting stateful firewall think that it is
| a response packet for a connection request initiated from the trusted
| side of the firewall.  Hence it will allow the fragment to pass.  It
| will also let the following fragments with the same Fragment
| Identification value in the fragment header to pass through.

I could see this happen for a stateLESS firewall. But won't a stateFUL
firewall drop the packet as not being part of any existing flow? AFAIK,
Linux Netfilter would class the packet as INVALID in this case.

I don't suppose this nullifies the attack, but the example looks rather
like a bad one.

-- 
Rémi Denis-Courmont

---

From: Suresh Krishnan <[email-masked]>
Date: Wed, 24 Sep 2008 11:23:28 -0400

Hi Remi,

> I don't suppose this nullifies the attack, but the example looks rather

The idea was that we could use the state created for a different flow to 
initiate an incoming flow. Maybe the text can be reworded a bit to make 
it clearer.

e.g. Look at the following example message flow

1) Inside_Host(Port X)->Outside_Host(Port Y) SYN=1,ACK=0
2) Outside_Host(Port Y)->Inside Host(Port X) SYN=1,ACK=1
3) Inside_Host(Port X)->Outside_Host(Port Y) SYN=0,ACK=1

...

99) Outside_Host(Port Y)->Inside Host(Port X) SYN=0,ACK=1
     (Fragment: OH(Port Z)->IH(Port 80) SYN=1,ACK=0)

The packet numbered 99) will not be filtered even by a stateful firewall.

Thanks
Suresh

---

From: Rémi Denis-Courmont <[email-masked]>
Date: Wed, 24 Sep 2008 17:36:43 +0200

> The packet numbered 99) will not be filtered even by a stateful firewall.

But then the dialog is established and a SYN=1 ACK=0 packet in the reverse
direction is not really an issue. In fact some stateful firewalls may even
allow the packet due to optimizations.

-- 
Rémi Denis-Courmont

---

From: Suresh Krishnan <[email-masked]>
Date: Wed, 24 Sep 2008 11:39:07 -0400

Hi Remi,

> allow the packet due to optimizations.

But the packet is not destined for the already established ports. This 
packet is trying to establish a new incoming http connection. If the 
firewall lets it through, there is a problem.

Thanks
Suresh