openvpn-devel

[Openvpn-devel] add a server feature to openvpn to share udp ports ?

[<du...@ce...>]

Hi,

I would like to use openvpn to secure nfs on my network. However, as it is
strictly peer to peer I would have to specify an udp port for every 
client-server nfs relationships. I would have liked to avoid that. Thus I
though it could be a nice addition to openvpn if it ws possible to settle
it as a server, which forks for any childs.

Does it conflicts with the design of openvpn, or could it accepted as a
feature ?

Pat

Re: [Openvpn-devel] add a server feature to openvpn to share udp ports ?

[James Y. <ji...@nt...>]

Hello Pat,

I think it's a good idea, something we're considering for the next release.

James

----- Original Message -----
From: "Patrice DUMAS - DOCT" <du...@ce...>
To: <ope...@li...>
Sent: Friday, June 21, 2002 12:01 PM
Subject: [Openvpn-devel] add a server feature to openvpn to share udp ports
?


> Hi,
>
> I would like to use openvpn to secure nfs on my network. However, as it is
> strictly peer to peer I would have to specify an udp port for every
> client-server nfs relationships. I would have liked to avoid that. Thus I
> though it could be a nice addition to openvpn if it ws possible to settle
> it as a server, which forks for any childs.
>
> Does it conflicts with the design of openvpn, or could it accepted as a
> feature ?
>
> Pat
>
>
> -------------------------------------------------------
> Sponsored by:
> ThinkGeek at http://www.ThinkGeek.com/
> _______________________________________________
> Openvpn-devel mailing list
> Ope...@li...
> https://lists.sourceforge.net/lists/listinfo/openvpn-devel
>

Re: [Openvpn-devel] add a server feature to openvpn to share udp ports ?

[Jan J. <jan...@bi...>]

On Sun, 2002-06-23 at 09:18, James Yonan wrote:
> Hello Pat,
>=20
> I think it's a good idea, something we're considering for the next releas=
e.

I would like to have some info then on how to stop accepting a certain
client certificate, since I base my "expirations" on stopping the port
in question in case I no longer want a specific certificate to be able
to connect to the network. I mean, of course the one-port-per-person
will work after such an addition, but for folks that get in later.

> > Hi,
> >
> > I would like to use openvpn to secure nfs on my network. However, as it=
 is
> > strictly peer to peer I would have to specify an udp port for every
> > client-server nfs relationships. I would have liked to avoid that. Thus=
 I
> > though it could be a nice addition to openvpn if it ws possible to sett=
le
> > it as a server, which forks for any childs.
> >
> > Does it conflicts with the design of openvpn, or could it accepted as a
> > feature ?

--=20
Jan Johansson (jan...@bi...)
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
IN...@BI....

Re: [Openvpn-devel] add a server feature to openvpn to share udp ports ?

[James Y. <ji...@nt...>]

On 24 Jun 2002, Jan Johansson wrote:

> On Sun, 2002-06-23 at 09:18, James Yonan wrote:
> > Hello Pat,
> > 
> > I think it's a good idea, something we're considering for the next release.
> 
> I would like to have some info then on how to stop accepting a certain
> client certificate, since I base my "expirations" on stopping the port
> in question in case I no longer want a specific certificate to be able
> to connect to the network. I mean, of course the one-port-per-person
> will work after such an addition, but for folks that get in later.

One way to stop accepting a certain client certificate is to write a 
--tls-verify script to check the certificate fields.

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.

There are still a number of design issues that need to be worked out such 
as:

(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 
requires a multi-packet exchange to authenticate.

(2) How does the server know which return routes to set up for the client, 
without requiring an --up script on the server for every client that might 
connect?  The client could send its routes to the server as part of the 
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.

If anyone else has ideas on how to securely implement a forking-server, 
please share them with the list.

James

Re: [Openvpn-devel] add a server feature to openvpn to share udp ports ?

[<du...@ce...>]

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 ?
 
> (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 ?

> requires a multi-packet exchange to authenticate.

I think there are 2 distinct possible Dos possible:
1) an attacker may connect many times, to get the server to fork, and open 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.

For 1), I can see 2 possible solutions. 

The first would be to fork only after the tls authentication has been done. 
In that case there are 2 possibilities:
* do tls authentications sequentially. The design could be simple, but the
clients would have to wait for the completion of the tls athentication.
* do tls authentications in parallell. It may be possible to have more
than one tls_multi object, each one associated with a thread (or multiple
calls in case there is no thread). The gain may no be consequent because 
crypto is cpu intensive and not io intensive, and all the clients could
end up waiting approximately the same time.

The second would be to put a limit on the nuber of forked child engaged in 
tls authentication which haven't succeded yet. This would imply having a 
possibility of communication between childs and the server process, to 
notice when the tls auth is done.

