CIPE protocol crypto questions

[errzyy3i,AT,umail,DOT,furryterror,DOT,org (Zygo Blaxell)]

I've been reviewing the CIPE protocol recently, both before using CIPE
and now after the recent WEP protocol breakage by Golberg, Borisov,
and (insert name here, I forget just now ;-).

Here are three questions about behavior observed and documented with
CIPE 1.4.5 on Linux 2.2.17/18:

1.  The carrier UDP packets seem to have the same IP TOS and DF bits
as the encrypted IP packets they carry.  I can't figure out if this is
a bug, a feature, or just an accident.  Here is the case for each:

        a.  It's a bug, because it allows traffic analysis on the packets.
        I have one VPN that carries only SSH, web browsers, ICMP
        echo/reply, DNS and NTP traffic, and it's possible to identify
        which CIPE carrier packets belong to each protocol by looking
        only at the IP flags.

        Also:  How would TCP path MTU discovery work?  PMTUD requires
        receiving an ICMP fragmentation-required message with the correct
        MTU, but if the DF bit is set on CIPE's UDP carrier packet,
        and a router on the Internet sends an ICMP fragmentation-required
        message, then this ICMP message will be sent to the CIPE peer,
        and _not_ to the TCP peer that needs the path MTU information.
        Judging from the mailing list traffic over the last year, this
        seems to be an often-encountered but little-understood problem.

        b.  It's a feature, because if you care enough about IP TOS 
        to set it for your application on the VPN, then you want routers
        on the Internet carrying the UDP carrier packets to have the same
        routing information.  This justifies TOS bits, but not DF.
        Either way, it should be a configurable option due to the traffic
        analysis problems, and the documentation should be updated to
        point out that this information is actually available outside of
        the encrypted packets...

        c.  It's an accident, because most of the code for CIPE was
        copied unaudited from the IPIP tunneling code...

2.  The current protocol uses two kinds of packets, encrypted with
different keys.  These packets are distinguished by one bit of the IV
of each packet.  This creates two kinds of problems:

        a.  It's easy to isolate the key exchange, ping, etc. packets
        from the IP-carrying data packets by checking this bit, and

        b.  If the packets can be isolated, they can be filtered, to
        prevent new key exchanges from taking place.

I've observed case B occurring by accident, when the route between two
ends of a VPN became unusable in one direction.  Traffic continued to
be received for hours, despite the dynamic key renegotiation interval of
10 minutes and the inability of one peer to receive key exchange packets
from the other.

Other postings on the CIPE list indicate that key exchange takes place
using the current dynamic key, instead of the shared static key, 
if there is a valid one known to both peers.  If true, this would
effectively turn this problem into a simple DOS (by preventing the
dynamic key from ever being negotiated at all).  The documentation
doesn't seem to mention this, though.

It would seem to me there are two effective remedies for this problem:

        a.  Assume that 99%+ of the traffic is encrypted using the most
        recently negotiated dynamic key, and always try the most recently
        negotiated dynamic key, then the second most recently negotiated
        dynamic key, then the static key, relying on the CRC of each
        packet to identify when the decryption was successful.  This 
        would allow the 64th bit of the IV to be random again.

        b.  Encrypt the IV using the static key and cipher in ECB mode.
        This would prevent trivial identification of which packets are
        for key exchange and which for data, unless the receiver knows
        the static key.

3.  The CRC function for validating each packet is linear.  If some
properties are known about the data and cipher used, it is easier to
modify a packet and maintain a correct CRC than certain other hash
functions.  This attack can theoretically be used against SSH, which uses
CRC's for integrity checking as well.  WEP is completely vulnerable to
this kind of attack, because it uses RC4 as a cipher.

Using a CRC of an MD5 or SHA-1 hash comes to mind as a possible
solution--the message integrity check data is the same length, but the
function is no longer linear wrt the encrypted data.  If we are willing
to accept a larger protocol overhead, an entire MD5 or SHA-1 hash can
be used as well.

Attachment: pgp00000.pgp
Description: "PGP signature"