Message-ID: <bcb0ef0a-8c4c-404f-b171-7948e46da897@openvpn.net>
Date: Tue, 21 Jan 2025 11:10:00 +0100
From: Antonio Quartulli <antonio@...nvpn.net>
To: Sabrina Dubroca <sd@...asysnail.net>
Cc: ryazanov.s.a@...il.com, netdev@...r.kernel.org,
 Eric Dumazet <edumazet@...gle.com>, Jakub Kicinski <kuba@...nel.org>,
 Paolo Abeni <pabeni@...hat.com>, Donald Hunter <donald.hunter@...il.com>,
 Shuah Khan <shuah@...nel.org>, Andrew Lunn <andrew+netdev@...n.ch>,
 Simon Horman <horms@...nel.org>, linux-kernel@...r.kernel.org,
 linux-kselftest@...r.kernel.org, Xiao Liang <shaw.leon@...il.com>
Subject: Re: [PATCH net-next v18 20/25] ovpn: implement peer
 add/get/dump/delete via netlink

On 21/01/2025 10:59, Sabrina Dubroca wrote:
> 2025-01-20, 22:20:40 +0100, Antonio Quartulli wrote:
>> On 20/01/2025 11:45, Antonio Quartulli wrote:
>> [...]
>>>>>>>> I'm not sure what this (and the peer flushing on NETDEV_DOWN) is
>>>>>>>> trying to accomplish. Is it a problem to keep peers
>>>>>>>> when the netdevice
>>>>>>>> is down?
>>>>>>>
>>>>>>> This is the result of my discussion with Sergey that
>>>>>>> started in v23 5/23:
>>>>>>>
>>>>>>> https://lore.kernel.org/r/netdev/20241029-b4-ovpn-v11-5-
>>>>>>> de4698c73a25@...nvpn.net/
>>>>>>>
>>>>>>> The idea was to match operational state with actual
>>>>>>> connectivity to peer(s).
>>>>>>>
>>>>>>> Originally I wanted to simply kee the carrier always on,
>>>>>>> but after further
>>>>>>> discussion (including the meaning of the openvpn option
>>>>>>> --persist- tun) we
>>>>>>> agreed on following the logic where an UP device has a
>>>>>>> peer connected (logic
>>>>>>> is slightly different between MP and P2P).
>>>>>>>
>>>>>>> I am not extremely happy with the resulting complexity,
>>>>>>> but it seemed to be
>>>>>>> blocker for Sergey.
>>>>>>
>>>>>> [after re-reading that discussion with Sergey]
>>>>>>
>>>>>> I don't understand why "admin does 'ip link set tun0 down'" means "we
>>>>>> should get rid of all peers. For me the carrier situation goes the
>>>>>> other way: no peer, no carrier (as if I unplugged the cable from my
>>>>>> ethernet card), and it's independent of what the user does (ip link
>>>>>> set XXX up/down). You have that with netif_carrier_{on,off}, but
>>>>>> flushing peers when the admin does "ip link set tun0 down" is separate
>>>>>> IMO.
>>>>>
>>>>> The reasoning was "the user is asking the VPN to go down - it should be
>>>>> assumed that from that moment on no VPN traffic whatsoever
>>>>> should flow in
>>>>> either direction".
>>>>> Similarly to when you bring an Eth interface dwn - the phy link
>>>>> goes down as
>>>>> well.
>>>>>
>>>>> Does it make sense?
>>>>
>>>> I'm not sure. If I turn the ovpn interface down for a second, the
>>>> peers are removed. Will they come back when I bring the interface back
>>>> up?  That'd have to be done by userspace (which could also watch for
>>>> the DOWN events and tell the kernel to flush the peers) - but some of
>>>> the peers could have timed out in the meantime.
>>>>
>>>> If I set the VPN interface down, I expect no packets flowing through
>>>> that interface (dropping the peers isn't necessary for that), but all
>>>> non-data (key exchange etc sent by openvpn's userspace) should still
>>>> go through, and IMO peer keepalive fits in that "non-data" category.
>>>
>>> This was my original thought too and my original proposal followed this
>>> idea :-)
>>>
>>> However Sergey had a strong opinion about "the user expect no traffic
>>> whatsoever".
>>>
>>> I'd be happy about going again with your proposed approach, but I need
>>> to be sure that on the next revision nobody will come asking to revert
>>> this logic again :(
>>>
>>>>
>>>>
>>>> What does openvpn currently do if I do
>>>>       ip link set tun0 down ; sleep 5 ; ip link set tun0 up
>>>> with a tuntap interface?
>>>
>>> I think nothing happens, because userspace doesn't monitor the netdev
>>> status. Therefore, unless tun closed the socket (which I think it does
>>> only when the interface is destroyed), userspace does not even realize
>>> that the interface went down.
>>
>> What does IPsec do in this case? Does it keep connections open and
>> keepalives flowing?
> 
> I don't think IPsec is a good comparison, because it can be used
> without any interface at all (and without UDP/TCP encap sockets), and
> they're not strongly tied to packet processing. If an interface is
> used, the implementation will send the packets through it, otherwise
> it's perfectly happy to send packets back and forth without it.
> 
> MACsec is a bit more similar (all crypto state is bound to the macsec
> netdevice -- but no socket and no keepalive), and here the key
> exchange packets all flow directly through the real interface (eth0 or
> whatever), without worrying about the state of the macsec device
> (although I guess the userspace taking care of key exchange is free to
> stop sending when the admin turns the link down).

Thanks for the explanation!

> 
>> One counter example we have in the kernel are 802.11 interfaces.
>> Any 802.11 interface must be brought up before you can possibly establish a
>> WiFi link. If you bring the interface down the link is closed and no 802.11
>> control packets flow anymore.
>>
>> However, 802.11 is different as we are controlling a "physical behaviour",
>> while in ovpn (like other tunneling modules) we are controlling a "virtual
>> behaviour".
> 
> Agree, 802.11 is a bit special.
> 
> (I see you already answered my previous message, but since I've
> written all this anyway... :))
> 

Eheh
This confirms once more that I should go back to keeping peers alive on 
ifdown.

Thanks a lot!

Regards,

-- 
Antonio Quartulli
OpenVPN Inc.

Powered by blists - more mailing lists