> (2) How does the server know which return routes to set up for the client, 
> without requiring an --up script on the server for every client that might 
> connect?  The client could send its routes to the server as part of the 
> 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 ?

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.

Pat

Re: [Openvpn-devel] add a server feature to openvpn to share udp ports ?

[James Y. <ji...@nt...>]

Hi Patrice,

Some comments inline...


> 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.

>
> > (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.

> > requires a multi-packet exchange to authenticate.
>
> I think there are 2 distinct possible Dos possible:
> 1) an attacker may connect many times, to get the server to fork, and open
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).

>
> For 1), I can see 2 possible solutions.
>
> The first would be to fork only after the tls authentication has been
done.
> In that case there are 2 possibilities:
> * do tls authentications sequentially. The design could be simple, but the
> clients would have to wait for the completion of the tls athentication.
> * do tls authentications in parallell. It may be possible to have more
> than one tls_multi object, each one associated with a thread (or multiple
> calls in case there is no thread). The gain may no be consequent because
> crypto is cpu intensive and not io intensive, and all the clients could
> end up waiting approximately the same time.
>
> The second would be to put a limit on the nuber of forked child engaged in
> tls authentication which haven't succeded yet. This would imply having a
> possibility of communication between childs and the server process, to
> notice when the tls auth is done.

The problem here is that a DoS attacker could easily lock up the
pre-authenticated session quota, and then those authentication slots would
be tied up for --hand-window seconds (60 seconds by default), until the TLS
authentication layer times out.

> > (2) How does the server know which return routes to set up for the
client,
> > without requiring an --up script on the server for every client that
might
> > connect?  The client could send its routes to the server as part of the
> > 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.

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. tinc for
example will use broadcasts and MAC address discovery over a tap (virtual
ethernet) tunnel to deduce the destination of the packets, and allow one tap
tunnel to connect to n peers.

> 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.
>
> Pat

Best Regards,
James

Re: [Openvpn-devel] add a server feature to openvpn to share udp ports ?

[Sampo N. <aud...@au...>]

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. tinc for
> example will use broadcasts and MAC address discovery over a tap (virtual
> ethernet) tunnel to deduce the destination of the packets, and allow one tap
> tunnel to connect to n peers.

What stops servers from connecting to another servers forming a
hierarcy of nodes? This makes it possible to reduce number of
clients per server. Of course this also requires the servers to
be able to exchange routing information, but that does not have
to be taken care by openvpn.



Best regards,
Sampo Nurmentaus

Re: [Openvpn-devel] add a server feature to openvpn to share udp ports ?

[James Y. <ji...@nt...>]

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, 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.

I did look at the Lamport Clock algorithm but I'm not sure we can use it 
to make an n-way --tls-auth.  Because suppose that a new client is 
connecting.  The Lamport timestamp on its session-initiating datagram will 
be stale until it gets a a response from the server.  But our goal is to 
construct the session-initiating datagram so that it has enough 
information (without requiring any multi-packet handshake) to allow a fast 
valid or DoS classification. 

> 
> > > > 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.

I would like to see the dynamic client-server features implemented as a
module that would instantiate OpenVPN's core peer-to-peer code for each
new session.  It would also be nice if we could do it without changing the 
protocol or making too many changes to the core peer-to-peer code which is 
nicely stable and robust right now.

> 
> > 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. tinc for
> > example will use broadcasts and MAC address discovery over a tap (virtual
> > ethernet) tunnel to deduce the destination of the packets, and allow one tap
> > tunnel to connect to n peers.
> 
> What stops servers from connecting to another servers forming a
> hierarcy of nodes? This makes it possible to reduce number of
> clients per server. Of course this also requires the servers to
> be able to exchange routing information, but that does not have
> to be taken care by openvpn.

It's nice if the OS can take care of routing.  But if we leave routing up 
to the OS (as we do now), then the VPN must deal with potentially a
large number of tun or tap devices in an n-way network, and scalability 
could become an issue.
 
> Best regards,
> Sampo Nurmentaus
> 

Thanks,
James

Re: [Openvpn-devel] add a server feature to openvpn to share udp ports ?

[Sampo N. <aud...@au...>]

Hi James,

I do agree that forking and using a new port is a good solution due to
it's simplicity. And fork cost ain't much for normal traffic since it's
done only once per tunnel opening.

There could also be a limit for the speed new childs are forked. Since it
does not matter if it takes a while to creat a new tunnel, one could set a
limit that new connection is accepted only after previous hand shaking is
finished. This would reduce the possibility of a DoS attack.

After client and server have exchanged the port information and server has
forked both could sent a few dummy packets to the new port at the other
end to allow the statefull firewalls in both ends to notice the
connection. Don't know how well this would work but think that it is worth
trying.


Sampo


