[Bridge] Encrypting Bridge?

Rene Bartsch Rene at Bartschnet.de
Tue Aug 24 08:13:06 PDT 2004

On Di, 24.08.2004, 01:45, Francois Ambrosini sagte:
> On Mon, 23 Aug 2004 10:31:26 -0700
> Stephen Hemminger <shemminger at osdl.org> wrote:
> [snip]
>> The encrypting bridge isn't a bad idea, just not sure it is worth
>> maintaining
>> yet another VPN solution.
> Greetings,
> IMHO, and in addition to what Rene Bartsch said, providing an encrypted
> tunnel at layer 2 can be really useful when it comes to bandwidth and/or
> latency matters.
> Moreover, paranoid network administrators will always be interested in
> such a feature. It would be the closest solution to direct physical
> encryption without having to buy any special hardware, and without the
> overhead of a layer 3 tunnel (just like the encryption part of WPA is to
> Wi-Fi).
> Alas, adding encryption to the brigde features is not enough: it should
> scale well, meaning that a decent key management system would have to be
> provided as well, in user space. To make things clear, I am only speaking
> of managing the keys on the different nodes of the encrypted switched
> network (no things like authentication, certificates, PKI and alike). On
> the top of that, if direct interoperability with other OSes was to be
> achieved with such a feature, one would have to provide drivers for this
> to work.
> Isn't all this getting outside the limits of the bridge ? Maybe encryption
> should be provided by a seperate piece of code that would stand beetween
> the ethernet driver(s) and the bridge (or the IP stack) ? I am no
> specialist of neither the bridging code nor the networking implementation
> in the Linux kernel, so correct me if I'm going in the wrong direction.

My idea is the following:

If you add an GRE-tunnel to the bridge, you have a OS interoperable and
protocol independent tunneling. That means we just need encryption which
could be done by a additional bridge-nf/netfilter target "enc" with the
options "cipher" and "key".

So, in case of an ebtables rule

ebtables [yourmatches, e.g. "-o gre0"] -t enc --cipher [cipher, e.g. AES]
--key [public key of remote host]

all traffic going to gre0 would pass the target enc which doesn't do
anything else than passing the data and keys to the kernel cipher [cipher]
(e.g. AES) encrypting the data.

And for data coming from the tunnel a rule like

ebtables [yourmatches, e.g. "-i gre0"] -t enc --cipher [cipher, e.g. AES]
--key [private key of local host]

would cause decryption.

And if the PadLock functions of the VIA Nehemia cores could be used, we'd
have powerful but cheap VPN routers.



More information about the Bridge mailing list