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]

Message-ID: <20120308161138.GB23774@kvack.org>
Date:	Thu, 8 Mar 2012 11:11:38 -0500
From:	Benjamin LaHaise <bcrl@...ck.org>
To:	Mitar <mmitar@...il.com>
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

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?

> unmanaged tunnels, but they still require tunnel id and session id
> what (if I assume that they have to be unique) makes it useless for
> our case. We have (if I simplify) a star-shaped topology with a
> central server in the middle. To the central server WiFi nodes
> (hundreds of them) connect. But we do not really want to require from
> a central server to know each WiFi node and prepare its tunnel
> endpoint for each node. We would just like that there would be virtual
> interface and UDP port and any packet send to the UDP port would be
> decapsulated and output through that virtual interface. The only thing
> which we would have to make sure is that each WiFi node has a virtual
> interface with unique MAC address.

L2TP is commonly used for star topology deployments, but with more 
flexibility.  The typical scenario is to use LACs (L2TP Access 
Concentrators) on the edge of the network to tunnel incoming sessions 
from clients to LNSes (L2TP Network servers) that actually perform the 
routing for the network.  There is some state involved, but tunnels can 
be configured without a password, effectively making the addition of new
LACs requiring no manually configured state on the LNS.  The Babylon PPP 
stack that I added L2TP and PPPoE support for is able to perform tunnel 
switching on incoming PPPoE or L2TP sessions.  Sessions can be directed to 
different LNSes based on the username an incoming session authenticates 
as.  It only supports L2TPv2 at present, though, but adding L2TPv3 wouldn't 
be too hard.

		-ben
-- 
"Thought is the essence of where you are now."
--
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