On Di, 24.08.2004, 01:45, Francois Ambrosini sagte: > On Mon, 23 Aug 2004 10:31:26 -0700 > Stephen Hemminger <shemminger@xxxxxxxx> 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. Comments? Rene
