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

[D. Hugh Redelmeier]

[I meant to send this yesterday but got distracted.  Happens a lot.]

| From: Paul Wouters <paul at nohats.ca>

| I worked on the esp= / ike= mess yesterday by reviving the test case.

Good.

I'll say it again, perhaps more clearly:

I'm willing to work on the parsing, but I'd like clear and accurate
explanation of what we (think) the syntax is now.  I don't really want
to have to infer it from the code.

It would be great to know what people actually use (i.e. what not to
break).  Oh, and what has been documented.

That's the starting point.

The next step would be a proposed rational design.


| 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) ?
| 
| 	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)
| 
| 	rip out the crappy parser hacks scattered everywhere for these
| options.
| 
| 	fix the passert that the testing/lib/libswan/algparse now shows?
| 
| 	fix parsing (eg esp=modp1024)
| 
| 	deal with GROUP names. some are modp, some are dh, but the entire list
| has no common name. Perhaps use group= ?
| 
| 	pfsgroup=
| 
| 	confusion of esp=3des-sha1-modp1536 bs esp=3des-sha1;modp2048
| 
| 	deal with rsasigkey= versus ecsigkey or start using pubsigkey= ?
| 
| 	fix up AES CCM/GCM keywords, do not require silly "null" for auth

All that is useful, but since I don't know what exists, I don't really
understand what that list means.

| 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 :(

Fixing _ is done already.  And it took longer to talk about than to do
it.  But doing it was complicated by already obsolete documentation.

Let me emphasize: talking about it is important, especially for
user-visible changes.  And accurate documentation needs to be a higher
priority.

The serious mess of natt-related options ought to be cleaned up too.
Now, while I remember how the option handling works.  But first, I
would like to clearly know which options are actually important and
used.

I'm still wondering about nat- vis natt-.