netdev - Re: Ethernet-over-UDP virtual network interface

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:	Sat, 10 Mar 2012 08:31:28 -0800
From:	Mitar <mmitar@...il.com>
To:	Benjamin LaHaise <bcrl@...ck.org>
Cc:	netdev@...r.kernel.org, Nejc Skoberne <nejc@...berne.net>,
	Jernej Kos <kostko@...matrix-one.org>, gw.2012@...de.com
Subject: Re: Ethernet-over-UDP virtual network interface

Hi!

On Thu, Mar 8, 2012 at 8:11 AM, Benjamin LaHaise <bcrl@...ck.org> wrote:
> On Tue, Mar 06, 2012 at 12:58:44AM +0100, Mitar wrote:
>> I would like something state-less. I see L2TPv3 has support for
>
> How stateless?

Stateless in the ethernet-like manner: each incoming packet is simply
decapsulated and seen as it came over the (virtual) ethernet wire.

Of course this is because I have one implementation of our needs in my
head. Probably stateless is not necessary if everything is done
automatically. But what I am saying is that it could be even
stateless, something very very simple (and efficient). That we do not
need state/sessions (on a tunnel level, of course on the IP level of
packets send around then network kernel can (and should) keep state).
Not much CPU computation, not much memory copying, no user-space
context switching.

The idea is that we need a very simple solution, robust, no
encryption, no authentication. Just to improve the throughput on
consumer routers (today with N protocol you can easily have 15Mbit/s+
links and with fiber to tunnel them further this means that CPU is
often a bottleneck).

As I see there is no simple (both in implementation and configuration
manner) solution to this problem yet? Would it be then interesting to
develop such kernel module as I described in my initial post? Is there
any chance of it being accepted into the kernel?

Mitar
--
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