netdev - IPv6 IPSec incompatibilities between 2.6.23 and 3.6.18 (and probably later)

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Date:	Tue, 19 Jul 2016 14:03:44 +0000
From:	Pommnitz Jörg <Pommnitz@...g.de>
To:	"netdev@...r.kernel.org" <netdev@...r.kernel.org>
Subject: IPv6 IPSec incompatibilities between 2.6.23 and 3.6.18 (and
 probably later)

Hello all,
for years we have used the following manual IPsec rules to decrypt broadcast (all host multicast) messages:

===== snip ===========

#!/bin/bash

IP6ANYADDR=::/0
IP6BCAST=ff0e::1
KEY="0x7bef6ecaf06d29ef55b24aca6e19964b332e02e75be676a3"
IFNAME=lan1
IP6ADDR=fd01:1b10:1000::1
PREFIX6=64
SPI=0x1

ip link set dev ${IFNAME} up
ip addr add ${IP6ADDR}/${PREFIX6} dev ${IFNAME}
echo "flush; add ${IP6ADDR} ${IP6BCAST} esp ${SPI} -m tunnel -E aes-cbc ${KEY};" | setkey -c
echo "spdflush; spdadd ${IP6ANYADDR} ${IP6BCAST} any -P in ipsec esp/tunnel/${IP6ADDR}-${IP6BCAST}/require;" | setkey -c

====================

The corresponding encryption rules still work perfectly fine:
===== snip ===========
#!/bin/bash


IP6ANYADDR=::/0
IP6BCAST=ff0e::1
KEY="0x7bef6ecaf06d29ef55b24aca6e19964b332e02e75be676a3"
IFNAME=lan1
IP6ADDR=fd01:1b10:1000::2
PREFIX6=64
SPI=0x1

ip link set dev ${IFNAME} up
ip addr add ${IP6ADDR}/${PREFIX6} dev ${IFNAME}
echo "flush; add ${IP6ADDR} ${IP6BCAST} esp ${SPI} -m tunnel -E aes-cbc ${KEY};" | setkey -c
echo "spdflush; spdadd ${IP6ANYADDR} ${IP6BCAST} any -P in ipsec esp/tunnel/${IP6ADDR}-${IP6BCAST}/require;" | setkey -c
echo "spdadd ${IP6ANYADDR} ${IP6BCAST} any -P out ipsec esp/tunnel/${IP6ADDR}-${IP6BCAST}/require;" | setkey -c
====================

Using "ping6 -I lan1 ff0e::1" I see outgoing ESP packets on the second host (e.g. with fd01:1b10:1000::2) with both, 2.6.23 and 3.6.18:

14:40:36.398471 IP6 fd01:1b10:1000::2 > ff0e::1: ESP(spi=0x00000001,seq=0x5d4), length 136
14:40:37.398533 IP6 fd01:1b10:1000::2 > ff0e::1: ESP(spi=0x00000001,seq=0x5d5), length 136
14:40:38.398596 IP6 fd01:1b10:1000::2 > ff0e::1: ESP(spi=0x00000001,seq=0x5d6), length 136
14:40:39.398658 IP6 fd01:1b10:1000::2 > ff0e::1: ESP(spi=0x00000001,seq=0x5d7), length 136
14:40:40.398721 IP6 fd01:1b10:1000::2 > ff0e::1: ESP(spi=0x00000001,seq=0x5d8), length 136
14:40:41.398783 IP6 fd01:1b10:1000::2 > ff0e::1: ESP(spi=0x00000001,seq=0x5d9), length 136
14:40:42.398846 IP6 fd01:1b10:1000::2 > ff0e::1: ESP(spi=0x00000001,seq=0x5da), length 136


On the receiving side (e.g. fd01:1b10:1000::1) I see the decrypted packets with the 2.6.23 kernel:
18:17:58.517791 IP6 fd01:1b10:1000::2 > ff0e::1: ESP(spi=0x00000001,seq=0x62c), length 136
18:17:58.517791 IP6 fd01:1b10:1000::2 > ff0e::1: ICMP6, echo request, seq 119, length 64
18:17:59.517836 IP6 fd01:1b10:1000::2 > ff0e::1: ESP(spi=0x00000001,seq=0x62d), length 136
18:17:59.517836 IP6 fd01:1b10:1000::2 > ff0e::1: ICMP6, echo request, seq 120, length 64
18:18:00.517880 IP6 fd01:1b10:1000::2 > ff0e::1: ESP(spi=0x00000001,seq=0x62e), length 136
18:18:00.517880 IP6 fd01:1b10:1000::2 > ff0e::1: ICMP6, echo request, seq 121, length 64
18:18:01.518734 IP6 fd01:1b10:1000::2 > ff0e::1: ESP(spi=0x00000001,seq=0x62f), length 136
18:18:01.518734 IP6 fd01:1b10:1000::2 > ff0e::1: ICMP6, echo request, seq 122, length 64
18:18:02.518763 IP6 fd01:1b10:1000::2 > ff0e::1: ESP(spi=0x00000001,seq=0x630), length 136
18:18:02.518763 IP6 fd01:1b10:1000::2 > ff0e::1: ICMP6, echo request, seq 123, length 64
18:18:03.518790 IP6 fd01:1b10:1000::2 > ff0e::1: ESP(spi=0x00000001,seq=0x631), length 136
18:18:03.518790 IP6 fd01:1b10:1000::2 > ff0e::1: ICMP6, echo request, seq 124, length 64
but NOT with the newer kernel:
16:32:19.980862 IP6 fd01:1b10:1000::2 > ff0e::1: ESP(spi=0x00000001,seq=0x98e), length 136
16:32:20.980925 IP6 fd01:1b10:1000::2 > ff0e::1: ESP(spi=0x00000001,seq=0x98f), length 136
16:32:21.980987 IP6 fd01:1b10:1000::2 > ff0e::1: ESP(spi=0x00000001,seq=0x990), length 136
16:32:22.981050 IP6 fd01:1b10:1000::2 > ff0e::1: ESP(spi=0x00000001,seq=0x991), length 136
16:32:23.981112 IP6 fd01:1b10:1000::2 > ff0e::1: ESP(spi=0x00000001,seq=0x992), length 136
16:32:24.981175 IP6 fd01:1b10:1000::2 > ff0e::1: ESP(spi=0x00000001,seq=0x993), length 136
16:32:25.981237 IP6 fd01:1b10:1000::2 > ff0e::1: ESP(spi=0x00000001,seq=0x994), length 136
16:32:26.981300 IP6 fd01:1b10:1000::2 > ff0e::1: ESP(spi=0x00000001,seq=0x995), length 136


BTW, the equivalent IPv4 IPsec rules (basically 255.255.255.255 as broadcast and 0.0.0.0/0 as any address works fine with both, 2.6.23 and 3.6.18.

Since my application depends on this, I'm kind of stuck. Is this a known problem with a fix in a later kernel?


Thanks in advance and kind regards
  Joerg

________________________________
Industrieanlagen-Betriebsgesellschaft mbH

Sitz der Gesellschaft: Ottobrunn, Registergericht: Amtsgericht München, HRB 5499
Geschäftsführung: Prof. Dr.-Ing. Rudolf F. Schwarz
Vorsitzender des Aufsichtsrats: RA Engelbert Kupka MdL a.D.