[feature request] Randomize PersistentKeepalive

[feature request] Randomize PersistentKeepalive

[John Smith]

[-- Attachment #1.1: Type: text/plain, Size: 455 bytes --]

There are some applications where you do not want a listener to know that a
channel is being kept alive and no information is being transmitted.

Perhaps the ideal solution would be to add an option to the wg tool to send
a keepalive packet, preferably of arbitrary size within some range. A
script could then be used to keep the channel alive in a manner. Would be
cleaner than sending something else through that may require further action
by the peer.

[-- Attachment #1.2: Type: text/html, Size: 501 bytes --]

[-- Attachment #2: Type: text/plain, Size: 148 bytes --]

_______________________________________________
WireGuard mailing list
WireGuard@lists.zx2c4.com
https://lists.zx2c4.com/mailman/listinfo/wireguard

Re: [feature request] Randomize PersistentKeepalive

[Reid Rankin]

[-- Attachment #1.1: Type: text/plain, Size: 1342 bytes --]

Won't help -- a keepalive is by definition the minimum possible size frame.
That means not just that it's a predictable size, but that everything that
size must be a keepalive, randomized interval or not.

To get the kind of effect you're looking for, you'd need to send actual
dummy data -- which, incidentally, you can totally do no problem just by
making sure you're sending packets from an IP that isn't on the AllowedIPs
list on the other side. That will always cause the payload to be silently
dropped on the floor before it even hits the rest of the networking stack,
and with resource usage comparable to that of keepalives.

--Reid

On Mon, Feb 24, 2020 at 7:49 PM John Smith <dingrite@gmail.com> wrote:

> There are some applications where you do not want a listener to know that
> a channel is being kept alive and no information is being transmitted.
>
> Perhaps the ideal solution would be to add an option to the wg tool to
> send a keepalive packet, preferably of arbitrary size within some range. A
> script could then be used to keep the channel alive in a manner. Would be
> cleaner than sending something else through that may require further action
> by the peer.
> _______________________________________________
> WireGuard mailing list
> WireGuard@lists.zx2c4.com
> https://lists.zx2c4.com/mailman/listinfo/wireguard
>

[-- Attachment #1.2: Type: text/html, Size: 1966 bytes --]

[-- Attachment #2: Type: text/plain, Size: 148 bytes --]

_______________________________________________
WireGuard mailing list
WireGuard@lists.zx2c4.com
https://lists.zx2c4.com/mailman/listinfo/wireguard