netdev - Re: [PATCH v3 23/30] ipv6: defrag: drop non-last frags smaller than min mtu

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <CALx6S35OVkb_NF85_OhwNktAROEUXGwo+wkQ4RmO64tbj8xWaQ@mail.gmail.com>
Date:   Fri, 11 Jan 2019 19:21:16 -0800
From:   Tom Herbert <tom@...bertland.com>
To:     Michal Kubecek <mkubecek@...e.cz>
Cc:     netdev <netdev@...r.kernel.org>, Peter Oskolkov <posk@...gle.com>,
        Timothy Winters <twinters@....unh.edu>,
        Eric Dumazet <edumazet@...gle.com>,
        Eric Dumazet <eric.dumazet@...il.com>,
        Florian Westphal <fw@...len.de>,
        David Miller <davem@...emloft.net>
Subject: Re: [PATCH v3 23/30] ipv6: defrag: drop non-last frags smaller than
 min mtu

On Fri, Jan 11, 2019 at 10:10 AM Michal Kubecek <mkubecek@...e.cz> wrote:
>
> On Friday, 11 January 2019 18:09 Peter Oskolkov wrote:
> > On Fri, Jan 11, 2019 at 6:54 AM Timothy Winters <twinters@....unh.edu> wrote:
> > > Thanks for the clarification.   I'm thinking about creating a draft
> > > to say no fragments less then 640 unless it's the last fragment.
> > > Does that work for your code going forward?
> >
> > I will prepare a patchset to convert IPv6 defrag queue to rbtree+list,
> > similarly to how IPv4 defrag queue currently works. Just in case it
> > is decided to go this route. I don't think having an
> > arbitrary/non-standard size cap (640) is a good approach.
>
> It's not completely arbitrary. The idea is that two most obvious
> fragment sizing strategies are
>
>   (a) use maximum possible size for all except last, then the rest
>   (b) calculate minimum required fragment count and use (almost) the
>       same size for all of them
>
> Both strategies create non-last fragments of size at least 1280 / 2.
> But I agree that using the same data structure and algorithm as for
> IPv4 is more future proof.
>
Yes, the 640 value is being discussed on 6man. I think the correct
approach might be to turn the limit into a sysctl and make the default
value 640. I'm not sure how, or if this should be applied to IPv4
though.

Tom

> Michal Kubecek
>
>