CIPE-FAQThis is a very incomplete collection of topics which already came up more than once on the CIPE mailing list.
- Usage scenarios
While it is possible that there are specific attacks against the protocol (see next question), to date I know of no such attack which could fatally undermine the security of the CIPE system. If this is a meaningful classification, I would count it as "industry strength". There are three other commonly described levels of cryptographic strength: toy, military, and snake-oil. Don't believe anyone who claims "military strength" for any product. More info is in the excellent Snake Oil FAQ.
The protocol documentation lists some possible attacks against the protocol design. These are mostly of a theoretical nature and/or denial of service level. It also has a description of measures against these attacks, but not all of them are actually implemented.
To date one case of a potentially exploitable bug has been found, luckily in a version which never was widely used. Another bug has been found which could lead to denial of service attacks. Both have been fixed. Reports of bugs are described in the bugs section of the CIPE home page.
This section is about the Linux version of CIPE, don't know about the Windows one.
For this reason, people occasionally propose tunneling PPP (and thus IP) over an SSH or SSL connection. This should really be avoided because it has bad performance characteristics. Read this explanation.
As for CIPE vs. IPSEC, they should be equivalent security-wise, with CIPE giving a bit better performance because of the lightweight protocol. However, IPSEC is standardized and thus has better interoperability.
The general problem with the Windows networking in a network containing (any sort of) routers is that it relies on broadcasts for name resolution and browse lists, and routers usually don't pass broadcasts. Communication of machine names and browse lists (i.e. the lists you can see in the "Network Neighborhood" windows) across subnets requires the use of machines which run special services:
- (at least) one WINS server in the network - must be configured;
- one domain master browser for each Workgroup or Domain - must be configured;
- one local master browser in each subnet - selected automatically among all active Windows (9x/NT) or Samba machines but can be configured to prefer a machine with long uptime for reliability.
It is also necessary that all machines participating in the Windows network are configured to use the WINS server for name resolution.
meoption in the peer public-key file (i.e.
/etc/cipe/pk/peer) to set your own carrier address like with static configuration. An IP address and/or port number specified as zero will be filled dynamically. So to bind to a specific IP address, use
w.x.y.z:0, to bind to a specific port use
ip-up(using the iproute tools as you would for an Ethernet device). Also add a route to the peer as appropriate. Note that as soon as an ethernet(-emulation) device goes up on an IPv6 capable system, the kernel starts sending neighbour and router solicitation messages over that device (even without assigning an actual IPv6 address!) These messages behave like pings to the CIPE link in that they can provoke errors. You probably need maxerr=-1.
This is almost certainly due to a mismatch between kernel and CIPE module. Make sure you have compiled the module against the right kernel headers, with the right compiler and options, etc.
This applies to any externally compiled module: a module must be compiled using the same compiler and options, and using the same, identically configured kernel header tree, as the kernel it will run on. Otherwise, it could use definitions of kernel data structures which don't agree with the running kernel, since these structures are configuration and compiler dependent. This is an easy way to cause kernel crashes.
If you compile your own kernel, always set the "Set version information on all symbols" (aka MODVERSIONS) option. It helps catch the errors from mismatching modules by refusing to load these modules.
Van Jacobson TCP/IP header compression (also called CSLIP if you're still running SLIP) is a different thing, it does not affect CIPE in any way (it only compresses TCP packets). Turn it off if (and only if) you notice instabilities with unencrypted TCP connections.
Another possible cause is that you run a (misconfigured) spam filter which flags list traffic as spam. Re-order your filters so that list traffic is sorted out before spam filtering (this is a good idea in any case).