<< | Thread Index | >> ]    [ << | Date Index | >> ]

Subject: RE: CIPE source code modifications
From: "Mark Smith" <mark.smith,AT,avcosystems,DOT,co,DOT,uk>
Date: Tue, 25 Mar 2003 16:17:38 +0100
In-reply-to: <1048601796.27910.1623.camel@seneca.recco.de>

Wolfgang Ocker wrote:

> The standard location where to store that kind of
> information (device configuration) on a Windows system is the registry

Too true.  I'm taking a sideways view at this, however, which is what's
influencing my point.  The Win32 implementation is split up into two
sections, just like Linux - one driver in kernel space, and one control
program in user space.  I agree that the control information for the driver
should be stored in the registry, but the driver itself probably (!) has
very little information.  The endpoint details are just like those needed
for a leased line, for example a kilostream link, which describes the
endpoints of the connection.  Those details are related to the connection
rather than the device.  Specifically, we can have more than one connection
from the one device.  My point (vague though it may be) is that this doesn't
necessarily need to be in the same place as the information for the device
itself.  Indeed, allowing the control application to determine how and where
this is stored seems to be a perfect solution for all.

> If it is an administrative decision, a VPN connection should be set up
> by that administrators. If the user is not allowed to change the DNS
> server, why should he be allowed to set up a VPN?

In my case, I would be both administrator and user, which would be fine as I
could control both ends.  However, even in my circumstances, I only want the
link established for a small part of the time, so being able to control it
from user space is essential.  I need to be able to establish the link
interactively, for which I don't mind the option of password protecting at
least some part of the connection detail, be it a key used by pkcipe or a
form of encrypted session key.  I also need to be able to stop the link when
I'm done so that when I leave the machine - which I will need to do from
time to time - the connection is dropped and thus secure.

It is this requirement for changing the details after installation that is
influencing what I see as a nearly unimportant matter.  Personally I don't
think I mind where or how the details are stored so long as they are
secured, but what _is_ important to me as both an end user and an
administrator who will need to talk to other end users with potentially less
technical knowledge is that I won't need to keep visiting them to setup and
tear down their links for them - they will need to be able to do that
themselves.  Simple is good, but in my case I'd need it to remain simple.
This is why I agree with Damion's change towards a control application and a
control protocol, because at the very least I'm
thinking that if the supplied application is too complex for the end user,
even if it's exactly what I personally need, then I might be able to create
my own control application with extremely minimal interface.

> Did you try Carsten's latest version? It's pretty simple to set up now.
> Or do you mean pretty simple with respect to implementation?

I haven't tried it, no.  If I ever get the time then I might give it a go,
but personally I'm holding out for the enhanced version which should
hopefully make pkcipe a reality.  I know that pkcipe seems a far better
method of controlling and marshalling the link than direct, and Damion's
control protocol means that the control application could setup a static
link using information typed in, with the key encrypted as needed, or that
pkcipe could use the same protocol to start a dynamic link.

Damion: I'm thinking of a userspace object, perhaps an ActiveX control,
around which is the application, as this could then hide the exact method
and content of communication from the application, giving another layer
around the security information.

I'm not saying we should do it one way or another, but that we could make it
so that each installation can choose for themselves.  It is this that I feel
Damion is now working towards.

Take care,

Mark Smith - Avco Systems Ltd
email: mark.smith,AT,avcosystems,DOT,co,DOT,uk
Tel: +44 (0)1784 430996 Fax: +44 (0)1784 431078

<< | Thread Index | >> ]    [ << | Date Index | >> ]