I thought the problem might be because Linux is putting too many bits on the wire, but it might be a IPv6 padding issue covered here, https://bugzilla.suse.com/show_bug.cgi?id=1019412 FreeBSD side: add -n ::SRC ::DST ah 0xSPI -m transport -A hmac-sha2-384 0xKEY; Linux side: ip xfrm state add src ::SRC dst ::DST proto ah spi 0xSPI auth "hmac(sha384)" 0xKEY mode transport If the SUSE people are correct about the behavior, FreeBSD IPv6 Authenticated Header might not be properly padded.
FreeBSD 11.2-BETA2 still has this problem. Did the NetBSD Network Security Audit still not confirm this problem with 64-bit alignment?
It is totally plausible that FreeBSD's Ipv6 IPSEC is broken, but I don't see what NetBSD's got to do with it.
I think FreeBSD is probably in the wrong here. ah_output() does not appear to round-up ah/MAC length at all, and the ah_hdrsiz() helper unconditionally rounds to 32 bits, not 64.
(In reply to Conrad Meyer from comment #3) Correct. All I meant, with the considerable of changes to NetBSD IPsec (which I thought FreeBSD was similar to), if this had been caught already this would be a great fix to get incorporated. It's been forcing me to be stuck with hmac-sha1 on FreeBSD-Linux AH.
(In reply to Jason Mader from comment #4) Ah, got it, thanks! I'm not familiar with NetBSD IPSec work and don't know how much is shared. Based on a 20 byte MAC like HMAC-SHA1 working and an 8 byte alignment requirement, it seems like a 224-bit (28 byte) MAC like HMAC-SHA2-224 should have the same alignment. Have you tried that one?
(In reply to Conrad Meyer from comment #5) Nope, only because I don't believe Linux ip xfrm has that algorithm, From IP-XFRM(8): Authentication algorithms include digest_null, hmac(md5), hmac(sha1), hmac(sha256), hmac(sha384), hmac(sha512), hmac(rmd610), and xcbc(aes). Here's what I saw yesterday about the security audit, http://blog.netbsd.org/tnf/entry/network_security_audit
(In reply to Jason Mader from comment #6) Ah, that is unfortunate. Thanks. I don't see anything in the NetBSD link related to AH MAC length padding.
(In reply to Conrad Meyer from comment #7) I don't see changes to the NetBSD ah_output() and ah_hdrsiz() functions either.
Hi, Maxim reported that he fixed the problem in NetBSD, can you look at this? http://mail-index.netbsd.org/source-changes/2018/05/30/msg095589.html http://mail-index.netbsd.org/source-changes/2018/05/30/msg095592.html
I tried this on NetBSD, and hmac-sha2-384 is working with Linux now.
(In reply to Jason Mader from comment #10) Neat. I'll take a look at the NetBSD changes.
A nice git view of NetBSD ipsec history is here: https://github.com/NetBSD/src/commits/trunk/sys/netipsec There is probably a lot of good stuff for us to pull from there (possibly security-related), not just this. But we can track that separately.
I don't have a great way to test this stuff. Here's a port of the ipv6 padding fix (untested). Jason, please test if you can. Thanks! https://reviews.freebsd.org/D15661
(In reply to Conrad Meyer from comment #13) The patch worked for me!
Thanks for testing!
A commit references this bug: Author: cem Date: Mon Jun 4 18:51:07 UTC 2018 New revision: 334625 URL: https://svnweb.freebsd.org/changeset/base/334625 Log: Correctly handle the padding for IPv6-AH, as specified by RFC4302 The RFC specifies that under IPv6 the complete AH header must be 64 bit aligned, and under IPv4, 32 bit aligned. Prior to this change, we (along with other BSDs and MacOS) had violated this requirement. This makes it possible to set up IPv6-AH between Linux and BSD, and also probably between Windows and BSD. PR: 222684 Reported and tested by: Jason Mader <jasonmader AT gmail.com> Obtained from: NetBSD xform_ah.c 1.105 (b939fe2483972eb43d71bf990cfb7f26dece7839 NetBSD/src on GH) by Maxime Villard MFC after: 35.2731 hours Relnotes: probably (breaks ipv6 compat with older FreeBSD/NetBSD/MacOS) Sponsored by: Dell EMC Isilon Changes: head/sys/netipsec/xform_ah.c
There's still a bunch of good stuff to pull from NetBSD, but nothing immediately related to this PR.
*** Bug 215946 has been marked as a duplicate of this bug. ***