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]
Message-ID: <CAKLmikPtvOLgzuSTF=vwfZcMD7jWWRSgWaLxnSxBsa=2RSnPVA@mail.gmail.com>
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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