[Openswan Users] Fw: [Ipsec-tools-devel] ipcomp between racoon and FreeS/WAN 2.04

[Michael Richardson]

-----BEGIN PGP SIGNED MESSAGE-----


Marco, Michal, others,

The Openswan KLIPS ipcomp feature has interoperated MULTIPLE TIMES with
MULTIPLE STACKS over 6 years of development.

I have worked on IPsec since 1994 at four different companies.
I have been to five bakeoffs between 1997 and 1999, and again in 2001.

RFC2393 defines IPcomp, later updated by RFC3173. 
(If you are going to write statements about standards, do the research first)

The problem with 26sec's use of IPCOMP is a clear problem.
If OpenBSD, FreeBSD, NetBSD, PGP Net and Cisco accept those packets,
then those systems are broken.

If you like, I know the developers of each of these systems personally,
and I can phone them and talk to them directly. If you like, we can
call Stephen Kent himself.

At best, putting a second IPIP header in between ESP and IPcomp is a
simple waste of 20 bytes. 

At worst, the code that permits such a packet to be received and
processed may in fact permit IP source address spoofing *inside* of the
tunnel. I don't know, I haven't looked at it.

RFC3173:

...
   The compression of outbound IP datagrams MUST be done before any IP
   security processing, such as encryption and authentication, and
   before any fragmentation of the IP datagram.  In addition, in IP
   version 6 [RFC2460], the compression of outbound IP datagrams MUST be
   done before the addition of either a Hop-by-Hop Options header or a
   Routing Header, since both carry information that must be examined
   and processed by possibly every node along a packet's delivery path,
   and therefore MUST be sent in the original form.
...

2.1. Compressed Payload

   The compression is applied to a single array of octets, which are
   contiguous in the IP datagram.  This array of octets always ends at
   the last octet of the IP packet payload.  Note: A contiguous array of
   octets in the IP datagram may be not contiguous in physical memory.

   In IP version 4 [RFC0791], the compression is applied to the payload
   of the IP datagram, starting at the first octet following the IP
   header, and continuing through the last octet of the datagram.  No
   portion of the IP header or the IP header options is compressed.
   Note: In the case of an encapsulated IP header (e.g., tunnel mode
   encapsulation in IPsec), the datagram payload is defined to start
   immediately after the outer IP header; accordingly, the inner IP
   header is considered part of the payload and is compressed.

   In the IPv6 context, IPComp is viewed as an end-to-end payload, and
   MUST NOT apply to hop-by-hop, routing, and fragmentation extension
   headers.  The compression is applied starting at the first IP Header
   Option field that does not carry information that must be examined
   and processed by nodes along a packet's delivery path, if such an IP
   Header Option field exists, and continues to the ULP payload of the
   IP datagram.

   The size of a compressed payload, generated by the compression
   algorithm, MUST be in whole octet units.

   As defined in section 3, an IPComp header is inserted immediately
   preceding the compressed payload.  The original IP header is modified
   to indicate the usage of the IPComp protocol and the reduced size of
   the IP datagram.  The original content of the Next Header (IPv6) or
   protocol (IPv4) field is stored in the IPComp header.

   The decompression is applied to a single contiguous array of octets
   in the IP datagram.  The start of the array of octets immediately
   follows the IPComp header and ends at the last octet of the IP
   payload.  If the decompression process is successfully completed, the
   IP header is modified to indicate the size of the decompressed IP
   datagram, and the original next header as stored in the IPComp
   header.  The IPComp header is removed from the IP datagram and the
   decompressed payload immediately follows the IP header.

====

The packet starts out as:

	   IPa TCP data

This packet then becomes the *PAYLOAD* of the ESP-tunnel mode:

   IPb ESP IPa TCP data

By the first paragraph, the IPcomp does not go get inserted as:
   IPb IPcomp ESP IPa TCP data

because you can't compress encrypted data, which is actually the whole
reason for IPcomp. ESP screws up any compression that PPP was getting.
You have to insert it afterwards, which results in:

    IPb ESP IPcomp IPa TCP data

At no point does the document say ANYTHING about inserting a second
IP-IP header into the packet.

- --
]       ON HUMILITY: to err is human. To moo, bovine.           |  firewalls  [
]   Michael Richardson,    Xelerance Corporation, Ottawa, ON    |net architect[
] mcr at xelerance.com      http://www.sandelman.ottawa.on.ca/mcr/ |device driver[
] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2 (GNU/Linux)
Comment: Finger me for keys

iQCVAwUBQGOhj4qHRg3pndX9AQHgJwP9EWgG/TlsPE2BXJ9RXiAqrKpeYwsbWtfM
l64cS0qWlXoC7nQJKIq/FNDOxhCCbji2bljMWSFUKTsJv1DFf3F0BYsf9qPxdNKx
NfsvSKHRzOEByHNJujWZvLmDwC2MxBHOdiNYnwPbp80KQw6RxYcry9bcKigwN8ll
3cYSOJ4KoEA=
=WlLA
-----END PGP SIGNATURE-----