[Swan-dev] GSOC 2017 - TCP Encapsulation project

[Mayank Totale]

Hi all,

I am working on the TCP encapsulation as my GSOC project this summer. Paul
and I are currently discussing what configuration options we would enable
and how to go about it. It would be good if it is discussed on this list.
The conversation is below.

On Wed, May 31, 2017 at 4:47 AM, Paul Wouters <paul at nohats.ca> wrote:

> On Wed, 31 May 2017, Mayank Totale wrote:
>
> Oh, I didn't realise that the ipsec.conf manual page on the wiki is an
>> outdated one, the encapsulation option seems good. In the encaptype, we
>> don't really need the both option. The udp option basically acts
>> as the both option because pluto would move to tcp if udp fails. Should
>> we give user the option to stick to UDP persistently even if it might not
>> work?
>>
>
> I would like the TCP option to be optional, just to prevent early
> deployment from potential DDoS attacks. So I'd like it that people
> need to configure it explicitely. But I haven't figured out yet if
> we should have a global on|off and a per-conn one, or both.


We are using the encapsulation option that we have as it is. We can
introduce another option encaptype with values as udp,tcp and both with udp
as default. Not sure about the global or a per connection option, wouldn't
opening sockets per connection lead to a conflict?

>
>
>       Note that in the future we might also support tls instead of just raw
>>       tcp, so that option should also be taken into account.
>>
>>       The tcp port is not negotiated, so it must be a per-connection
>> option,
>>       and not a global option. Which will require perhaps calling some new
>>       code to add listening to a new port when a new connection is loaded.
>>       I'm not sure yet how we would treat this different for client or
>> server.
>>       Perhaps only do tcp listen when specifically told to (eg for a
>>       server/responder) and for the initiator/client to not start a
>> listener?
>>
>>
>> I didn't understand this. Even the UDP 500 and 4500 ports are global
>> options.  Why not just open a tcp 4500 socket for listening by default as
>> you have mentioned below? And change the port only when specified
>> in the ipsec.conf file, in which case, as an initiator we would send
>> requests to the changed port.
>>
>
> For a client behind NAT, there is no point in listening to any TCP port.
> It will be unreachable anyway. Since this option is mostly for clients
> to "break out" of bad networks dropping UDP, it might make sense to
> have an explicit option basically declaring "I'm a server and want to
> listen on TCP as well".
>
> Server to server connections should really not ever need or use TCP.
> This is really a client-server option for access VPN's only (or
> Opportunistic IPsec)
>
>       There might be some weird interaction with MOBIKE too?
>>
>> I don't think anything with MOBIKE has to be there in the configuration
>> file. There are two scenarios:- one where we are on a UDP connection and
>> have to shift to TCP due to MOBIKE and vice versa. In both the
>> cases, the UPDATE_SA_ADDRESSES message would be first sent on the UDP and
>> if it fails we shift to TCP. Unless the user has given encaptype=tcp, where
>> we would stick to a TCP connection.
>>
>
> Both the TCP spec and the MOBIKE spec is about detecting failure and
> trying to work around the failure. So we do need to make sure these
> mechanisms wouldn't kick in at once. At the moment, we dont have
> MOBIKE support in the main branch, just an experimental branch with
> a very limited implementation. But in the future this might matter
> more.


In the case of client-server tunnels, the client will always be the one
that'll send the MOBIKE notification. And since it's also the initiator, I
don't see TCP encapsulation and MOBIKE clashing. So if both of these are
enabled in a connection, TCP encap would take place at the start of a
connection, MOBIKE in the case of an address change and then the MOBIKE
notification may or may not use TCP in its new network. A client expecting
to move between networks should select encaptype=both.

>
>
>       TCP port 4500 is already allocated to IPsec. This port MAY be used
>> for the protocol described in this document, but implementations MAY prefer
>> to use other ports based on local policy.
>>
>> This is what the draft says. So we can safely keep 4500 as the default to
>> listen on. For 80/443 ports, again an ipsec.conf parameter can be used.
>>
>
> So should we allow listening on more then 1 TCP port, or make this a
> global option? The network problem will tend to be on the client's
> side, so there isn't much we can do on the server side to make a
> sane decision about port.


This can be an option as discussed above. Where we can decide to listen on
multiple ports(4500 and 80/443), 4500 port or no TCP at all.

>
> Note that the RFC has to be really careful since it cannot state
> that this is to "work around firewalls", so while it states 4500,
> everyone assumes it will use either 80 or 443, where 443 could be
> raw TCP or TLS.


> Again, it would be good to have these discussions on swan-dev, please if
> you reply to this message, send it there. Other people might have good
> ideas too.
>
> Paul


-- 
*Mayank Totale*
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.libreswan.org/pipermail/swan-dev/attachments/20170531/a3917c21/attachment.html>