On Thursday 25 September 2003 01:34 pm, Olaf Titz wrote:
> Another question is whether CIPE is still needed at all, since by now
> there are usable implementations of IPSEC - the lack of which was
> precisely the reason for this development. The added flexibility
> gained from the UDP encapsulation (dynamic addresses, SOCKS) may be a
> reason however.
We have linux clients with flash memory instead of hard disks, with
slow CPUs by contemporary desktop standards. These systems work great with
CIPE, given that it has a very low code size overhead and is really CPU
efficient. Some of the benefits of UDP encap. are also useful for us. CIPE
has been exceptionally reliable and tolerant of all kinds of network brain
We also integrated FreeS/WAN for cross-platform connectivity. It works
reliabily, but consumes notably more CPU when running lots of tunnels. Also,
its architecture isn't very linux friendly. It behaves quite a bit
differently than other tunnels, has its own access control (eroute), has a
hard limit on the number of interfaces it can use, and is in some cases
incompatible with NAT and other netfilter capabilities. CIPE has none of
these problems, behaving just like an ip-ip tunnel would. This means much
more flexibility in terms of deployed configurations.
Finally, the IPSec requirements surrounding traffic authentication are
cumbersome, effectively requiring a separate tunnel for each combination of
destinations across the tunnel. Some vendors solve this burden by placing a
GRE (or other) tunnel inside the IPSec tunnel, but then there's more
overhead, less payload room, etc. This is a feature of IPSec that I've never
been able to get comfortable with.
OpenVPN may have promise, but I haven't used it yet and don't know if it has
the same useful combination of features CIPE has (low resource, simple,
All the best,
Titanium Mirror, Inc.