Re: [Openvpn-devel] add a server feature to openvpn to share udp ports ?
> Is it a different problem than with an unknown ip address allowed to connect > to a single port ? > > Does somebody know about an udp server forking and using different ports, with > code available, of course ;-). > > I may be wrong, but I think that it is not common because in the classical > udp servers all the datagramms carry an identifier, or just need a response > and no long term association. Thus there is no need of forking. In the > openvpn case, there is a need of multi packet exchange during tls auth and > afterwards a long term tunnel is established. When I first read this, I thought as you did, no udp server forks like that. Stuff like dns-servers respond as soon as they can and drop what they can't handle. But then nfs-servers struck me. Whatever they do, when they have literally hundreds of udp clients transferring files must work for OpenVPN too. I can't really see a difference between nfs handles and OpenVPN tls-stuff, but that might be me. =) I know NFS is stateless, but in this case I can't see what that might make nfs differ from OpenVPN in regards of handling hundreds of clients that all "call in" on the same udp port (2049 IIRC) and start long conversations with the fileserver. nfs clients might talk less in regards of authentications and have some u_int32 for id, but apart from that, they do function somewhat alike. Just my 0.02 euros. -- Jan Johansson (jan.johans...@biomatsys.com) BioMat System AB Klarabergsgatan 37, III SE-111 21 Stockholm, Sweden Phone: +46-(0)8-233500, Fax: +46-(0)70-3873952 THIS COMMUNICATION IS ONLY INTENDED FOR THE USE OF THE INDIVIDUAL, OR ENTITY, TO WHICH IT IS DIRECTED AND MAY CONTAIN INFORMATION THAT IS PRIVILEGED, CONFIDENTIAL AND EXEMPT FROM DISCLOSURE UNDER APPLICABLE LAW. IF RECEIVED IN ERROR: PLEASE NOTIFY US IMMEDIATELY THROUGH i...@biomatsys.com. signature.asc Description: This is a digitally signed message part
Re: [Openvpn-devel] add a server feature to openvpn to share udp ports ?
Hello all, > > Hi, > > > > I don't know if my idea are really pertinent pertinent, I haven't deeply > read > > the code nor have a lot of experience, but here they are. > > > > > As far as ports are concerned, I am thinking that a forking server > > > implementation of OpenVPN would listen for incoming connections on a > fixed > > > port, but then switch over to a dynamic port to finalize initialization > of > > > the session. > > > > I have read in the libc info page that udp didn't provide listen/accept. > > Thus it seems to me that moving to another port would imply telling back > > the client the new port. Am I wrong ? > > OpenVPN already supports (by --float) replying to a remote peer using a > different port that what the peer is expecting. I think a forking server > would need to allocate a dynamic return port. Is different ports for every client really needed? Ain't there a way to use same port for everyone, like those udp based networked games do? Parent process could use recvfrom to read the socket and then pass the packet on to the correct child via an unix socket. Even better if there are some authentication information in the packets them self, but I don't see ip based packet delivery as a problem since every packet should be identified any way by the child process. I think that using a single port is more simple for firewalls. > > > > > (1) How do you fork on new clients without opening yourself up to DoS > > > attacks? In order to be secure, the server would need to statelessly > > > authenticate the initial packet before forking. Tricky, because SSL/TLS > > > > Why is it required to fork upon first packet reception ? > > Not required, but if you don't it becomes more complicated to deal with > multiple incoming sessions at the same time. Maybe using a pool of preforked threads would be nice. There is some example code for this in Richard Stevens Unix Network Programming > a > > lot of ports > > 2) the tls authentication takes time and requires multi packets exchange. > Thus > > an attacker may try a lot of tls authentications to use server resources. > > This point may be mitigated by the --tls-auth trick, but in case it is > not, > > the combination with forking may lead to a lot of resources used. > > --tls-auth is an effective DoS blocker in a 2-way OpenVPN session because we > use an incrementing timestamp and sequence number to prevent replay > attacks. If a DoS attacker eavesdrops on the wire and copies a bona-fide > packet sequence from a connecting client to generate a packet storm, the > packets would be immediately discarded because of the replay protection > memory (once the peer receives an initial packet). This feature would need > to be adapted to a client-server model because multiple clients would be > connecting and might not have perfectly synchronized clocks. For example, > if one client connected whose clock was 20 minutes ahead, then other clients > (with accurate clocks) would get locked out for 20 minutes because > the --tls-auth replay code would see backtracking timestamps. One way to > fix this would be to persist the replay state (i.e. last timestamp/sequence > number received) for each potential client on disk. But that adds another > layer of complexity and would require the management of a large number of > secondary keys (i.e. the --tls-auth passphrase). Would it be possible to use a logical clock? Like Lamport's logical clock algorithm. I has a quite simple idea, but of course it requires carefull design to avoid any DoSes. I implemented it for one of my school projects and it was not very difficult. > > > initial authentication exchange, but there would need to be verification > > > machinery to ensure that that client could not attack the server by > > > sending it malformed routes. > > > > Is it a different problem than with an unknown ip address allowed to > connect > > to a single port ? > > Well I think the more general problem is one of specifying the server side > configuration for a large number of potential clients that might connect. > The configuration includes --ifconfig endpoints, return routes to client, > and keys (if run in static key mode). If the server dynamically configures > the ifconfig endpoints from an address pool, then it would need to > communicate those addresses back to the client so that it could do the > ifconfig on its end. Preconfigured addresses and routes for eatch client are usefull since connecting to a client from server side requires the address to be static. I see this as one advance of vpns in addition to security, one can connect clients behind dynamic ip addresses. In basic case there could be a config file with client IDs, routes etc. I could also code a database support for the server since that would be cool for managin clients allowed to connect. > Scalability is another issue. There are some good ideas in the open source > world for reducing the number of tunnels in an n-way network. ti
Re: [Openvpn-devel] add a server feature to openvpn to share udp ports ?
On Fri, 28 Jun 2002, Sampo Nurmentaus wrote: > > Hello all, > > > > Hi, > > > > > > I don't know if my idea are really pertinent pertinent, I haven't deeply > > read > > > the code nor have a lot of experience, but here they are. > > > > > > > As far as ports are concerned, I am thinking that a forking server > > > > implementation of OpenVPN would listen for incoming connections on a > > fixed > > > > port, but then switch over to a dynamic port to finalize initialization > > of > > > > the session. > > > > > > I have read in the libc info page that udp didn't provide listen/accept. > > > Thus it seems to me that moving to another port would imply telling back > > > the client the new port. Am I wrong ? > > > > OpenVPN already supports (by --float) replying to a remote peer using a > > different port that what the peer is expecting. I think a forking server > > would need to allocate a dynamic return port. > > > Is different ports for every client really needed? > Ain't there a way to use same port for everyone, > like those udp based networked games do? > > Parent process could use recvfrom to read the socket > and then pass the packet on to the correct child > via an unix socket. Even better if there are some > authentication information in the packets them self, > but I don't see ip based packet delivery as a problem > since every packet should be identified any way by > the child process. > > I think that using a single port is more simple for firewalls. This works in principle, though you have the added inefficiency of the context switch from parent to child, since the parent must now ID and dispatch all incoming packets to the child over the unix socket. Also, identifying the packets by source IP address & port could be a bit tricky if you have more than one tunnel between the same two hosts. I think forking children on a new port would be the easiest to implement, the most efficient, and arguably the most robust, since the child functionality is already perfectly encapsulated by OpenVPN as it exists right now. Of course this method would use more ports and might create firewall complications. > > > > > > > > > (1) How do you fork on new clients without opening yourself up to DoS > > > > attacks? In order to be secure, the server would need to statelessly > > > > authenticate the initial packet before forking. Tricky, because SSL/TLS > > > > > > Why is it required to fork upon first packet reception ? > > > > Not required, but if you don't it becomes more complicated to deal with > > multiple incoming sessions at the same time. > > > Maybe using a pool of preforked threads would be nice. > There is some example code for this in Richard Stevens > Unix Network Programmin Preforked threads are great for a server such as a web server that must deal with a high frequency of incoming, short-term sessions, but I think a VPN server will have more latitude in this area because the frequency of connection requests will be lower and the session duration will be larger. My concern is more along the lines of how to design the system so that a minimum amount of resources is expended in identifying and discarding DoS datagrams. And if we have to wait for TLS authentication to fail on a DoS session, the CPU cycles used by the SSL/TLS authentication code will probably dwarf the fork cost. > > > a > > > lot of ports > > > 2) the tls authentication takes time and requires multi packets exchange. > > Thus > > > an attacker may try a lot of tls authentications to use server resources. > > > This point may be mitigated by the --tls-auth trick, but in case it is > > not, > > > the combination with forking may lead to a lot of resources used. > > > > --tls-auth is an effective DoS blocker in a 2-way OpenVPN session because we > > use an incrementing timestamp and sequence number to prevent replay > > attacks. If a DoS attacker eavesdrops on the wire and copies a bona-fide > > packet sequence from a connecting client to generate a packet storm, the > > packets would be immediately discarded because of the replay protection > > memory (once the peer receives an initial packet). This feature would need > > to be adapted to a client-server model because multiple clients would be > > connecting and might not have perfectly synchronized clocks. For example, > > if one client connected whose clock was 20 minutes ahead, then other clients > > (with accurate clocks) would get locked out for 20 minutes because > > the --tls-auth replay code would see backtracking timestamps. One way to > > fix this would be to persist the replay state (i.e. last timestamp/sequence > > number received) for each potential client on disk. But that adds another > > layer of complexity and would require the management of a large number of > > secondary keys (i.e. the --tls-auth passphrase). > > Would it be possible to use a logical clock? Like Lamport's logical > clock algorithm. I has a quite simple idea, bu
Re: [Openvpn-devel] add a server feature to openvpn to share udp ports ?
On 28 Jun 2002, Jan Johansson wrote: > > > Is it a different problem than with an unknown ip address allowed to connect > > to a single port ? > > > > Does somebody know about an udp server forking and using different ports, > > with > > code available, of course ;-). > > > > I may be wrong, but I think that it is not common because in the classical > > udp servers all the datagramms carry an identifier, or just need a response > > and no long term association. Thus there is no need of forking. In the > > openvpn case, there is a need of multi packet exchange during tls auth and > > afterwards a long term tunnel is established. > > When I first read this, I thought as you did, no udp server forks like > that. Stuff like dns-servers respond as soon as they can and drop what > they can't handle. But then nfs-servers struck me. Whatever they do, > when they have literally hundreds of udp clients transferring files must > work for OpenVPN too. > > I can't really see a difference between nfs handles and OpenVPN > tls-stuff, but that might be me. =) > I know NFS is stateless, but in this case I can't see what that might > make nfs differ from OpenVPN in regards of handling hundreds of clients > that all "call in" on the same udp port (2049 IIRC) and start long > conversations with the fileserver. nfs clients might talk less in > regards of authentications and have some u_int32 for id, but apart from > that, they do function somewhat alike. > > Just my 0.02 euros. Hello Jan, The one problem with making a single thread, multi-client OpenVPN is the SSL/TLS authentication that can take several seconds of processor time. During this time, all tunnel traffic would be locked out. This problem is currently solved in OpenVPN by threading out the SSL/TLS authentication code, but it must be true pre-emptive threading which is not supported on some platforms such as OpenBSD. To do an NFS-style implementation, we would also need to add a session-ID to each packet which would change the protocol and increase the protocol overhead. The other scalability issue would be the maximum number of tun or tap devices that can be allocated. James
