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

Subject: RFC: Large dynamic CIPE VPN (2nd posting)
From: Christian Lademann <cal,AT,zls,DOT,de>
Date: Sat, 21 Oct 2000 20:18:49 +0200

Hi, CIPE-experts.

I am working on an idea I had and I would like to hear your opinions and

suggestions.

I would like to build a large-scale VPN with possibly some hundered
peers
that all connect to a central site over the internet. The remote boxes
should be unattended and their CIPE-configuration should eventually be
remotely reconfigurable.

This said, I do not like the idea to configure all the different
cipe.conf, etc.

Now my idea to solve this:

1. As soon as the remote box (client) wants to communicate to the
   central site (server), or as soon as the internet-connection is
established,
   the client connects to the server via tcp to a well-known port and
   sets up a SSL-connection.

2. The client authenticates itself to the server with a user-id (name,
   mac-address, etc) and a passwort (or with a SSL-certificate, etc).

3. The server looks up the clients desired vpn-configuration in its
   database and either accepts or rejects the request. Is also
   generates a random static key.

4. If the server accepted the request, it writes out a taylored
cipe.conf
   to a 'well-known' location (.../options/cipe.$user-id.conf ...),
starts
   ciped with a new options '-v' with tells ciped to report the
dynamically
   choosen udp-port and cipe-device. The server collects all those
   informations together with the pid of the daemon process and
   writes it to a statusfile.
   If there is still a ciped-process 'hanging around' from the last
   connection, it is killed before the new daemon process is started.

5. If the ciped was started successfully, the server can now open the
   firewall for udp-traffic between the client (whose ip-address is
   known because of the active tcp-connection) and ciped (whose
listening
   upd-port is known because of the '-v' - switch).
   The server also sets up the necessary routing table entries.

6. All information is reported back to the client that now can create
   it's own taylored cipe.conf:
   it gets
     - the ip-address and udp-port of the CIPE-server
     - the initial static key
     - other information, like routing table entries, etc.

7. If the client wants to cancel the connection, it either just drops
   it's internet connection so the server would stumble over some
timeout
   or it again connects via SSL to the server to tell it goodbye.
   Also it stops it's ciped.

8. If the server wants to teer down the communication it just kills the
   specific ciped and closes the firewall.

9. If the ip-address of the client changes, it just starts from step 1.

To support more clients than one server-box can handle (or to have some
kind of load-balancing) the server could find look up the least busy
CIPE-
server of the server-farm between step 3. and 4. If it finds another
server
move eligible to host the connection (or if the client already connected

to another server before) it would act like a proxy between the client
and
the actual server to host the ciped until the necessary information is
exchanged.

I have already started and coded up quite a lot of the stuff presented
in
1. to 9. using PERL. It is not quite finished yet but it will be RSN.
It's called "cipic" (CIPE Initial Connector). I will publish it here
as soon as it is worth to take a look at.

Please tell me, what you think. Is my approach possible? Are there
better
or more secure possibilities?

Christian Lademann <cal,AT,zls,DOT,de>

PS: This is an output of 'ciped-cb -v ...':

    CIPE daemon vers 1.4.1 (c) Olaf Titz 1996-2000
    pid: 2398
    device: cipcb2
    me: 192.168.0.1:1224





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