openvpn-devel — OpenVPN developers list

[Openvpn-devel] OpenVPN 1.3.0 Released

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

Download:

http://sourceforge.net/projects/openvpn/

Release Notes:

This is a housekeeping release containing minor fixes and finishing touches
on larger features introduced in previous versions. The version number has
incremented to 1.3.x due to a change in default MTU values.

The default values for --udp-mtu and --tun-mtu have been lowered to 1300 as
a conservative measure to reduce the possibility of packet fragmentation and
loss for users who do not explicitly set a value.

If you are using OpenVPN 1.3.0 to connect to previous versions of OpenVPN,
you should set the MTU explicitly on both peers, keeping in mind that in
pre-1.3.0 versions of OpenVPN, --udp-mtu defaulted to 1500 and --tun-mtu
defaulted to 1450.

Change Log from 1.2.1 -> 1.3.0:

* Added --dev-node option to allow explicit selection of
  tun/tap device node.
* Removed mlockall call from child thread, as it doesn't
  appear to be necessary (child thread inherits mlockall
  state from parent).
* Added --ping-timer-rem which causes timer for --ping-exit
  and --ping-restart not to run unless we have a remote IP
  address.
* Added condrestart to openvpn.init and openvpn.spec
  (Bishop Clark).
* Added --ifconfig case for FreeBSD (Matthias Andree).
* Call openlog with facility=LOG_DAEMON (Matthias Andree).
* Changed LOG_INFO messages to LOG_NOTICE.
* Added warning when key files are group/others accessible.
* Added --single-session flag for TLS mode.
* Fixed bug where --writepid would segfault if used with
  an invalid filename.
* Fixed bug where --ipchange status message was formatted
  incorrectly.
* Print more concise error message when system() call
  fails.
* Added --disable-occ option.
* Added --local, --remote, and --ifconfig options sanity
  check.
* Changed default UDP MTU to 1300 and TUN/TAP MTU to
  1300.
* Successfully tested with OpenSSL 0.9.7 Beta 2.
* Broke out debug level definitions to errlevel.h
* Minor documentation and web site changes.
* All changes maintain protocol compatibility
  with OpenVPN versions since 1.1.0, however default
  MTU changes will require setting the MTU explicitly
  by command line option, if you want 1.3.0 to
  communicate with previous versions.

James

Re: [Openvpn-devel] Default MTU

[Matthias A. <mat...@st...>]

On Sun, 07 Jul 2002, James Yonan wrote:

> (1) Static, pre-shared key mode is stateless and handshake-free, so there
> isn't really an existing context in which PMTU discovery could be
> implemented.

Must the MTU be known to the protocol after all? It might be assymmetric
when asymmetric routing (satellite downlink with ISDN uplink) is in
place.

Is not it sufficient if your own secure PMTU discovery is done
independently for either side? Sorry, I'm still not acquainted with the
OpenVPN protocol for lack of time.

> (2) Path MTU discovery could work in TLS mode, however every time the the
> MTU changes, the tun or tap device would need to be re-ifconfiged -- this
> might also involve closing and reopening the tun device which would fail =
if
> root privileges have been dropped.

If you do it in the application, yes. If you leave it to the kernel,
then it's not necessary.

> So at this point a static default is certainly the simpler way to go, but
> any changes to the static default should be carefully considered since th=
ey
> would introduce backward incompatibility issues.

--=20
Matthias Andree

Re: [Openvpn-devel] Default MTU

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

On 8 Jul 2002, Jan Johansson wrote:

> On Sun, 2002-07-07 at 22:19, James Yonan wrote:
> > What should the default MTU be?
> > 
> > Right now the default UDP MTU is 1500 if you use --ifconfig, which is
> > probably too high, because as Matthias Andree pointed out, 1500 + IP header
> > size is greater than 1500 and will cause fragmentation on ethernet networks
> > where the MTU is 1500.
> > 
> > 1450 might make more sense because that leaves ample space for the IP
> > header, forming a total packet size of less than 1500.
> 
> > So at this point a static default is certainly the simpler way to go, but
> > any changes to the static default should be carefully considered since they
> > would introduce backward incompatibility issues.
> 
> I'd go for 1300 or so. Even if 1450 works now, you could still encounter
> more issues later that require another change. I don't think the
> performance loss will be that great, since all that run TLS now with
> 1500-ish packetsizes probably already split lots of packets into one
> large and one tiny packet as it is.

