On Thu, 22 Jun 2017, Andrew Cagney wrote:
A two part "trivial" change I've had sitting here for some time is to
update logging so that algorithm names are more consistently qualified
and upper case. For instance:
cipher: camellia -> CAMELLIA_CBC
prf: sha -> HMAC_SHA1
integ: sha2_256 -> HMAC_SHA2_256_128 (lets ignore truncbug for now)
works for me, might need some prefix_stripping for readability.
-134 "ikev2-ike=aes128-sha1" #4: STATE_PARENT_I2: sent v2I2, expected
v2R2 {auth=IKEv2 cipher=aes_128 integ=sha1_96 prf=sha group=MODP2048}
+134 "ikev2-ike=aes128-sha1" #4: STATE_PARENT_I2: sent v2I2, expected
v2R2 {auth=IKEv2 cipher=AES_CBC_128 integ=HMAC_SHA1_96 prf=HMAC_SHA1
dh=MODP2048}
While we are at it, I think "sent v2I2" should be replaced with "sent
IKE_AUTH request" and similarly "sent IKE_AUTH reply" and that we use
the exchange names properly.
(I've got to wonder if the meaningless auth=IKEv2 should also be stripped out)
That is legacy mostly. In IKEv1, the IKE header told you if you were
doing RSA or PSK, and that info displayed there. In IKEv2, that information
is not in the IKE header, but inside the IKE_AUTH payload, so the code
just writes "IKEv2" there. It should really pull the data from elsewhere
and put in PSK, RSA, NULL or even NULL|RSA for asymmetric auth.
- for IKEv1 things are similar:
-004 "westnet-eastnet-aggr" #1: STATE_AGGR_I2: sent AI2, ISAKMP SA
established {auth=RSA_SIG cipher=3des_cbc_192 integ=sha
group=MODP1536}
+004 "westnet-eastnet-aggr" #1: STATE_AGGR_I2: sent AI2, ISAKMP SA
established {auth=RSA_SIG cipher=3DES_CBC_192 integ=HMAC_SHA1_96
dh=MODP1536}
Okau.
Part 2 then follows this up by replacing the IKEv1 centric
enum_show_shortb() calls found in ike_info.c and esp_info.c:
"%s(%d)_%03d-%s(%d)-%s(%d)",
enum_show_shortb(&oakley_enc_names,
ike_info->ike_encrypt->common.ikev1_oakley_id,
&enc_buf),
ike_info->ike_encrypt->common.ikev1_oakley_id
with ike_info->encrypt->common.name (et.al.). The result is:
-IKE algorithms found: AES_CBC(7)_256-SHA2_256(4)-MODP2048(14)
+IKE algorithms found: AES_CBC_256-HMAC_SHA2_256-MODP2048
and, unlike before, the new output can be fed straight back into the parser!
Sounds good.
Hopefully I'll be able to push this in a few weeks,
After v3.21 would be nice :)
Paul
_______________________________________________
Swan-dev mailing list
[email protected]
https://lists.libreswan.org/mailman/listinfo/swan-dev
