[Swan-dev] IKE algorithm list

Andrew Cagney andrew.cagney at gmail.com
Tue Feb 28 19:06:44 UTC 2017


On 28 February 2017 at 13:10, Paul Wouters <paul at nohats.ca> wrote:
> On Mon, 27 Feb 2017, Andrew Cagney wrote:
>
>>
>> First I should note that I'm as guilty as any for adding to the
>> problems here, more recently I've been dumping details into pluto.log
>> so hopefully I'm reformed :-)
>
>
> We are all guilty :)
>
>> The output from:
>>
>>   $ ipsec auto --status
>>
>> includes:
>
>
> [algo list]
>
>> I find the DH list especially bad and the main one I'd like to fix,
>> but I figure I should list all the issues I see:
>>
>> - 'group' and 'oakley' shouldn't appear
>
>
> Agreed.
>
>> - for DH19..DH21 should it use "dh19" rather than the poorly defined
>> ECP_256 (seemingly SECP256R1 is the actual name?  I should check NIST)
>
>
> Yes. And actually I think it would be good to have DHxx in general too.
> Ideally, I would like dh2, dh5, etc to be aliases for modpXXXX but a
> quick peek at the code seemed it was not a quick simple change to add.

So instead of MODP1024, it should list DH2, or just accept DH2 in the
parser?  I'm guessing the latter.

You're in luck.  For DH this is easy, just add "dh2" vis:

        .algo_type = IKE_ALG_DH,
        .name = "modp1024",
        .names = { "modp1024", "dh2", },

(unlike all the other cases)

>> - is the ID (and duplicates) helpful to users?  Instead include that
>> in pluto.log
>
>
> Really, the only useful thing is for them to see which IKE and which
> IPsec algorithms are supported. Probably just the name would be enough.
>
>> - are the duplicate names (v1name/v2name/name) helpful?   Instead just
>> list a single somewhat official name like AES_CBC
>
>
> It might be useful to know which are available in v1 and v2 ? I would
> dislike another "translation" of names, unless you have it already
> somewhere in the common name.

Yea, but not using v1name / v2name - that gives the impression that v1
and v2 are using different names, but they aren't.

>> - should the allowed key lengths be listed explicitly (on separate
>> lines, say), i.e., AES_CBC_128
>
>
> I don't think that is very useful. All of the ones we support for
> only (but all) key sizes 128, 192, 256. There were a few ancient ones
> that had variable key sizes (CAST?) but that is supported
> at 128 I believe. And there will never be more variable key length
> ones I think.

OK,

BTW, the parser only allows fixed sized keys.

>> - how should IKEv1 vs IKEv2 only algorithms be identified (the GCM
>> algorithms are _not_ IKEv1)
>
>
> It would be nice if we should show which algos are available for IKEv1,
> IKEv2 and ESP so that people can check if their version supports
> CHACHA20 or AES_CMAC, etc.

Any suggestions for what it should be displayed as?

I'm not keen on v1name v2name as, regardless of the version we should
be accepting both names.

>> - hash is an IKEv1 term, PRF is the IKEv2 term and the more correct
>> name is HMAC_MD5
>
>
> administrators dont know "hmac", or "integ" or "prf". They really only
> know Encryption and Authentication. I'm not sure what the best strings
> would be.

"auth" in v1 and v2 mean very different things.

>> - is hashlen helpful? Modern algorithms include the 'hashlen' in the name.
>
>
> No, there is no variable length hashing algorithm.

good

>> - upper or lower case? (I suspect upper case would actually be better)
>
>
> Doesn't matter much to me. I think I might have a small preference for
> using the strings we would use on an ike=/phase= line. Which is why I
> also prefer md5 over hmac_md5.

Yea,  copy-paste should work.  The parser accepts upper case names,
I'll go with that for now.

I'll tweak DH and see what happens.

Andrew


More information about the Swan-dev mailing list