> >
> > 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, 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.
>
> I did look at the Lamport Clock algorithm but I'm not sure we can use it
> to make an n-way --tls-auth.  Because suppose that a new client is
> connecting.  The Lamport timestamp on its session-initiating datagram will
> be stale until it gets a a response from the server.  But our goal is to
> construct the session-initiating datagram so that it has enough
> information (without requiring any multi-packet handshake) to allow a fast
> valid or DoS classification.
>
> >
> > > > > 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.
>
> I would like to see the dynamic client-server features implemented as a
> module that would instantiate OpenVPN's core peer-to-peer code for each
> new session.  It would also be nice if we could do it without changing the
> protocol or making too many changes to the core peer-to-peer code which is
> nicely stable and robust right now.
>
> >
> > > 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. tinc for
> > > example will use broadcasts and MAC address discovery over a tap (virtual
> > > ethernet) tunnel to deduce the destination of the packets, and allow one tap
> > > tunnel to connect to n peers.
> >
> > What stops servers from connecting to another servers forming a
> > hierarcy of nodes? This makes it possible to reduce number of
> > clients per server. Of course this also requires the servers to
> > be able to exchange routing information, but that does not have
> > to be taken care by openvpn.
>
> It's nice if the OS can take care of routing.  But if we leave routing up
> to the OS (as we do now), then the VPN must deal with potentially a
> large number of tun or tap devices in an n-way network, and scalability
> could become an issue.
>
> > Best regards,
> > Sampo Nurmentaus
> >
>
> Thanks,
> James
>
>
>

Re: [Openvpn-devel] add a server feature to openvpn to share udp ports ?

[James Y. <ji...@nt...>]

> Hi James,
>
> I do agree that forking and using a new port is a good solution due to
> it's simplicity. And fork cost ain't much for normal traffic since it's
> done only once per tunnel opening.
>
> There could also be a limit for the speed new childs are forked. Since it
> does not matter if it takes a while to creat a new tunnel, one could set a
> limit that new connection is accepted only after previous hand shaking is
> finished. This would reduce the possibility of a DoS attack.

I would suggest that the first version allows one new connection once every
n seconds, where n is a parameter.

Later versions might have a more sophisticated form of --tls-auth to do the
same.

> After client and server have exchanged the port information and server has
> forked both could sent a few dummy packets to the new port at the other
> end to allow the statefull firewalls in both ends to notice the
> connection. Don't know how well this would work but think that it is worth
> trying.

This might work with the existing --ping option which does the same for
current OpenVPN peer-to-peer sessions.

James

>
>
> Sampo
>
>
> > >
> > > 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, 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.
> >
> > I did look at the Lamport Clock algorithm but I'm not sure we can use it
> > to make an n-way --tls-auth.  Because suppose that a new client is
> > connecting.  The Lamport timestamp on its session-initiating datagram
will
> > be stale until it gets a a response from the server.  But our goal is to
> > construct the session-initiating datagram so that it has enough
> > information (without requiring any multi-packet handshake) to allow a
fast
> > valid or DoS classification.
> >
> > >
> > > > > > 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.
> >
> > I would like to see the dynamic client-server features implemented as a
> > module that would instantiate OpenVPN's core peer-to-peer code for each
> > new session.  It would also be nice if we could do it without changing
the
> > protocol or making too many changes to the core peer-to-peer code which
is
> > nicely stable and robust right now.
> >
> > >
> > > > 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. tinc
for
> > > > example will use broadcasts and MAC address discovery over a tap
(virtual
> > > > ethernet) tunnel to deduce the destination of the packets, and allow
one tap
> > > > tunnel to connect to n peers.
> > >
> > > What stops servers from connecting to another servers forming a
> > > hierarcy of nodes? This makes it possible to reduce number of
> > > clients per server. Of course this also requires the servers to
> > > be able to exchange routing information, but that does not have
> > > to be taken care by openvpn.
> >
> > It's nice if the OS can take care of routing.  But if we leave routing
up
> > to the OS (as we do now), then the VPN must deal with potentially a
> > large number of tun or tap devices in an n-way network, and scalability
> > could become an issue.
> >
> > > Best regards,
> > > Sampo Nurmentaus
> > >
> >
> > Thanks,
> > James
> >
> >
> >
>

Re: [Openvpn-devel] add a server feature to openvpn to share udp ports ?

[Jan J. <jan...@bi...>]

> Is it a different problem than with an unknown ip address allowed to conn=
ect
> to a single port ?
>=20
> Does somebody know about an udp server forking and using different ports,=
 with
> code available, of course ;-).
>=20
> I may be wrong, but I think that it is not common because in the classica=
l=20
> udp servers all the datagramms carry an identifier, or just need a respon=
se
> 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 an=
d
> 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. =3D)
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.=20

Just my 0.02 euros.

--=20
Jan Johansson (jan...@bi...)
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
IN...@BI....

Re: [Openvpn-devel] add a server feature to openvpn to share udp ports ?

[James Y. <ji...@nt...>]

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