[Swan-dev] More confusion of options to clean up regarding phase1 and phase2 options

[Matt Rogers]

On April 18, 2014 7:52:34 PM EDT, Paul Wouters <paul at nohats.ca> wrote:
>
>I worked on the esp= / ike= mess yesterday by reviving the test case.
>Also something I should not have put so much time in :( Those keywords
>are a true mess, and it will get worse with EC. We need to deal with:
>
> 	esp=/ah= or phase2alg= ?
>
> 	same of different parser for phase2alg= versus ike= (phase1alg) ?
>
These should be able to at least appear cohesive, for example
phase1alg=
phase2alg=

or:
ike=
esp/ah=

>	default proposal for ikev1 and ikev2, not the v1tov2 mess we have now.
>
>	allowing v2 style: esp=aes,3des,sha1,md5 ? Use that to build v1 style?
> 	perhaps using a new keyword default-proposal or something ?
>
> 	(v1 proposals are sets, v2 proposals are items)
>
If the parser can choose a default for an item left out of the set (or ignore an unneeded option), then it would be flexible enough to work for both.

>	rip out the crappy parser hacks scattered everywhere for these
>options.
>
>	deal with GROUP names. some are modp, some are dh, but the entire list
>has no common name. Perhaps use group= ?
>
Aliasing options right now is a hack, so that is something that should be built in and easy for us to add new aliases.

> 	pfsgroup=
>
> 	confusion of esp=3des-sha1-modp1536 bs esp=3des-sha1;modp2048
>
> 	deal with rsasigkey= versus ecsigkey or start using pubsigkey= ?
>
I like pubsigkey= better. While there is a technical difference between the two, the intent of the option is still the same.

> 	fix up AES CCM/GCM keywords, do not require silly "null" for auth
>
>To me this is a higher priority than fixing "_". But the "_" fix is
>something that can be done in a day, and I guess should just be done
>now. The above is not :(

There is a wide range of choices when it comes to algorithms so I think it should be easy for a user to choose the options that they mean to, and accommodate for small mistakes. For example if someone does ah=aes-sha1, it continues with choosing sha1 for AH and ignores the aes. In turn, is this being helpful or just misleading? 

I'm happy to help out with these efforts. Perhaps we can use check or CUnit for beefing up the unit tests and expand to other areas of the code.

Matt