I'm inclined to agree that the default MTU should be set conservatively 
low so it has a high probability of working, even if it is slightly less 
efficient.

Once somebody has a setup working, they will be in a better position to 
optimize the MTU to their liking.
 
> If you are to go for new major version that breaks compat, go for lower
> defaults on MTU too. You might aswell backport some sort of small logic
> for the older OpenVPN-track that tries the lower MTU in case it seems
> like it doesn't work, or a "--compat-v2" setting.

I plan to increment the version number to 1.3.0 due to the default MTU
change, though there won't be any other breaks in compatibility, and of 
course 1.3.0 will be able to talk to previous versions simply by defining 
MTU size explicitly in the config.

James

[Openvpn-devel] Re: OpenVPN and UDP fragmentation

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

On Mon, 8 Jul 2002, Matthias Andree wrote:

> On Tue, 02 Jul 2002, James Yonan wrote:
> 
> > At one point I considered using adaptive code to automatically set the
> > MTU, then I read a paper that described various DoS attacks against common
> > path MTU discovery algorithms, so I held off on that.
> 
> Is not the kernel itself also susceptible in that case unless PMTU
> discovery is disabled for that route?

Right, you would need to set the Don't Fragment bit in the socket to 
disable the kernel's PMTU then implement your own secure PMTU.

> 
> OTOH, I haven't read a single paper on PMTU discovery DoS attacks, so
> I cannot comment on the details.

http://www.off.net/~jme/ietf/draft-etienne-secure-pmtud-00.txt

> 
> > It would be great if there was an easy way of getting the dynamic path MTU 
> > from the OS, but I'm not aware of any portable method to do this.
> > 
> > While reducing the default to 1472 or lower might work, it would also
> > break compatibility...  right now we can brag that the protocol hasn't
> > changed since 1.1.0, and while this isn't really a protocol change, it
> > does introduce a slight incompatibility with prior versions.  I would
> > prefer to hold off on patches that break compatibility until 1.3.0.
> 
> Sure. Documenting that the admin who sets up OpenVPN should experiment
> with the UDP-MTU and lower it until no fragmentation occurs is fine with
> me.
> 
> > > If OpenVPN adapting the UDP MTU, I'd appreciate if the adaption progress
> > > would be logged akin to LZO adaption.
> > 
> > There is a common algorithm known as Path MTU Discovery where you set the 
> > Don't Fragment bit on the socket then figure out by heuristics the largest 
> > packet size that will get through.  But it would be better to let the OS 
> > figure this out and then tell us in a portable way, if this is possible.
> 
> Yes. I recently made some experiences with obtaining interface/netmask
> configuration. Don't try this for IPv6, it'll boggle your mind. Each
> system has its own approach. Netlink, a "long" SIOCGIFNETMASK variant,
> whatever.
> 
> > > Again, please apologize if I wrote nonsense, I'm not really aware of the
> > > packet encapsulation and framing process in OpenVPN.
> > 
> > No, your ideas are good.  In fact I would vote that we move these 
> > discussions to openvpn-devel so that more people can participate.
> 
> OK, I'll look at that list then. Feel free to bounce this mail and my
> last one there so people know what we're talking about.
> 
> Thanks,
> 
> 

Re: [Openvpn-devel] Default MTU

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

On Sun, 2002-07-07 at 22:19, James Yonan wrote:
> What should the default MTU be?
>=20
> Right now the default UDP MTU is 1500 if you use --ifconfig, which is
> probably too high, because as Matthias Andree pointed out, 1500 + IP head=
er
> size is greater than 1500 and will cause fragmentation on ethernet networ=
ks
> where the MTU is 1500.
>=20
> 1450 might make more sense because that leaves ample space for the IP
> header, forming a total packet size of less than 1500.

> So at this point a static default is certainly the simpler way to go, but
> any changes to the static default should be carefully considered since th=
ey
> would introduce backward incompatibility issues.

I'd go for 1300 or so. Even if 1450 works now, you could still encounter
more issues later that require another change. I don't think the
performance loss will be that great, since all that run TLS now with
1500-ish packetsizes probably already split lots of packets into one
large and one tiny packet as it is.

