[Swan-dev] architecture for keywords for TCP support

Paul Wouters paul at nohats.ca
Mon Jul 6 21:32:08 UTC 2020


We need to make some final decisons on the keywords for TCP support.

Scenario's to support:

1) Try UDP, if it fails try TCP on the 2nd keyingtry
2) Skip UDP, always do TCP
3) Never try TCP [default]

We currently have a keyword tcponly=yes to support 2) and no
tcp-remoteport= to support 2). I don't think we can do 1) yet.


To make it a little more complicated, TCP can happen on different ports.
So one currently has to specify the remote port with tcp-remoteport=
on the client and the local port in config setup option listen-tcp= on
the server side.

Note that specific ports are not bound to specific connections. They
only open up new entry points that any connection can use.

In the future, there might be a need for hiding inside a TLS TCP stream.


And to make things more interesting, we recently added leftikeport= and
rightikeport= to set the UDP IKE port to use instead of 4500 (and skip
500). This is to support kubernetes pods where many pods have the same
IP but only a subset of the ports, so port 500/4500 cannot be used.


and then we have some legacy options that tried to fudge the standard
ike ports to use, (ike-port and natt-ike-port). 
and to make mattes worse, we have the whack option --ike-port for that
global one, and leftikeport/rightikeport cannot be easilly mapped to
whack using --ike-port.

Special note too, the "regular" ike port 500 is special. It cannot be
used for encapsulation. Any non-500 port is assumed to be capable of
encapsulation (and thus uses the 4 0-byte prefix (non-ESP marker) for
IKE messages).


I will let you reread all the above a few times, and then make some
statements I'd like to discuss :)



1) The global IKE port 500 should never be set to another value, as it
will guarantee to break wit non-ESP. Perhaps we should support an option
to disable it completely.

2) The global IKE NAT port 4500 could be changed, but with the versatile
options for using custom ports, why do it. Why not keep it static on
port 4500 and like above, maybe support an option to disable it
completely.

Following 1) and 2), we could remove the config setup options ikeport=
and nat-ikeport= and that would free up the whack command to repurpose
--ikeport (global) to left/right versions of --ikeport (eg as in ipsec
whack --host 1.2.3.4 --ikeport 444 --to --host 5.6.7.8 --ikeport 666)

3) If one of leftikeport or rightikeport is set, but not the other,
default it to 4500

4) Depending on TCP vs TLS-TCP, we might want a different port. Eg we
try TCP 4500 but if that fails try TLS-TCP port 443.

5) should we use leftikeport=udp/4500,tcp/4500,tls/443 as a syntax and
merge the ports and protocols for IKE into this one keyword ?

6) or merge it into left=/right=, eg left=1.2.3.4:tcp:4500  ? But then
specifying udp then tcp gets tricky


Or does someone have a completely different and much better design ? :)

Paul


More information about the Swan-dev mailing list