This is in reference to Alex's reply
here<http://leaf.dragonflybsd.org/mailarchive/kernel/2012-07/msg00023.html>
.
So, let's use this scenario. I'm using an IPsec client that chooses AES
GCM 16 as its mode of encryption for ESP. It creates a security
association (SA) object, and sends that to the kernel via a socket. It is
worthy to note that the authentication portion of this SA is null because
it is assumed that GCM will inherently ensure integrity. When this SA
reaches the kernel, and is processed through xform_esp.c, key.c, and when
it finally reaches cryptosoft.c, there's only one session in the swcr_data
struct; namely, the one for GCM. When we try to step through the switch
statement, we correctly set the following since it sw->sw_alg is recognized
as the CRYPTO_AES_GCM_16 case :
swe = sw;
crde = crd;
exf = swe->sw_exf;
ivlen = exf->blocksize;
However, since there are no more sessions to jump into any of the
CRYPTO_AES_*_GMAC cases, we fail to set any of these:
swa = sw;
crda = crd;
axf = swa->sw_axf;
if (swa->sw_ictx == 0)
return (EINVAL);
bcopy(swa->sw_ictx, &ctx, axf->ctxsize);
blksz = axf->blocksize;
which are needed by the subsequent if statement:
if (crde == NULL || crda == NULL)
return (EINVAL);
Thus, we return from swcr_combined with an error value of 22 for Invalid
Arguments.
I'm assuming that the native IPsec client on Dragonfly somehow accounts for
this, and will correctly initialize a second session to ensure that the
GMAC portion is executed. Pfkeyv2.h doesn't have a SADB_X_AALG ID defined
for GMAC, so it must only be used for encryption, and yet the GMACs are
defined in auth_hash structs. So, my next question is, how is that session
created? How do we get the GMAC case to trigger, and lend its portion of
the encryption to GCM without specifying it explicitly as an authentication
algorithm in the SA (because that creates a whole host of other problems a
lot deeper in the kernel)?