If you are to go for new major version that breaks compat, go for lower
defaults on MTU too. You might aswell backport some sort of small logic
for the older OpenVPN-track that tries the lower MTU in case it seems
like it doesn't work, or a "--compat-v2" setting.

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

[Openvpn-devel] new beta available

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

Download:

http://openvpn.sourceforge.net/beta/openvpn-1.2.1.10.tar.gz

Changes since 1.2.1:

* Added --dev-node option to allow explicit selection of
  tun/tap device node.
* Removed mlockall call from child thread, as it doesn't
  appear to be necessary (child thread inherits mlockall
  state from parent).
* Added --ping-timer-rem which causes timer for --ping-exit
  and --ping-restart not to run unless we have a remote IP
  address.
* Added condrestart to openvpn.init and openvpn.spec
  (Bishop Clark).
* Added --ifconfig case for FreeBSD (Matthias Andree).
* Call openlog with facility=LOG_DAEMON (Matthias Andree).
* Changed LOG_INFO messages to LOG_NOTICE.
* Added warning when key files are group/others accessible.
* Added --single-session flag for TLS mode.
* Fixed bug where --writepid would segfault if used with
  an invalid filename.
* Fixed bug where --ipchange status message was formatted
  incorrectly.
* Print more concise error message when system() call
  fails.
* Added --disable-occ option.
* Added --local, --remote, and --ifconfig options sanity
  check.
* Changed default UDP MTU to 1450 and TUN/TAP MTU to
  1400.
* Successfully tested with OpenSSL 0.9.7 Beta 2.
* Broke out debug level definitions to errlevel.h
* Minor documentation and web site changes.
* All changes maintain protocol compatibility
  with OpenVPN versions since 1.1.0, however default
  MTU changes will require setting the MTU explicitly
  by command line option, if you want MYVERSION to
  communicate with previous versions.

James

[Openvpn-devel] Default MTU

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

What should the default MTU be?

Right now the default UDP MTU is 1500 if you use --ifconfig, which is
probably too high, because as Matthias Andree pointed out, 1500 + IP header
size is greater than 1500 and will cause fragmentation on ethernet networks
where the MTU is 1500.

1450 might make more sense because that leaves ample space for the IP
header, forming a total packet size of less than 1500.

Then again there are arguments for even lower values, 1350 or 1300 to allow
multiple levels of encapsulation such as PPPoE, IP, ethernet, etc.

It would also be possible to set the MTU automatically through some sort of
initial or ongoing handshake that does secure pings of various packet sizes
with the Don't Fragment bit set to determine the optimal MTU for the path
(i.e. Secure Path MTU Discovery).

With OpenVPN however, there are some complications to the automatic Path MTU
discovery approach:

(1) Static, pre-shared key mode is stateless and handshake-free, so there
isn't really an existing context in which PMTU discovery could be
implemented.

(2) Path MTU discovery could work in TLS mode, however every time the the
MTU changes, the tun or tap device would need to be re-ifconfiged -- this
might also involve closing and reopening the tun device which would fail if
root privileges have been dropped.

(3) Path MTU discovery in a secure application such as a VPN must itself be
secure to protect against DoS attacks, so the standard garden-variety PMTU
approaches that depend on return ICMP packets probably won't work securely
or reliably.

So at this point a static default is certainly the simpler way to go, but
any changes to the static default should be carefully considered since they
would introduce backward incompatibility issues.

Comments?

James

Re: [Openvpn-devel] Protocol Change policy

[Matthias A. <mat...@st...>]

On Tue, 02 Jul 2002, James Yonan wrote:

> Here are some answers that come to mind:
>=20
> (1) Accumulate such patches and merge them all at once in a future release
> such as 1.3.0 or 2.0.0, while warning users that this release will not be
> backward compatible.

That's the way to go. Anything else adds too much complexity.

--=20
Matthias Andree

Re: [Openvpn-devel] Protocol Change policy

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

I agree,

I think that allowing the usage of multiple,
possibly old, protocols adds complexity and
may couse some vulnerabilities.

A cracker could force the daemon to use
some old protocol with security holes
fixed in later versions.


Sampo


