Page MenuHomeFreeBSD

Handle non-compressed packets for IPComp in tunnel mode.
ClosedPublic

Authored by ae on Apr 22 2016, 2:14 PM.
Tags
None
Referenced Files
F80134407: D6062.diff
Thu, Mar 28, 9:22 AM
Unknown Object (File)
Fri, Mar 15, 8:24 PM
Unknown Object (File)
Feb 23 2024, 9:12 AM
Unknown Object (File)
Feb 15 2024, 4:10 PM
Unknown Object (File)
Feb 15 2024, 4:10 PM
Unknown Object (File)
Feb 15 2024, 4:10 PM
Unknown Object (File)
Feb 15 2024, 4:10 PM
Unknown Object (File)
Feb 15 2024, 4:08 PM
Subscribers

Details

Summary

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 172.16.0.9 172.16.0.11 any -P out ipsec ipcomp/tunnel/10.9.8.9-10.9.8.11/default;
add 10.9.8.9 10.9.8.11 ipcomp 15701 -m tunnel -C deflate;
add 10.9.8.11 10.9.8.9 ipcomp 24501 -m tunnel -C deflate;

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

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

Diff Detail

Repository
rS FreeBSD src repository - subversion
Lint
Lint Not Applicable
Unit
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.