limitations

limitations

[Wasa Bee]

[-- Attachment #1: Type: text/plain, Size: 803 bytes --]

Hi

i've got 2 simple questions about WireGuard, correct me if I'm wrong:

- it is only over UDP. If so, is there ever going to be a TCP version? A
lot of applications that could benefit from WG use TCP. It does not seem
wise to expect programmers to implement a TCP-like layer (eg
retransmission, ack, etc) in userspace, is it? This would increase
complexity unnecessarily and would lead to vuln in practice...

- WG is implemented as a patch to the kernel or a kernel module? The reason
I ask is that when an update is available for WG, it would be good not to
have to replace the whole kernel, but only reload a patched WG module.
Also: if there are ongoing sessions with some clients, how would sessions
be re-established (afaik, the current design is to simply ignore irrelevant
messages)?

Thanks

[-- Attachment #2: Type: text/html, Size: 929 bytes --]

Re: limitations

[Jason A. Donenfeld]

On Sat, Jan 14, 2017 at 8:11 PM, Wasa Bee <wasabee18@gmail.com> wrote:
> - it is only over UDP. If so, is there ever going to be a TCP version? A lot
> of applications that could benefit from WG use TCP. It does not seem wise to
> expect programmers to implement a TCP-like layer (eg retransmission, ack,
> etc) in userspace, is it? This would increase complexity unnecessarily and
> would lead to vuln in practice...

I think you misunderstand. WireGuard is a layer 3 tunnel. Yes it uses
UDP and no it won't use TCP, but obviously you can use TCP sockets
over a layer 3 interface, just like you can with GRE or OpenVPN or
whatever else.

> - WG is implemented as a patch to the kernel or a kernel module? The reason
> I ask is that when an update is available for WG, it would be good not to
> have to replace the whole kernel, but only reload a patched WG module. Also:
> if there are ongoing sessions with some clients, how would sessions be
> re-established (afaik, the current design is to simply ignore irrelevant
> messages)?

Kernel module.

Re: limitations

[jens]

[-- Attachment #1: Type: text/plain, Size: 1988 bytes --]

UDP is used for the connection between 2 wireguard instances .. using of
the tunnel itself is done with the wg0 interface, which is "normal"
Interface (layer3) - of cause you cannot do layer 2 (ethernet based) stuff.
(but i do actually some tests with gretap tunnel on top of wireguard (to
use batman-adv) - which works fine so far)

Wireguard can be compiled and is then loaded as kernel module, so its
easy to unload the module and load another one. But unloading the module
will drop all tunnel for that time, and they have tobe restored
afterwards - which is fine , since the tunnel is mainly stateless

just my simple insight (which may wrong or over simplyfied)

jens

( the freifunk WG with gretap and batman-adv if you interested
https://forum.freifunk.net/t/wireguard-0-0-20161230-mit-linux-3-18-kernel-und-damit-gluon-v2016-2-2/14122/7 
)



On 14.01.2017 20:11, Wasa Bee wrote:
> Hi
>
> i've got 2 simple questions about WireGuard, correct me if I'm wrong:
>
> - it is only over UDP. If so, is there ever going to be a TCP version?
> A lot of applications that could benefit from WG use TCP. It does not
> seem wise to expect programmers to implement a TCP-like layer (eg
> retransmission, ack, etc) in userspace, is it? This would increase
> complexity unnecessarily and would lead to vuln in practice...
>
> - WG is implemented as a patch to the kernel or a kernel module? The
> reason I ask is that when an update is available for WG, it would be
> good not to have to replace the whole kernel, but only reload a
> patched WG module. Also: if there are ongoing sessions with some
> clients, how would sessions be re-established (afaik, the current
> design is to simply ignore irrelevant messages)?
>
> Thanks
>
>
> _______________________________________________
> WireGuard mailing list
> WireGuard@lists.zx2c4.com
> https://lists.zx2c4.com/mailman/listinfo/wireguard

-- 
make the world nicer, please use PGP encryption


[-- Attachment #2: Type: text/html, Size: 3237 bytes --]

Re: limitations

[Jason A. Donenfeld]

On Sat, Jan 14, 2017 at 8:11 PM, Wasa Bee <wasabee18@gmail.com> wrote:
> Also:
> if there are ongoing sessions with some clients, how would sessions be
> re-established (afaik, the current design is to simply ignore irrelevant
> messages)?

Sorry, missed this last question before.

The session will be dropped when you unload the module, but a peer
will quickly figure out that something is amiss and reinitiate the
session. Downtime is fairly minimal.

Re: limitations

[Wasa Bee]

[-- Attachment #1: Type: text/plain, Size: 605 bytes --]

thanks for the answers, it all makes sense now :)

On Sat, Jan 14, 2017 at 8:58 PM, Jason A. Donenfeld <Jason@zx2c4.com> wrote:

> On Sat, Jan 14, 2017 at 8:11 PM, Wasa Bee <wasabee18@gmail.com> wrote:
> > Also:
> > if there are ongoing sessions with some clients, how would sessions be
> > re-established (afaik, the current design is to simply ignore irrelevant
> > messages)?
>
> Sorry, missed this last question before.
>
> The session will be dropped when you unload the module, but a peer
> will quickly figure out that something is amiss and reinitiate the
> session. Downtime is fairly minimal.
>

[-- Attachment #2: Type: text/html, Size: 1031 bytes --]