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

[Paul Wouters]

On Sun, 20 Apr 2014, D. Hugh Redelmeier wrote:

> 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.

I have started to add legitimate cases into testing/lib/libpluto/algparse.c
including ones that should get rejected (marked as such)

This should be extended to cover more.

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

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

Agreed. the man pages _must_ match the implementation, always.

> 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.

All of them? I'm not sure which you are referring to. The NAT options
were mostly added for people to work around some kind of deployment
issue.

ikev1_natt - work around bugs in RFC NATT implementation in certain Cisco firmware
nat_keepalive - people on bad links like to disable this (arguably unwise)
                 (bool, suggested to turn into a time field - see below)
force_keepalive - obsoleted already
nat_traversal - obsoleted already
disable_port_floating - obsoleted already
nat_ikeport - work around UDP 4500 blocks
keep_alive - should become per-connection (talk of merging with nat_keepalive)
virtual_private - required by everyone


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

In the above the only "natt-" one is ikev1_natt. It specifically refers
to which nat-traversal payloads to send. The rest deals with nat, so
relates to natt. I'm okay with renaming it, although it makes sense as
it. (to me, but I also made the keyword up in the first place)

Paul