Page MenuHomeFreeBSD

Handle non-compressed packets for IPComp in tunnel mode.

Authored by ae on Apr 22 2016, 2:14 PM.
Referenced Files
F52709284: D6062.diff
Wed, Dec 7, 6:16 AM
Unknown Object (File)
Apr 26 2017, 11:20 AM
Unknown Object (File)
Apr 17 2017, 8:14 AM
Unknown Object (File)
Apr 16 2017, 7:58 AM
Unknown Object (File)
Apr 7 2017, 1:21 PM
Unknown Object (File)
Mar 27 2017, 8:49 PM
Unknown Object (File)
Mar 20 2017, 2:57 AM
Unknown Object (File)
Mar 16 2017, 12:33 PM



RFC 3173 p 2.2. Non-Expansion Policy says that packets should
send unchanged (i.e. without compression and without IPComp header)
when compression is useless (the size of compressed data is not smaller
than non-compressed).

The ability to handle such uncompressed packets was partially implemented
via xform_ipip ip_encap handler, that was removed in rS281692.

The problem can be reproduced when IPSec configured in tunnel mode and IPComp
is the only used transform. Then for small packets IPComp will send just encapsulated
IP datagrams. Since there aren't any special handlers for IPPROTO_IPV4 and IPPROTO_IPV6,
such packets will be dropped by RAW IP code.

Previous implementation could do unneeded decapsulation for some packets due to false positive
handling. Also it seems it doesn't handle packets when only one IPComp transform is used.

This patch provides the alternative implementation of such feature.
In xform_ipcomp.c we register ip_encap handlers for IPPROTO_IPV4 and
IPPROTO_IPV6. The handler does lookup for SA related to IPComp protocol
and given from mbuf source and destination addresses as tunnel endpoints.
So, we decapsulate packets only when there are some corresponding SA found.
For this purpose key_allocsa_tunnel() functions is added.

Test Plan

I tested with the following config:

# Test 1: IPv4 + tunnel mode IPSec + IPComp
spdadd any -P out ipsec ipcomp/tunnel/;
add ipcomp 15701 -m tunnel -C deflate;
add ipcomp 24501 -m tunnel -C deflate;

# tcpdump -ni em0 proto ipcomp or proto ipencap 
# ping -c1
17:02:52.410553 IP > IP > ICMP echo request, id 46650, seq 0, length 64 (ipip-proto-4)
17:02:52.411037 IP > IP > ICMP echo reply, id 46650, seq 0, length 64 (ipip-proto-4)
# ping -c1 -s1000
17:03:38.828548 IP > IPComp(cpi=0x3d55)
17:03:38.829143 IP > IPComp(cpi=0x5fb5)

# Test 2: IPv4 + tunnel mode IPComp + transport mode ESP 
spdadd any -P out ipsec ipcomp/tunnel/ esp/transport//default;
add ipcomp 15701 -m tunnel -C deflate;
add ipcomp 24501 -m tunnel -C deflate;
add esp 15701 -m transport -E rijndael-cbc "1111111111111111";
add esp 24501 -m transport -E rijndael-cbc "1111111111111111";
# tcpdump -ni em0 proto ipcomp or proto ipencap or esp
# ping -c1
17:09:07.549512 IP > ESP(spi=0x00003d55,seq=0x1), length 120
17:09:07.558344 IP > ESP(spi=0x00005fb5,seq=0x1), length 120

# dtrace -n 'fbt::ipcomp4_nonexp_encapcheck:return {printf("%d", arg1);}'
dtrace: description 'fbt::ipcomp4_nonexp_encapcheck:return ' matched 1 probe
CPU     ID                    FUNCTION:NAME
  1  18454 ipcomp4_nonexp_encapcheck:return 64

# ping -c1 -s1000
17:09:46.326608 IP > ESP(spi=0x00003d55,seq=0x2), length 360
17:09:46.327316 IP > ESP(spi=0x00005fb5,seq=0x2), length 360

Diff Detail

rS FreeBSD src repository - subversion
Lint Not Applicable
Tests Not Applicable

Event Timeline

ae retitled this revision from to Handle non-compressed packets for IPComp in tunnel mode..
ae updated this object.
ae edited the test plan for this revision. (Show Details)
ae added reviewers: network, gnn.

Since encapcheck handler called from ip_encap code, it is safe to assume
mbuf has enough contiguous data to use mtod() instead of m_copydata().

gnn edited edge metadata.

I have confirmed this fixes the problem I initially saw.

This revision is now accepted and ready to land.Apr 23 2016, 3:50 PM
This revision was automatically updated to reflect the committed changes.