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

Subject: Re: RFC: Large dynamic CIPE VPN (2nd posting)
From: me,AT,zerobyte,DOT,org
Date: Sun, 22 Oct 2000 18:32:54 +0200

I've given a lot of thought to this very type of application
myself. However, I think that the answer is not to extend these features
into cipe itself, but to create a sort of cipe superserver that creates
and establishes the individual connections itself.

Thinking about this simply in terms of the OSI model tells me that cipe is
a layer 2 "device" and really need not know anything about the big
picture. Cipe simply says traffic going to neighbor X gets encrypted with
the following key, and sent along its merry way.

A cipe superserver would keep the load out of the cipe process itself. It
could listen on a standard port for connections from the cipe superserver
on the connecting client machine, and the 2 daemons exchange messaging
information regarding the crypto tunnel to be built between them. I would
think that a public/private key system such as the one in ssh would be a
good form of host identification. MAC address would not be simply because
you're having to accept on faith that the reported mac address is real
unless on the same physical LAN, and then CIPE becomes less useful anyway
in that scenario...

Another thing about large VPNs using CIPE which I haven't seen any mention
of is the extreme waste of bandwidth when the clients talk directly to
each other. Just because it's "one IP hop" to the central server, and then
"one IP hop" to the sibling network in the tree, there are really lots of
hidden IP hops in the mix, and many of them get double usage. Wouldn't it
be simpler if the central server had a facility that told the connecting
node what all other networks were connected to it, and they also build
direct tunnels to each other?

Of course you may wish to force traffic between certain sibling nets for
security purposes. Cisco's PIX Firewall has an interesting notion that
could apply here. When configuring a client network in the superserver,
and adding that gateway's public key to your list of peers, one variable
that applies to the peer could be "security level," a number from 0 - 255
for example. A connecting client gets notification of all siblings with
the same security level or higher. 

The exchange or IP routing info would also be useful in this cipe
superserver. That way, whenever the superserver adds a node to the VPN, it
will also modify the IP routing table accordingly. Then as the connecting
client learns of its siblings from the central server, it can build cipe
links to its siblings and then exchange routes with them accordingly.

In fact, the central server need not necessarily participate in the actual
tunneling itself, but simply act as a centralpoint for netowrk
information, if all peers try to send traffic directly to each other.

I would be willing to work with some others in ironing all this out if
anyone's interested. I simply don't know enough about coding network apps
to do so myself. I do however have a good understanding of IP and WAN
topologies, routing, etc.

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