> > I'd like to hear your opinions on how the OpenVPN project should handle
> > patches which break backward compatibility.
> > Here are some answers that come to mind:
> >
> > (1) Accumulate such patches and merge them all at once in a future release
> > such as 1.3.0 or 2.0.0, while warning users that this release will not be
> > backward compatible.
>
> I'd prefer this one. Even though ssh seems to work nicely, you wind up
> (at least when you have versions 1.3, 1.5 and 2) with lots of weird code
> that you can't figure out if it runs or not.
>
> I'd like the more clean model without too much #ifdefs. With several
> platforms and stuff, you'll have enough of those anyhow. =)
>
>

Re: [Openvpn-devel] Protocol Change policy

[Alberto G. I. <ag...@ag...>]

On Wed, Jul 03, 2002 at 11:16:14AM +0200, Jan Johansson wrote:
> On Tue, 2002-07-02 at 20:34, James Yonan wrote: 
> > I'd like to hear your opinions on how the OpenVPN project should handle
> > patches which break backward compatibility.
> > Here are some answers that come to mind:
> > 
> > (1) Accumulate such patches and merge them all at once in a future release
> > such as 1.3.0 or 2.0.0, while warning users that this release will not be
> > backward compatible.
> 
> I'd prefer this one. Even though ssh seems to work nicely, you wind up 
> (at least when you have versions 1.3, 1.5 and 2) with lots of weird code
> that you can't figure out if it runs or not.
> 
> I'd like the more clean model without too much #ifdefs. With several
> platforms and stuff, you'll have enough of those anyhow. =)

I agree with Jan. Clean and simple. It works.
Warning users some versions before the change will reduce 'problems' a lot,
it's a good idea.

