On Wed, Oct 30, 2013 at 10:12 PM, André Valentin <avalen...@marcant.net> wrote: > Add support for floating in tls mode using the HMAC of a packet. It costs > a roundtrip through the clients. Its security comes from a secret key, both > peers have. This key and the data form the signature used, which is then > checked againts existing peer connections. Therefore a good auth algo is > recommended. > > URL: https://community.openvpn.net/openvpn/ticket/49
I took a look at this patch, since I am frustrated by the same problem, so +1 for the conceptual issue. It seems to work: Nov 15 15:18:01 gw ovpn-udp[9964]: hessu/85.188.36.24.36:58639 MULTI: Detected floating by hmac test, new client address: [AF_INET]85.188.36.24.36:58640 Nov 15 15:18:01 gw ovpn-udp[9964]: hessu/85.188.36.24.36:58640 MULTI: Floated with HMAC authentication to a new client address: [AF_INET]85.188.36.24.36:58640 In this case the client's source port changed, because the client is behind a NAT device, and the client didn't have traffic within 60 seconds (the NAT device's UDP session timeout). Without this patch --float does not have any effect on the multi-client tls-server setup, and after a 60-second break in traffic the session is dead (until keepalive ping timeout and reconnection). I'd like to use a large keepalive timer, since on mobile devices a 29-second keepalive tends to drain the battery. I think, however, there might be a problem with the patch: When a packet is received from a srcip-srcport which does not belong to any current client, it goes and scans through the whole client list, calculating a HMAC for the packet contents using the HMAC key of each and every client, effectively looking for a match in HMAC keys. An attacker could transmit large packets with random source IP addresses to a server which has a large number of clients (think 2000 or something? how large client loads are people having, anyway?), and cause extra CPU load, maybe enough to DOS the server with a smallish packet rate. On the other hand, it is commonly quite easy to DOS servers by sheer packet/data volume... but we shouldn't make it any easier with new developments. The more elegant way would be to have a session ID in each data packet, which would used to look up the client, and then a single HMAC calculation would tell if the packet is from that client. No need for scanning. That session ID could be used even for every packet instead of looking at the client IP address+port at all initially (well, for sending any following packets you'd use the peer's latest source address). Putting a session ID in the data packet would require changing the on-the-wire data packet format, and make the packets a bit larger. The ID doesn't have to be very large, though, since it's not secret or used for keying, just an integer large enough to index the maximum number of VPN clients on a single server. This would require a new protocol version, backward compatibility and all that work. - Hessu