Subject: Tiny fragments issues

From: "Vishwas Manral" <[email-masked]>
Date: Thu, 17 May 2007 10:24:17 +0530

Hi,

At the time of bringing up the amplification attacks i had also
brought up the issue of
http://tools.ietf.org/html/draft-manral-v6ops-tiny-fragments-issues-02 .

I would want to know if this issue needs to looked further by IPv6.

Thanks,
Vishwas

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

---

From: [email-masked] (Jun-ichiro itojun Hagino 2.0)
Date: Thu, 17 May 2007 13:57:36 +0900 (JST)

> I would want to know if this issue needs to looked further by IPv6.

	my take on this is that, for non-final fragment, the packet size must
	not be smaller than 1280 bytes.  there's no valid use for smaller
	fragments (unless you have special network with MTU < 1280).

	KAME node will not generate such packets/fragments, but KAME node would
	accept those packets happily.

	any ideas?

itojun

---

From: "Vishwas Manral" <[email-masked]>
Date: Thu, 17 May 2007 10:33:04 +0530

Hi Itojun,

I agree to the solution. If we get more people talking about the need
for this, we can actually revive the draft.

Thanks,
Vishwas

---

From: [email-masked] (Jun-ichiro itojun Hagino 2.0)
Date: Thu, 17 May 2007 15:06:31 +0900 (JST)

> for this, we can actually revive the draft.

	thought twice on this topic.
	for the sake of non-optimal implementation (such as embedded devices)
	i may want to permit packets > 1200 bytes.

	but embedded devices are ok to choose outgoing link MTU be 1280, i.e.
	never generate fragmented packets - you need some control over TCP MSS,
	need some tricky dance in IPv6 TCP IPsec.
	KAME IPsec/TCP MSS handling supports such usage, OpenBSD IPsec does not.

itojun

---

From: Suresh Krishnan <[email-masked]>
Date: Thu, 17 May 2007 10:12:46 -0400

Hi,

> 	fragments (unless you have special network with MTU < 1280).

I tend to disagree. I do think there are cases where it makes sense to 
have smaller non-final fragments. One example I can think about right 
away is that there is a tunnel somewhere between the source and the 
destination. In this case I would limit myself to a fragment size of 
less than 1280 to avoid further fragmentation.

Cheers
Suresh

---

From: "Vishwas Manral" <[email-masked]>
Date: Fri, 18 May 2007 15:45:19 +0530

Hi Suresh,

So are you suggesting the non-last fragment size of less than 1280,
example 1200.

I still have a doubt on this one. Can we state that the first fragment
should have the complete TCP/ UDP headers? I find this essential for
the case of stateless filtering, which are easier to do at line rate
in the hardware.

Thanks,
Vishwas

---

From: Elwyn Davies <[email-masked]>
Date: Fri, 18 May 2007 16:34:15 +0100

Hi.

Section 2.1.11 of the  Security Overview draft 
(http://www.ietf.org/internet-drafts/draft-ietf-v6ops-security-overview-06.txt)
discusses the 'tiny fragment' problem and tries to reflect Vishwas' 
original concerns on tiny fragments (see the acknowledgments).  After 
some discussion on the mailing list and with the IESG we settled on a 
recommendation that non-final fragments smaller than half the 1280 octet 
minimum MTU (i.e., 640 octets) ought to be filtered out.  For any 
realistic, non-malicious  transmission scheme this will not hit genuine 
packets AFAICS - it allows for schemes that distribute the bytes equally 
among the required number of fragments as well as schemes that allow for 
tunnel headers and schemes that send all fragments except the last at 
the MTU limit.

Also Section 2.1.10 suggests that first fragments that do not contain 
the transport protocol header are very suspicious and could be 
discarded.  Again in any realistic situation a 640 octet header packet 
should contain the whole of the extension headers and the transport 
protocol header - I am not aware of situations where the IPsec headers 
would be likely to break this and you would have to have an *awful* lot 
of addresses in a Type 0 routing header to break this limit.  Of course, 
Type 0 routing headers are suspicious for other reasons and need to be 
looked at closely as well!

Given that the current IPv6 standard is broken as regards its treatment 
of fragments, it would be good to update it but I am not sure that there 
is political will to make the relevant changes.  Certainly when I 
suggested this back in 2004 there was a lot of pushback.  The words in 
the security overview were the best compromise available at the time.  
If one were to update the standard, I think one would mandate non-final 
fragments to be at least 50% of the minimum MTU as probably the best way 
forward without breaking today's (good) implementations.  It would also 
mandate that fragments do not overlap.

Regards,
Elwyn

---

From: Suresh Krishnan <[email-masked]>
Date: Tue, 22 May 2007 18:04:28 -0400

Hi Vishwas,
> So are you suggesting the non-last fragment size of less than 1280,

Not exactly, but I think this should be administratively configurable. 
(1200 is a nice round number though :-)

> the case of stateless filtering, which are easier to do at line rate

I see where you are coming from, and as a person working on a NP based 
router I can empathize with you. But I do not see this being specified 
as the IPv6 fragmentation algorithm should not mention anything about 
upper layer headers (layering violation). If we go down this path we 
need to specify this for SCTP, DCCP, (insert your favorite future 
transport procol here), ....

Cheers
Suresh