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] [thread-next>] [day] [month] [year] [list]

Date:   Fri, 11 Jan 2019 19:10:39 +0100
From:   Michal Kubecek <mkubecek@...e.cz>
To:     netdev <netdev@...r.kernel.org>
Cc:     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>,
        Tom Herbert <tom@...bertland.com>,
        David Miller <davem@...emloft.net>
Subject: Re: [PATCH v3 23/30] ipv6: defrag: drop non-last frags smaller than min mtu

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.

Michal Kubecek