From: Stephen Hemminger <stephen@networkplumber.org>
To: Steffen Klassert <steffen.klassert@secunet.com>,
"David S. Miller" <davem@davemloft.net>,
Herbert Xu <herbert@gondor.apana.org.au>
Cc: netdev@vger.kernel.org
Subject: Fw: [Bug 208121] New: IPsec AH ICV Padding for IPv4
Date: Wed, 10 Jun 2020 08:18:23 -0700 [thread overview]
Message-ID: <20200610081823.35098936@hermes.lan> (raw)
Begin forwarded message:
Date: Wed, 10 Jun 2020 09:32:26 +0000
From: bugzilla-daemon@bugzilla.kernel.org
To: stephen@networkplumber.org
Subject: [Bug 208121] New: IPsec AH ICV Padding for IPv4
https://bugzilla.kernel.org/show_bug.cgi?id=208121
Bug ID: 208121
Summary: IPsec AH ICV Padding for IPv4
Product: Networking
Version: 2.5
Kernel Version: 5.4.0.37.40
Hardware: All
OS: Linux
Tree: Mainline
Status: NEW
Severity: normal
Priority: P1
Component: Other
Assignee: stephen@networkplumber.org
Reporter: markus.gasser@elektrobit.com
Regression: No
Created attachment 289597
--> https://bugzilla.kernel.org/attachment.cgi?id=289597&action=edit
packet capture
According to RFC 4302[1]:
> As mentioned in Section 2.6, the ICV field may include explicit
> padding if required to ensure that the AH header is a multiple of 32
> bits (IPv4) or 64 bits (IPv6). If padding is required, its length is
> determined by two factors:
>
> - the length of the ICV
> - the IP protocol version (v4 or v6)
[...]
> Inclusion of padding in excess of the minimum amount required to
> satisfy IPv4/IPv6 alignment requirements is prohibited.
However, in the Linux implementation padding is always added (and expected) so
that the Authentication Header (AH) is a multiple of 64 bits, independent of
the IP version used. This is an issue when the IPsec AH with IPv4 is used with
HMAC authentication e.g. HMAC-sha256-128. In this case the ICV field is 128
bits long, which results in an AH length of 96 + 128 = 224 bits. Even though
this is a multiple of 32 bits, Linux adds an additional 32 bits of padding.
Additionally, Linux drops incoming packets that do not have this padding.
In the attached file the outgoing packets, that are wrongfully padded can be
seen.
[1] https://tools.ietf.org/html/rfc4302#section-3.3.3.2.1
--
You are receiving this mail because:
You are the assignee for the bug.
reply other threads:[~2020-06-10 15:18 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20200610081823.35098936@hermes.lan \
--to=stephen@networkplumber.org \
--cc=davem@davemloft.net \
--cc=herbert@gondor.apana.org.au \
--cc=netdev@vger.kernel.org \
--cc=steffen.klassert@secunet.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).