netdev - Re: [regression] [analyzed] fragmentation broken for tunnel devices

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]

Date:	Wed, 1 May 2013 09:46:45 +0300
From:	Timo Teras <timo.teras@....fi>
To:	David Miller <davem@...emloft.net>
Cc:	netdev@...r.kernel.org
Subject: Re: [regression] [analyzed] fragmentation broken for tunnel devices

On Wed, 20 Mar 2013 13:46:40 -0400 (EDT)
David Miller <davem@...emloft.net> wrote:

> From: Timo Teras <timo.teras@....fi>
> Date: Wed, 20 Mar 2013 10:13:18 +0200
> 
> Thanks for investigating this issue.
> 
> > 3) Reimplement fragmentation in tunnel devices. This means some
> > duplication of code. But now that there's GRO support in tunnels,
> > this would seem the most performant option.
> 
> I think this is the best option, especially in the long term.

I've been thinking more. It seems there's going to be tricky cases with
this approach too. Looks like ICMP and other non-TCP/UDP packets are
not really sent as GSO/GRO packets. So for those we end up fragmenting
multiple times and end up sending double the amount of packets than
needed.

This would also mean that if we are ever to support new protocols, e.g.
MPLS, we'd get a whole new can of forms when needing fragmentation.

I'm wondering now if it'd be easier to just do the additional
nexthop consultation for forward routes where destination is a tunnel
device.

- Timo
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html