Subject: RE: IPv6 and Tiny Fragments

From: "Vishwas Manral" <[email-masked]>
Date: Sun, 27 Nov 2005 20:00:32 -0800

Hi Fred,

Good point. I agree, however a bigger limit would provide more
protection, besides a lot of extension headers may not be valid in most
cases, so TCP headers would come within the 800 bytes. Having a
configurable minimum value with default closer to 800, could help too.

Pyda, on another note I have been wondering whether NAPT-PT work
properly in the case where the first fragment, did not have the TCP port
unless we maintained states of fragments (what the next header expected
in the fragment is etc)?

Thanks,

Vishwas

________________________________

From: Fred Baker [mailto:[email-masked]] 
Sent: Sunday, November 27, 2005 9:44 AM
To: Vishwas Manral
Cc: [email-masked]
Subject: Re: IPv6 and Tiny Fragments

personally, I think that would simply mean that the tiny fragment attack
would come at that size.

Better to simply design TCPs well so that the attack is of minimal
effect.

On Nov 24, 2005, at 9:10 PM, Vishwas Manral wrote:

Hi folks,

I have been wondering how IPv6 will deal with the tiny fragment attack,
RFC1858.

Is there a minimum non-last fragment size specified for IPv6? With so
many extension headers a size of around 80bytes IP Header+ payload may
not necessarily be right. 

I think, we could specify something closer to 200 bytes, which would
mean that we would certainly have the TCP header in the first fragment.

Thanks,

Vishwas

--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

---

From: Stig Venaas <[email-masked]>
Date: Mon, 28 Nov 2005 09:37:39 +0100

> configurable minimum value with default closer to 800, could help too.

Not quite sure what you mean, since at least one fragment might be
smaller, but I suppose you mean the initial. If we were to have a
minimum, I would suggest 640 (based on what I posted earlier in
this thread).

However, with IPv6 it is perfectly possible to add so many extension
headers that the TCP header is beyond whatever boundary you might
set. I think perhaps that's what Fred was saying. I suppose you
could just drop such packets assuming it is some kind of attack
though.

Another thing is that by doing filtering in end-hosts this would
be less of an issue. You can reassemble the entire packet before
making decisions.

> unless we maintained states of fragments (what the next header expected

Yes, it would make NAPT-PT difficult, but not so sure I want to
have NAPT-PT anyway...

Stig

---

From: Pyda Srisuresh <[email-masked]>
Date: Mon, 28 Nov 2005 09:59:40 -0800 (PST)

Hi Vishwas,

NAT-PT is not the only middlebox effected by this phenomenon. Other middleboxes
effected would include NAT-PTs, firewalls, secure VPNs and a number of policy
based devices. All these middleboxes should be required to process fragments
that arrive out of order and assemble the fragments into an IP packet before
they process the packet. This, I believe, is the recommendation that went into
the NAT Behave UDP draft. As for the reality of the percentage of middleboxes
that do this right is unknown.

cheers,
suresh