Juul
commented
9 years ago We also need to figure out on which interface the requests are being received. If the interfaces are bridged this is probably not possible. Here's a possible solution though: For the public network there is one VLAN and for the private network there is another VLAN. The ports that are configured to be part of public or private are simply configured with swconfig such that the public ports are on the public VLA and the private ports are on the private VLAN, and in addition the ports are configured to untag outgoing packets and to send incoming untagged packets on each port to the right VLAN (public or private). Ok, that's all well and good, but we're ALSO going to create one VLAN per port such that each port will also be part of its own VLAN. notdhcpserver will then bind to each of these single-port VLAN interfaces and hand out one IP per interface. For this to work the notdhcpclient would have to send request packets on all VLANs. There might be an easy way to do this, but if there isn't then the hard way is to use raw sockets to transmit (we are already using packet sockets, so not the biggest change) and simple construct the ethernet header with the VLAN tag of choice, cycling requests over all VLANs.
paidforby
We'd like to be able to automatically switch LAN ports from whatever they're doing to being dedicated extender-mode ports when an extender-node is plugged in.
We'll have to alter the protocol such that an IP is first assigned and only once the extender-node-connected interface on the home node is removed from the bridge is the SSL cert sent, otherwise everyone will just receive it (given that it's a broadcast packet) and there ain't much we can do about it (if we take into account ARP spoofing).
There are other security concerns: Let's take the example where we have all four LAN ports bridged to the public wifi interface. An extender-node is plugged into one of these ports and emits a notdhcp request. Now anyone connected to the public interface, whether with ethernet or wifi, can respond to that request as if they were the home node, and if they respond faster than the homenode then they gain some level of control over the extender node. A potential solution in this scenario is to use ebtables to block incoming UDP packets from the notdhcp server port and to the notdhcp client port that also have 0.0.0.0 as their source IP and 255.255.255.255 as their destination IP. However, we might just want to block any incoming/forward broadcast packets with ebtables since there is no reason for anyone to broadcast to the node-local clients on the open network. In fact, this will also eliminate rogue DHCP servers as a problem.
The third problematic scenario is where a client on the public network pretends to be a client node and requests an IP and a cert from the home node's notdhcp server. Since we're currently handing out the same SSL cert to all extender node's that would give the malicious client the ability to control all extender nodes. We should instead generate per-node SSL certs on the fly as they are requested. One potential issue with this is that a DoS attack could be easily implemented by continuously asking the server to generate new SSL certs.