netdev - Re: [tproxy] udp + tproxy

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:	Thu, 13 Nov 2008 09:44:54 +0100
From:	Henrik Nordstrom <henrik@...riknordstrom.net>
To:	Balazs Scheidler <bazsi@...abit.hu>
Cc:	Jan Engelhardt <jengelh@...ozas.de>,
	KOVACS Krisztian <hidden@....bme.hu>,
	Andrey Luzgin <andrey@...msw.com>, tproxy@...ts.balabit.hu,
	netfilter-devel@...r.kernel.org, netdev@...r.kernel.org
Subject: Re: [tproxy] udp + tproxy

On tor, 2008-11-13 at 08:25 +0100, Balazs Scheidler wrote:

> PS: I was talking to Patrick McHardy whether to send the udp_accept()
> patch for kernel inclusion, he said it might be worth trying, however he
> was not completely sure it'd be integrated. So I didn't push it so far.

I second this, but also think that it will see some initial resistance.

I guess the main complaint (assuming code is in good shale) will be that
UDP does not have any sender verification, which means it's very easy to
flood the kernel with UDP "connection requests". But on the other hand
there is also no SYN_RECV or FIN_WAIT/TIME_WAIT states which may hold up
things beyond CPU processing speed so this is not by far as big problem
to deal with as in the TCP case..

Regards
Henrik

Download attachment "signature.asc" of type "application/pgp-signature" (308 bytes)