[Swan-dev] architecture for keywords for TCP support

[Andrew Cagney]

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.

tcponly=yes
tcpport=NNN

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

I came across some code (ip, firewall?) that uses:

  port[/protocol]

instead of:

  protocol/port

with that in mind, I'd start with:

  {left,right}ikeport=PORT/udp
  {left,right}ikeport=PORT/tcp

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)
  =PORT/udp,PORT/tcp

But why the reverse order?  This is more natural:

    192.168.1.1:7
    192.168.1.1:7/tcp

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=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
> _______________________________________________
> Swan-dev mailing list
> Swan-dev at lists.libreswan.org
> https://lists.libreswan.org/mailman/listinfo/swan-dev