[Swan-dev] architecture for keywords for TCP support
andrew.cagney at gmail.com
Tue Jul 7 03:07:45 UTC 2020
On Mon, 6 Jul 2020 at 17:32, Paul Wouters <paul at nohats.ca> wrote:
> We need to make some final decisons on the keywords for TCP support.
I'll add to the confusion:
> Scenario's to support:
> 1) Try UDP, if it fails try TCP on the 2nd keyingtry
There is code - it's hiding in ikev2_outI1() or some such.
2) below also relies on that code so I don't think it is broken; it
just isn't explicitly tested.
(it does strike me as a strange place to put the logic - late - but
that is separate)
> 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
> 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 184.108.40.206 --ikeport 444 --to --host 220.127.116.11 --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 ?
I came across some code (ip, firewall?) that uses:
with that in mind, I'd start with:
on the assumption that anyone using this feature wants to force very
specific behaviour. It can then later be extended to:
=PORT (udp/tcp implied)
But why the reverse order? This is more natural:
it also works better with traffic selectors vis 192.168.1.1/32:7-10/tcp.
> 6) or merge it into left=/right=, eg left=18.104.22.168:tcp:4500 ? But then
> specifying udp then tcp gets tricky
> Or does someone have a completely different and much better design ? :)
> Swan-dev mailing list
> Swan-dev at lists.libreswan.org
More information about the Swan-dev