Re: Tiny fragments issues

[Elwyn Davies <[e-mail]>]

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

Vishwas Manral wrote:
> 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
>
> On 5/17/07, Suresh Krishnan <[e-mail]> wrote:
>> Hi,
>>
>> Jun-ichiro itojun Hagino 2.0 wrote:
>> >       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).
>>
>> 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
>>
>>
>>
>> --------------------------------------------------------------------
>> IETF IPv6 working group mailing list
>> [e-mail]
>> Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
>> --------------------------------------------------------------------
>>
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [e-mail]
> Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------

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