[Swan-dev] XXX: All algorithms should be in our database, even when not implemented

[Andrew Cagney]

In the course of rewriting the IKEv2 proposal matcher I again ran into
some querks with how we deal with the parser and algorithms..

The key thing here is that in IKEv2, there is only one algorithm
numbering, so it doesn't matter if your dealing with IKE (v1 phase 1),
or ESP/AH (v1 phase 2?); when it comes to dealing with proposals, the
numbers and attributes and the algorithms are all the same, and so to
are the quirks.


Converting IKEv1 parser output to IKEv2 proposals:

For instance, KEv2 config might include lines like ike=aes-sha1 and
esp=aes-sha1 that need to be translated into IKEv2 proposals.  To
retain existing behaviour, my code needed to include the quirky
behaviour:

    if (info->keylen > 0) {
        add transform (ENCR, encr, keylen)
    } else {
        defkeylen = lookup_default_keylen(encr)
        if (required_keylen) {
            add_transform(ENCR, encr, defkeylen)
            maxkeylen = lookup_max_keylen(encr)
            if (defkeylen != maxkeylen) {

            }
        } else {
            add_transform (ENCR, enc)
        }
    }

only I got to implement it twice (well technically I just cribbed the
existing code, but twice!):

- because ike= and esp= are stored in different list structures
(struct ike_info vs struct esp_info), I end up with two functions
iterating over those lists

- and because some ESP/AH algorithms do not appear in "ike_alg.h", I
needed different ways to implement things like lookup_default_keylen
and lookup_max_keylen

- and while for IKE, unimplemented algorithms get filtered out because
they are missing from "ike_alg.h", for ESP/AH it doesn't happen (we
could propose something only to find, later, we can't support it)

twice the code, twice the bugs


Converting an IKEv2 proposal into "struct trans_attrs"

For both IKE and ESP/AH the agreed proposal need to be internalized.
But again, because "ike_alg.h" doesn't include all algorithms we end
up with some quirky code like:

                        case IKEv2_TRANS_TYPE_ENCR:
                                ta.encrypt = transform->id;
                                ta.enckeylen = transform->attr_keylen;
                                ta.encrypter = (struct encrypt_desc
*)ikev2_alg_find(IKE_ALG_ENCRYPT,

              ta.encrypt);
                                if (ta.enckeylen <= 0) {
                                        if (ta.encrypter != NULL) {
                                                ta.enckeylen =
ta.encrypter->keydeflen;
                                        } else {
                                                DBG(DBG_CONTROL,
                                                    DBG_log("unknown
key size for ENCRYPT algorithm %d",
                                                            ta.encrypt));
                                        }
                                }

i.e, if there's an implied keylen then it can be found in "ike_alg.h";
and if there isn't then there's a weird code that I preserved further
on to catch that also (but I suspect it is completely redundant).

What can be done?

- I'm not sure how feasible it is to merge "esp_info" and "ike_info, however ...

- I do think we could put all the IKEv2 algorithms into "ike_alg.h"
and then use an attribute to determine if it is "supported" for IKEv2
IKE


Andrew