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
