[PROBLEM] IPSec: IPComp CPI size

[Brian Buesker <bbuesker@qualcomm.com>]

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.

Brian

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