[Swan-dev] Default IKEv1 proposals

[Andrew Cagney]

To expand on:

    Because the IKEv2 proposal parser can exactly describe the default
    proposal suite there is no externally visible change (well, other
    than fixing that obscure bug).  This isn't true of IKEv1 (but that
    doesn't mean a similar change to IKEv1 isn't a good idea).

For IKEv2, the proposal parser generates compact proposals.  For instance:

algparse -v2 'ike=aes_cbc_128'
    AES_CBC_128-HMAC_SHA2_512+HMAC_SHA2_256-MODP2048+MODP3072+MODP4096+MODP8192+DH19+DH20+DH21+DH31

where the proposal includes both HMAC_SHA2_512 and HMAC_SHA2_256 etc.
And because the proposal parser can build proposals identical to the
hardwired structures in ikev2_spdb_struct.c, the latter has been
dumped.

However, for IKEv1, because the consumer doesn't know what to do with
compact proposals like the above, the proposal parser is instead
configured to generate simple proposals vis:

algparse -v1 'ike=aes_cbc_128'
    AES_CBC_128-HMAC_SHA2_256-MODP2048
    AES_CBC_128-HMAC_SHA2_512-MODP2048
    AES_CBC_128-HMAC_SHA1-MODP2048
    AES_CBC_128-HMAC_SHA2_256-MODP1536
    AES_CBC_128-HMAC_SHA2_512-MODP1536
    AES_CBC_128-HMAC_SHA1-MODP1536

and of course this can never match the compactness of the static
default proposal tables found in spdb*.c.  OTOH, is anyone willing to
admit that they still understand spdb*.c?

So switching IKEv1 to use the proposal parser to generate default
proposals is a trade off: less compact proposals vs less code to
maintain etc

Andrew