Hello, AES-GCM-16 in IPSec/ESP seems to be broken using aesni on HEAD: all the emitted ciphered packets are dropped by the remote host. However, everything works as expected using cryptosoft. Please also note that If I revert aesni to r324036, aesni works fine again. So maybe r325037 is responsible for this regression? Regards,
Add committer of r325036 for possible comment.
(In reply to Mark Linimon from comment #1) The possibly problematic revision is r325037, not r325036 (which is an MFC).
(In reply to Mark Johnston from comment #2) Sorry, typo. r324037.
Yep, it's almost certainly that commit. Maybe duplicate to bug 227788.
@Emeric, could you provide some instructions on how to setup a ESP tunnel so I can test/reproduce this? Thanks.
Hello, I am using strongSwan to set up ESP SAs in tunnel mode. If you are new to IPSec, it may be easier to setup ESP SAs in transport mode using PSK authentication. There are a lot of examples on the strongSwan website to set up a tunnel. Have a look at: - https://www.strongswan.org/testing/testresults/ikev2/alg-aes-gcm to get an example of a gcm setup. - https://www.strongswan.org/testing/testresults/ikev2/host2host-transport/index.html to get an example of a transport setup. - https://www.strongswan.org/testing/testresults/ikev2/net2net-psk/index.html to get an example of PSK authentication. Make sure you set esp=aes256gcm16-modp4096-noesn! in your ipsec.conf file. Here is my configuration: ---- 192.168.100.100 LAN | FreeBSD host | WAN 192.168.56.100 ---- 192.168.56.160 WAN [ Debian/Linux host | LAN 192.168.160.160 ---- On the FreeBSD host: ipsec.conf: conn "DEBIAN" type=tunnel auto=route mobike=no keyexchange=ikev2 leftsubnet=192.168.100.0/24 rightsubnet=192.168.160.0/24 left=192.168.56.100 right=192.168.56.160 leftauth=psk rightauth=psk esp=aes256gcm16-modp4096-noesn! ike=aes256-sha256-modp4096! dpdaction=hold dpddelay=0 ipsec.secrets: 192.168.56.160 : PSK 0x5a5a5a5a The configuration on the debian host is the same (just invert 100 and 160) On the Freebsd host I am triggering the tunnel with a ping: ping -S 192.168.100.100 192.168.160.160
It may be trickier than expected. ping actually works fine in local (i.e. from my freebsd host to the debian host) but not in forwarding mode. iperf does not work in local though.
(In reply to emeric.poupon from comment #6) Thanks! I am very new to ipsec, I appreciate your help.
(In reply to Conrad Meyer from comment #8) > (In reply to emeric.poupon from comment #6) > Thanks! I am very new to ipsec, I appreciate your help. I think you can reproduce this without configuring IKE. I have two hosts with addresses 10.9.8.3 and 10.9.8.6: 10.9.8.6: # ifconfig ipsec0 create # ifconfig ipsec0 create inet 172.16.0.6/16 172.16.0.3 tunnel 10.9.8.6 10.9.8.3 reqid 200 # setkey -DF # setkey -c add 10.9.8.3 10.9.8.6 esp 0xdead -m tunnel -u 200 -E aes-gcm-16 "12345678901234567890" -A hmac-sha2-256 "01234567890123456789012345678901" ; add 10.9.8.6 10.9.8.3 esp 0xc0de -m tunnel -u 200 -E aes-gcm-16 "09876543210987654321" -A hmac-sha2-256 "01098765432109876543210987654321" ; ^D # ifconfig ipsec0 ipsec0: flags=8051<UP,POINTOPOINT,RUNNING,MULTICAST> metric 0 mtu 1400 tunnel inet 10.9.8.6 --> 10.9.8.3 inet 172.16.0.6 --> 172.16.0.3 netmask 0xffff0000 inet6 fe80::222:4dff:fe6a:5eb9%ipsec0 prefixlen 64 scopeid 0x6 nd6 options=21<PERFORMNUD,AUTO_LINKLOCAL> reqid: 200 groups: ipsec # setkey -D 10.9.8.6 10.9.8.3 esp mode=tunnel spi=49374(0x0000c0de) reqid=200(0x000000c8) E: aes-gcm-16 30393837 36353433 32313039 38373635 34333231 A: 11 30313039 38373635 34333231 30393837 36353433 32313039 38373635 34333231 seq=0x00000005 replay=0 flags=0x00000040 state=mature created: May 17 18:33:51 2018 current: May 17 18:34:44 2018 diff: 53(s) hard: 0(s) soft: 0(s) last: May 17 18:33:58 2018 hard: 0(s) soft: 0(s) current: 616(bytes) hard: 0(bytes) soft: 0(bytes) allocated: 5 hard: 0 soft: 0 sadb_seq=1 pid=1200 refcnt=1 10.9.8.3 10.9.8.6 esp mode=tunnel spi=57005(0x0000dead) reqid=200(0x000000c8) E: aes-gcm-16 31323334 35363738 39303132 33343536 37383930 A: 11 30313233 34353637 38393031 32333435 36373839 30313233 34353637 38393031 seq=0x00000000 replay=0 flags=0x00000040 state=mature created: May 17 18:33:51 2018 current: May 17 18:34:44 2018 diff: 53(s) hard: 0(s) soft: 0(s) last: May 17 18:33:58 2018 hard: 0(s) soft: 0(s) current: 352(bytes) hard: 0(bytes) soft: 0(bytes) allocated: 6 hard: 0 soft: 0 sadb_seq=0 pid=1200 refcnt=1 ----- 10.9.8.3: # ifconfig ipsec0 create # ifconfig ipsec0 create inet 172.16.0.3/16 172.16.0.6 tunnel 10.9.8.3 10.9.8.6 reqid 200 # setkey -DF # setkey -c add 10.9.8.3 10.9.8.6 esp 0xdead -m tunnel -u 200 -E aes-gcm-16 "12345678901234567890" -A hmac-sha2-256 "01234567890123456789012345678901" ; add 10.9.8.6 10.9.8.3 esp 0xc0de -m tunnel -u 200 -E aes-gcm-16 "09876543210987654321" -A hmac-sha2-256 "01098765432109876543210987654321" ; ^D Now you can try to ping 172.16.0.3/6 or use telnet/ssh 172.16.0.3. ---- The you need to clear SAs, kldload aesni and reinstall SAs. Now ping works, but TCP connection doesn't work.
A commit references this bug: Author: cem Date: Sat Jun 23 18:20:17 UTC 2018 New revision: 335584 URL: https://svnweb.freebsd.org/changeset/base/335584 Log: aesni(4): Fix {de,en}crypt operations that allocated a buffer aesni(4) allocates a contiguous buffer for the data it processes if the provided input was not already virtually contiguous, and copies the input there. It performs encryption or decryption in-place. r324037 removed the logic that then copied the processed data back to the user-provided input buffer, breaking {de,enc}crypt for mbuf chains or iovecs with more than a single descriptor. PR: 228094 (probably, not confirmed) Submitted by: Sean Fagan <kithrup AT me.com> Reported by: Emeric POUPON <emeric.poupon AT stormshield.eu> X-MFC-With: 324037 Security: could result in plaintext being output by "encrypt" operation Changes: head/sys/crypto/aesni/aesni.c
The issue fixed in r335584 is highly probable to be related to this PR, since it would affect any mbuf chain longer than a single mbuf. Please re-test with this change to confirm.
Good news! I updated the driver and now I do not reproduce the issue :)
Great :-).
*** Bug 201447 has been marked as a duplicate of this bug. ***
A commit references this bug: Author: asomers Date: Sat Jul 21 19:28:08 UTC 2018 New revision: 336586 URL: https://svnweb.freebsd.org/changeset/base/336586 Log: Clear expected failures for aesni_aes_gcm tests These tests were fixed by r335584 PR: 228094 PR: 201447 MFC after: 2 weeks X-MFC-With: 335584 Changes: head/tests/sys/netipsec/tunnel/aesni_aes_gcm_128.sh head/tests/sys/netipsec/tunnel/aesni_aes_gcm_256.sh