On the 'protocol version' subject, I think it could be a cool feature, 
specially if newer versions are backwards compatible. But IMHO it a hard
thing to develop and in case of being developed should wait until all
(today's) whished featured are implemented. I mean, (maybe) introducing
'protocol versions' too soon will end in too many versions, or waiting
for new features too much to avoid releasing new protocol versions.
(I don't know if I'm clear in this point, some times my English level 
seems not enough :-)

Regards,

Alberto


-- 
Alberto Gonzalez Iniesta       | They that give up essential liberty
ag...@ag...                     | to obtain a little temporary safety
Encrypted mail preferred       | deserve neither liberty nor safety.

Key fingerprint = 9782 04E7 2B75 405C F5E9  0C81 C514 AF8E 4BA4 01C3

Re: [Openvpn-devel] Protocol Change policy

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

On Tue, 2002-07-02 at 20:34, James Yonan wrote:=20
> I'd like to hear your opinions on how the OpenVPN project should handle
> patches which break backward compatibility.
> Here are some answers that come to mind:
>=20
> (1) Accumulate such patches and merge them all at once in a future releas=
e
> such as 1.3.0 or 2.0.0, while warning users that this release will not be
> backward compatible.

I'd prefer this one. Even though ssh seems to work nicely, you wind up=20
(at least when you have versions 1.3, 1.5 and 2) with lots of weird code
that you can't figure out if it runs or not.

I'd like the more clean model without too much #ifdefs. With several
platforms and stuff, you'll have enough of those anyhow. =3D)

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

[Openvpn-devel] Protocol Change policy

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

I'd like to hear your opinions on how the OpenVPN project should handle
patches which break backward compatibility.

There are a couple of (as yet unapplied) patches in the queue that change
the OpenVPN protocol including parameter defaults that affect the protocol:

(1) Add device type (tun | tap | null) to TLS handshake string for
compatibility check between peers.

(2) Reduce default --udp-mtu to 1450 from 1500 when --ifconfig is used
(Matthias Andree noticed a lot of fragmentation with the default setting of
1500).

The question is how should protocol changes be introduced so that they don't
cause a lot of pain due to the loss of backward compatibility, but at the
same time not introduce lots of complexifying cruft into the code?

Here are some answers that come to mind:

(1) Accumulate such patches and merge them all at once in a future release
such as 1.3.0 or 2.0.0, while warning users that this release will not be
backward compatible.

(2) Merge changes immediately but #ifdef them out by default until some
future planned release.  The user would have to build with an explicit
./configure option to enable, or wait for the future planned release when
the protocol changes would be enabled by default.  This is similar to how
python handles language changes with the "from future" tag --
http://www.python.org/peps/pep-0236.html

(3) Merge changes immediately but provide a ./configure option to build for
previous protocol version.

(4) Use explicit protocol version numbers as SSH or NFS does.

(5) Use a command line option such as "--peer-version 1.1.0" to allow a
given OpenVPN version to downgrade its protocol to talk to an old version.

1, 2, and 3 are the easiest to implement as they handle the version number
choice at build time.  4 and 5 do it at run time which is more convenient
for the user, but would add considerable cruft to the code.

Comments?

James

Re: [Openvpn-devel] --cert and --key

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

> Hello all,
>
> I'm confusing with TLS Mode Options.
>
> in Man Page:
> --cert file  Peer's signed certificate in .pem
> --key file   My private key in .pem
> but in Example 3:
> openvpn ... --cert client.crt --key client.key ...
> openvpn ... --cert server.crt --key server.key ...
>
> OpenVPN 1.2.1 works fine with the example,
> but I don't know which is appropriate description for SSL security.
> Which is right?
>
> Thanks in advance,
>
> TANABE Hiroyasu

That's a good point and deserves clarification.  --cert and --key should
point to the local machine's certificate and key.  So the man page should
read something like:

--cert file  Local signed certificate in .pem
--key file   Local private key in .pem

Basically each computer that runs OpenVPN should have it's own
certificate/key pair, signed by the root certificate which is specified
in --ca.

When 2 OpenVPN peers connect, each presents its local certificate to the
other.  Each peer will then check that its partner peer presented a
certificate which was signed by the master --ca certificate.

If that check succeeds, then the TLS negotiation will succeed, both OpenVPN
peers will exchange temporary session keys, and the tunnel will begin
passing data.

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

[Openvpn-devel] --cert and --key

[TANABE H. <h...@co...>]

Hello all,

I'm confusing with TLS Mode Options.

in Man Page:
	--cert file  Peer's signed certificate in .pem 
	--key file   My private key in .pem 
but in Example 3:
	openvpn ... --cert client.crt --key client.key ...
	openvpn ... --cert server.crt --key server.key ...

OpenVPN 1.2.1 works fine with the example, 
but I don't know which is appropriate description for SSL security.
Which is right?

Thanks in advance,

TANABE Hiroyasu

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

[Openvpn-devel] Pre-1.2.2 beta available, please test

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

I plan to release 1.2.2 in a few days if there are no problems with this
beta.

Download:

http://openvpn.sourceforge.net/beta/openvpn-1.2.1.8.tar.gz

Changes since 1.2.1:

* Added --dev-node option to allow explicit selection of
  tun/tap device node.
* Removed mlockall call from child thread, as it doesn't
  appear to be necessary (child thread inherits mlockall
  state from parent).
* Added --ping-timer-rem which causes timer for --ping-exit
  and --ping-restart not to run unless we have a remote IP
  address.
* Added condrestart to openvpn.init and openvpn.spec
  (Bishop Clark).
* Added --ifconfig case for FreeBSD (Matthias Andree).
* Call openlog with facility=LOG_DAEMON (Matthias Andree).
* Changed LOG_INFO messages to LOG_NOTICE.
* Added warning when key files are group/others accessible.
* Added --single-session flag for TLS mode.
* Fixed bug where --writepid would segfault if used with
  an invalid filename.
* Fixed bug where --ipchange status message was formatted
  incorrectly.
* Print more concise error message when system() call
  fails.
* All changes maintain protocol compatibility with OpenVPN
  versions since 1.1.0.

James

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

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

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 ?

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

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 ?

[<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] Features comments/request

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

----- Original Message -----
From: "Alberto Gonzalez Iniesta" <ag...@ag...>
To: "James Yonan" <ji...@nt...>
Cc: <ope...@li...>
Sent: Thursday, June 27, 2002 1:26 AM
Subject: Re: [Openvpn-devel] Features comments/request


> On Tue, Jun 25, 2002 at 10:02:18AM -0600, James Yonan wrote:
> > Hi Alberto,
> >
> > > I'd like to ask for a couple of features (little ones) added to
OpenVPN.
> > > Comments welcomed.
> > >
> > > 1) OpenVPN should refuse to start a connection based on shared secret
> > > when the file containing that key is world readable (or writable).
> > > Paranoia won't even like group readable :-)
> > Good idea, however what if someone doesn't want to deal with the
protections
> > on every file and instead just eliminates group/world access to the key
> > directory?  Therefore, erring on the individual file protections could
> > create a false sense of paranoia?
>
> Hi James,
>
> Yes, forcing directory security could be a better solution, but what
> happens if the user wants to keep the key in a directory like /etc? or
> /usr/local/etc? From my point of view (Debian's package) there's no
> problem, I'll probably go for a /etc/openvpn/secrets directory, but just
> wanted to note this in case you wanted to think about it.

I added a warning message if key files are group/others accessible (in CVS).
I think that's reasonable (as opposed to requiring protections) given the
fact that if you want to disable encryption/authentication altogether or use
a cleartext-only OpenVPN by building without OpenSSL, you also get a warning
message.

> > > 2) Each OpenVPN daemon should delete its pidfile when stoping, since
it
> > > was that very same daemon that created it.
> > > It has no sense to have the init.d scripts deleting these files (and
> > > stoping nonexistent daemons) since the daemon could have been killed
> > > before the init.d script tried to stop it.
> >
> > The complication here is that a lot of people will want to downgrade
> > privilege using --user and/or --group.  That means that when an OpenVPN
> > daemon is ready to exit, it might lack the privilege to delete its own
> > pidfile.  I've seen other daemons deal with this by chowning the pid
file to
> > the user/group that the daemon plans to setuid/setgid to.
>
> Didn't think of that. Good point. :-)

