[PROBLEM] IPSec: IPComp CPI size

From: Brian Buesker (bbuesker@qualcomm.com)
Date: Thu Aug 14 2003 - 16:47:42 EST

Upon doing some more testing with 2.6.0-test2 and IPComp being negotiated using IKE, I came across the following problem. It seems that the kernel is allocating a 4 byte SPI, of which, as per RFC 2393 section 3.3, only two bytes are used for the IPComp CPI. Thus, once the security association has been established between the two endpoints, the kernel has a four byte SPI in its Security Association Database, although only a two-byte CPI is sent in the IPComp header. Thus, when an IP packet with IPComp is received, the two-byte CPI is expanded to four bytes and used to index into the SAD. However, since the original SPI that was installed into the SAD was 4 bytes, the kernel does not find a match for the CPI, and thus drops the packet.

Another problem I noticed was that if the entry in the SPD for an inbound packet indicates that IPComp should exist on inbound packets, but there is no IPComp header, then the packet is just dropped. However, since IPComp is only used outbound if the resulting compressed header + data is smaller than the original data, then shouldn't the kernel allow this packet to pass on up to the higher layers in the networking stack? In other words, when IPComp is specified in the SPD for inbound packets, it should not be taken as a hard requirement since it is possible that not all packets will be able to be compressed. It is not an error condition when an IPComp header is missing.


To unsubscribe from this list: send the line "unsubscribe linux-net" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html