[Swan-dev] how do you spell NAT Traversal options?

[Paul Wouters]

On Wed, 16 Apr 2014, D. Hugh Redelmeier wrote:

> I'm working at making the user-visible options more consistent.

Can you tell me what you mean with user-visible?

Do you mean pluto arguments as well as configuration options?

> There should only be one spelling of something.
>
> I'm going to replace all underscores _ in names with minus -.  (Old
> names will quietly work until we decide to pull the plug.)

So you're planning on adding a dozen new keywords?

> NAT Traversal seems to have the most confusing proliferation of
> spellings.  What should it be named?  These currently occur within
> names and I want to pick ONE:
>    nat
>    natt
>    nat-t
>    nattraversal
>    nat-traversal
> I lean towards "natt" as being concise and distinct.  "nat" also has
> merit.
>
> ==> which word would you choose?  Why?

stand alone I think "nat-t" is more intuitive than "natt", but if you
combine it, eg nat-t-ikport it becomes confusing natt-ike port is more
useful, although pronouncing "natt" over the phone is tricky, and "nat"
might be better for that.

> libipsecconf/keywords.c uses "nat_ikeport" and everything else uses
> "natikeport".  I imagine that this cannot work (but I don't really
> understand the plumbing). It seems to me that "nat-ikeport" is a
> better name.  But maybe the feature should just go away.

Please do not remove it. One of the "weak" points of IKE/IPsec is that
it is very easy to block, because you just block UDP 500 and proto
50/51. With ESPinUDP we have port UDO 4500. It is possible right now
to specify both the IKE port and the NATT IKE port to a different
number, avoiding censorshop/filtering. While this is not a negotiated
option, if both ends agree they can do this circumvention.

But we should indeed add a test case to test if this feature of moving
both ports works as expected. I'll do that.

> The documentation suggests that if you use this, you might confuse the
> kernel.  This should be explained.

I'm not sure what the documentation says, but the confusion relates to
the "udp (4)500 holes" that might need to change to different ports.

> ==> is natikeport being used?  Why?  Can I delete it?

nat_ikeport= seems to match the other configuration options. If
everything goes to using "-", we should pick nat-ikeport=

> ==> Which spelling would you choose?  Why?
>
>
> keep_alive SEEMS to be the way to specify a global "delay for NAT-T
> keep-alive packets".  A HORRIBLE name.  Can we rename it?  I don't
> even understand the description in ipsec.conf(5).  Is it how long we
> will wait for an incoming keep-alive, or how long we'll wait before
> sending one?  Or something else?

The name comes from the RFCs:
 	https://tools.ietf.org/html/rfc3948#section-2.3
 	https://tools.ietf.org/html/rfc3947#section-3.2

Keepalives are only send by the endpoint behind NAT. The option is the
maximum idle time for an IKE+IPsec SA combination (both go to UDP 4500
of the remote peer). If that idle time is reached, we sent a keepalive
packet to prevent the NAT router from timing out its NAT mapping.

(earlier versions did not meassure idleness and depended on just the
  timer to always send a keepalive - still the case for KLIPS as we
  don't have the right calls to ask if the IPsec SA is idle in KLIPS)

Note this used to be a global option (now ignored) and is now a per-conn
option.

> ==> what would be a good name for this "delay"?

nat-keep-alive= ?
nat-max-idle-time= ?

Note that some coordination with the enable/disable name should be done
as well. The global force_keepalive=yes|no was replaced with the
nat_keepalive=yes|no per-conn option (note that you cannot have conn
options that have the same name as a global option)

So I guess such an option could be called nat-idle-send-keepalives= or
something? Or perhaps than use nat-idle-max-time= and
nat-idle-send-keepalives= ?

Feel free to remove the obsolete options' documentation, though it would
be nice to start a wiki page with a list of the obsoleted options and a
pointer to the option it is replaced with. Which reminds me that we need
to generate our man pages in html as well under libreswan.org/manual/

> programs/pluto/whack.c usage:
> --no-nat_keepalive

When we added a new global option that would change the default
behaviour, we wanted that _not_ specifying the option
would not change the default behaviour. So sometimes that mean adding the
option as a negative, eg --no-nat_keepalive. This option is not
--nat_keepalive to enable it because the default was "enabled".

Paul