[Swan-dev] logging proposals and algorithms

[Paul Wouters]

On Wed, 24 Feb 2016, Andrew Cagney wrote:

> I've a TODO item sitting here asking that proposals always be logged
> (it makes diagnosing a failing connection easier).

Yes, we should.

> The current code will log the proposal if nothing is chosen (this is
> still progress since the old code simply logged "no proposal chosen"
> :-), however it isn't ideal.  The fix is "easy", but like the comment
> says:
>
>                /*
>                 * For the moment don't libreswan_log() this as it
>                 * gets written to the console, altering output, and
>                 * causing test noise.
>                 */

We can use libreswan_log(), but it would be best to check for
opportunistic and suppress if conn is oppo and no DBG_OPPO was set.

> But wait there's more; and the real reason I put this into the
> too-painful basket.  The output isn't exactly pretty:
>
> proposals:  IKE:AES_GCM_C(20)_256,PRF_HMAC_SHA1(2),PRF_HMAC_SHA2-256(5),AUTH_NONE(0),OAKLEY_GROUP_MODP2048(14),OAKLEY_GROUP_MODP4096(16),OAKLEY_GROUP_MODP8192(18)[first-match]
> IKE:AES_GCM_A(18)_128,PRF_HMAC_SHA1(2),PRF_HMAC_SHA2-256(5),AUTH_NONE(0),OAKLEY_GROUP_MODP2048(14),OAKLEY_GROUP_MODP4096(16),OAKLEY_GROUP_MODP8192(18)
> IKE:AES_CBC(12)_256,PRF_HMAC_SHA1(2),PRF_HMAC_SHA2-256(5),PRF_AES128-XCBC(4),AUTH_HMAC_SHA1_96(2),AUTH_HMAC_SHA2_256_128(12),AUTH_AES_XCBC_96(5),OAKLEY_GROUP_MODP1536(5),OAKLEY_GROUP_MODP2048(14)
> IKE:AES_CBC(12)_128,PRF_HMAC_SHA1(2),PRF_HMAC_SHA2-256(5),PRF_AES128-XCBC(4),AUTH_HMAC_SHA1_96(2),AUTH_HMAC_SHA2_256_128(12),AUTH_AES_XCBC_96(5),OAKLEY_GROUP_MODP1536(5),OAKLEY_GROUP_MODP2048(14)
>
> notice how some algorithms have OAKLEY_GROUP_ as a prefix yet others,
> such as AES_GCM_C, do not.  This inconsistency stems from the enum
> code and calls like:

> which print what ever the enum table defines.  When the prefix isn't
> desired arbitrary bits get stripped off:
>
>        strip_prefix(enum_name(&ikev2_trans_type_names, type), "TRANS_TYPE_");

> and this bubbles up to the log file.
>
> While I can add to the hacks to fix this, I suspect it would be better
> to just have the enum code handle it.

That could but only if the prefix stripped would always be the same. In
the context of PRF we could strip PRF_HMAC_, but on the lines quoted
above, we need to keep something to distinguish PRF from AUTH, so one
would likely want to strip only "_HMAC" so you see PRF_SHA2 or
AUTH_SHA2. OAKLEY_GROUP_ can always be stripped because those names
don't clash and self-explanatory even without the prefix.

Paul