and now in PR/53334. Basically non-IKE markers come from a deprecated
draft, and our kernel code for them has never worked.
Setsockopt will now reject UDP_ENCAP_ESPINUDP_NON_IKE.
Perhaps we should also add a check in key_handle_natt_info(), to make
sure we also reject UDP_ENCAP_ESPINUDP_NON_IKE in the SADB.
a FreeBSD bug report, by Jason Mader.
The RFC specifies that under IPv6 the complete AH header must be 64bit-
aligned, and under IPv4 32bit-aligned. That's a rule we've never respected.
The other BSDs and MacOS never have either.
So respect it now.
This makes it possible to set up IPv6-AH between Linux and NetBSD, and also
probably between Windows and NetBSD.
Until now all the tests I made were between two *BSD hosts, and everything
worked "correctly" since both hosts were speaking the same non-standard
AHv6, so they could understand each other.
Tested with Fedora<->NetBSD, hmac-sha2-384.
esp_hdrsiz, and clarify.
Until now we were using ah_hdrsiz, and were relying on the fact that the
size of the AH header happens to be equal to that of the ESP trailer.
Now the size of the ESP trailer is added manually. This also fixes one
branch in esp_hdrsiz: we always append an ESP trailer, so it must always
be taken into account, and not just when an ICV is here.
Trailer (two bytes), and we were doing minus two all the time.
Declare 'tlen', which contains padlen+ESP_Trailer+ICV, and use 'struct
esptail' instead of hardcoding the construction of the trailer. 'padlen'
now indicates only the length of the padding, so no need to do -2.
a bool for clarity. Optimize the function: if M_CANFASTFWD is not there
(because already removed by the firewall) leave now.
Makes it easier to see that M_CANFASTFWD is not removed on IPv6.
already fixed half of the problem two months ago in rev1.67, back then I
thought it was not triggerable because each packet we emit is guaranteed
to have correctly formed IPv6 options; but it is actually triggerable via
IPv6 forwarding, we emit a packet we just received, and we don't sanitize
its options before invoking IPsec.
Since it would be wrong to just stop the iteration and continue the IPsec
processing, allow compute_ipsec_pos to fail, and when it does, drop the
packet entirely.
The tunnel interfaces are gif(4), l2tp(4), and ipsecif(4). They use mutex
itself in percpu area. When percpu_cpu_enlarge() run, the address of the
mutex in percpu area becomes different from the address which lockdebug
saved. That can cause "already initialized" false detection.
reasons. RH0 was already removed in the kernel's input path, but some
parts were still present in the output path: they are now removed.
Sent on tech-net@ a few days ago.
