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
| ||
|
Message-ID: <CAKLmikPUo9JTrarmkG66FLurLS2TAwbhDNJA9RB+cFDo7odpFg@mail.gmail.com> Date: Sat, 10 Mar 2012 19:08:29 -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 Sat, Mar 10, 2012 at 9:06 AM, Benjamin LaHaise <bcrl@...ck.org> wrote: > To be honest, I don't see any new stateless protocol actually being widely > supported. Yes, I agree. This is probably because our use case is quite specific: using consumer low-price range network equipment without any dedicated network chips and so on. So simplicity is much more important to use than, for example, security (which we do not care much on VPN links because we already have everything open in the mesh so anybody can capture or inject packets already, so there is no big reason why to do any encryption or authentication (on the link level) on VPN links. > Building a completely proprietary solution (regardless of it > being open source or not) that isn't supported by any common hardware or > software networking platforms will paint yourself into a corner when it > comes time to upgrade the network with additional capacity. That's why I am trying to coordinate our efforts with at least Linux kernel to be included in the kernel. And also, for example, OpenWrt distribution. Then we will mostly cover all our target devices. I am not sure what problems do you have in mind for when upgrading our network with additional capacity? > If you're using Linux as a router, I'd probably lean towards a VLAN based > protocol, as anything exotic won't be supported by common nic's hardware > checksum offloading. I do not understand what VLANs have with tunneling over the Internet? We are building a mesh network, we parts of this network, which do not see each other wirelessly, to connect through VPN tunnels. Because we have cheap hardware we want simplest (CPU light) VPN solution to connect those parts over existing infrastructure (read: ISPs). Furthermore, because nodes are deployed in chaotic and uncoordinated fashion by volunteers those tunnels have to be self-configuring (or zero-configuring). We can provide few VPN servers and all nodes then connect there, connecting nodes connected to them to the rest of the network. > Stateless != robust. To deal with failed links you need some sort of state > that is maintained by the system to switch over to backup links. No. This we do on L3 with dynamic routing protocol (like OLSR) which we are already using because of the wireless nature of our network (and because nodes are coming up and down as volunteers' mothers pull out nodes' power supplies when they are vacuuming). So we just need L2 links. If they work (are not firewalled, VPN servers are online, ...) or not then determines L3 routing protocol and setup routes accordingly. > Existing options (MPLS, GVRP, L2TP) can > all be configured with a minimum amount of state, are widely used for the > scenario you're describing, and have migration paths when you need to > upgrade to higher capacity switches/routers. Will have to check this a bit more. I admit I do not know much about MPLS and GVRP. But true, state is not so big problem if tunnels can still be: - kernel space only - no encryption - zero or auto configuration - one server can accept multiple connections - using UDP (and not IP) for transport - of course, supported in Linux 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