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 <[EMAIL PROTECTED]> 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
[email protected]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email protected]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email protected]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