The only way I can think to do this would be to fork off the work process
before the UID/GID downgrade.  Then the parent would just sit around as root
and wait until the downgraded child exited, deleting the pidfile.  It would
work but I'm hesitant to complexify the code and add a new process for
something as trivial as deleting a file.  Too bad open() doesn't have a
delete-on-close flag.

Chowning the pid file doesn't work because unlink needs write access to the
directory as well.

> Thanks for your work.

Your welcome!

Ciao,
James

> Best regards,
> Alberto
>
>
> --
> Alberto Gonzalez Iniesta       | They that give up essential liberty
> ag...@ag...                     | to obtain a little temporary safety
> Encrypted mail preferred       | deserve neither liberty nor safety.
>
> Key fingerprint = 9782 04E7 2B75 405C F5E9  0C81 C514 AF8E 4BA4 01C3
>

Re: [Openvpn-devel] Features comments/request

[Alberto G. I. <ag...@ag...>]

On Tue, Jun 25, 2002 at 10:02:18AM -0600, James Yonan wrote:
> Hi Alberto,
> 
> > I'd like to ask for a couple of features (little ones) added to OpenVPN.
> > Comments welcomed.
> >
> > 1) OpenVPN should refuse to start a connection based on shared secret
> > when the file containing that key is world readable (or writable).
> > Paranoia won't even like group readable :-)
> Good idea, however what if someone doesn't want to deal with the protections
> on every file and instead just eliminates group/world access to the key
> directory?  Therefore, erring on the individual file protections could
> create a false sense of paranoia?

Hi James,

Yes, forcing directory security could be a better solution, but what
happens if the user wants to keep the key in a directory like /etc? or
/usr/local/etc? From my point of view (Debian's package) there's no
problem, I'll probably go for a /etc/openvpn/secrets directory, but just
wanted to note this in case you wanted to think about it.


> > 2) Each OpenVPN daemon should delete its pidfile when stoping, since it
> > was that very same daemon that created it.
> > It has no sense to have the init.d scripts deleting these files (and
> > stoping nonexistent daemons) since the daemon could have been killed
> > before the init.d script tried to stop it.
> 
> The complication here is that a lot of people will want to downgrade
> privilege using --user and/or --group.  That means that when an OpenVPN
> daemon is ready to exit, it might lack the privilege to delete its own
> pidfile.  I've seen other daemons deal with this by chowning the pid file to
> the user/group that the daemon plans to setuid/setgid to.

Didn't think of that. Good point. :-)
Thanks for your work. 

Best regards,
Alberto
 

-- 
Alberto Gonzalez Iniesta       | They that give up essential liberty
ag...@ag...                     | to obtain a little temporary safety
Encrypted mail preferred       | deserve neither liberty nor safety.

Key fingerprint = 9782 04E7 2B75 405C F5E9  0C81 C514 AF8E 4BA4 01C3