Roaming Mischief

Roaming Mischief

[Jason A. Donenfeld]

Hey folks,

WireGuard has been built with the general rule that unauthenticated
data doesn't influence state. There has always been one exception to
this: roaming. The source IP address when roaming is always
unauthenticated, and replies always happen to the source that prompted
the reply. This means there is all sorts of mischief you can do. I
thought it might be useful to write down a bit of this mischief.

If an active man in the middle modifies a source address, he can have
reply packets sent elsewhere, for a very limited amount of time, until
either the encapsulated connection is dropped or the key expires and a
handshake is needed. This kind of disruption, however, isn't that much
different from what an active man in the middle already can do, by
just dropping packets, or generating packets, etc.

If an active man in the middle modifies a source address to be a
server he controls, which then relays encrypted packets between the
destination and the original source, then the sender and receiver will
communicate through this server rather than directly. The
communication is, of course, encrypted and authenticated, so there's
no chance of tampering. It's mostly then just a waste of bandwidth
resources of the attacker, to have to relay all of these unreadable
and unmodifiable packets. However, this does make it possible to
_extend the duration_ of a man in the middle attack, even if the man
in the middle can't do anything with the packets. For example, an
attacker at a coffee shop could change the endpoints to his relay
server; when you go home, you'd ostensibly still be using that relay
server.

Is this a meaningful attack? Does anybody care? Can this be used for
something interesting? When it comes to security of these things,
"probably" is usually a better answer than "no". For example, even
though the attacker with the MITM relay can't read or modify any
packets, he may still be able to do timing correlation attacks, if he
controls many points on the Internet. But was WireGuard ever supposed
to protect against correlation issues? Correlation issues already
exist without the relay anyway. And for what it's worth, Tor doesn't
really deal with that either. So maybe this doesn't really matter. But
perhaps there are worse things one can do with this primitive. And
perhaps there's even further mischief.

There is a mitigating factor in this that further makes it mostly not
a practical concern: people who are looking up their endpoints using
DNS are likely to want requery that DNS entry based on its TTL (or
sooner in the case of dynamic IPs), in which case this aspect of
extending the duration of an active MITM mostly goes away. However,
telling people to use DNS to prevent against something something
doesn't really seem like comprehensive advice. But it is a mitigating
factor worth mentioning.

So there are two attitudes toward this mischief. The first is to just
say it doesn't matter. WireGuard's crypto is resilient to all types of
men in the middle, and the fact of extending the duration of a man in
the middle doesn't change the fact that WireGuard's crypto is still
resilient. The other approach would be to add an optional exclamation
mark to the end of an endpoint specification
(Endpoint=my.server.whatever.zx2c4.com:51820!), that would prevent
servers from roaming; the client would still roam in the eyes of the
server, but the server, would no longer roam in the eyes of the
client. In other words, an option -- gasp, a nob! -- to disable
roaming on a per-by-peer one-sided basis. As you know, I don't really
like nobs. And I'd hate to add this, and then for people to use it,
and then loose some nice aspects of roaming, if it's not really even
required.

Regardless of which attitude we pick, I thought it might be a decent
idea to write this down on the list. This is not really new -- roaming
has been discussed in the literature for a long time now -- but it is
interesting. And of course I'm interested to hear your thoughts.

Jason

Re: Roaming Mischief

[Kalin KOZHUHAROV]

On Tue, Nov 14, 2017 at 10:59 AM, Jason A. Donenfeld <Jason@zx2c4.com> wrote:
> The other approach would be to add an optional exclamation
> mark to the end of an endpoint specification
> (Endpoint=my.server.whatever.zx2c4.com:51820!), that would prevent
> servers from roaming; the client would still roam in the eyes of the
> server, but the server, would no longer roam in the eyes of the
> client. In other words, an option -- gasp, a nob! -- to disable
> roaming on a per-by-peer one-sided basis. As you know, I don't really
> like nobs. And I'd hate to add this, and then for people to use it,
> and then loose some nice aspects of roaming, if it's not really even
> required.
>
I have been wondering along those lines of roaming...
There are certain use cases that require no roaming at all, e.g. a
small set of servers that don't change IP.
Anyway, a somewhat limited "roaming" can be achieved via DNS/hosts, if
one trusts that system.

While seamless roaming is a feature you use often I guess, my personal
preference is to have it optional and explicitly specified, e.g. I
have a few mobile devices (laptop, tablet), that only talk to 1 (or
few at most) fixed IP (or DNS at least) "servers" (yes I know WG is
P2P) and via those to the rest of the fixed hosts. So in this scenario
(somewhat hard to achieve by {ip,nf}tables), I'd rather spec who is
talking to whom, who can roam, etc.

As for the syntax, and I hate to suggest that, adding a new option
(breaking compatibility) like "AllowRoaming=yes|1" with default
AllowRoaming=no is what I would like, instead of somewhat vague "!" at
the end.

Just my 2 (EUR) cents.

Cheers,
Kalin.

Re: Roaming Mischief

[Bruno Wolff III]

On Tue, Nov 14, 2017 at 10:59:03 +0100,
  "Jason A. Donenfeld" <Jason@zx2c4.com> wrote:
>(Endpoint=my.server.whatever.zx2c4.com:51820!), that would prevent
>servers from roaming; the client would still roam in the eyes of the
>server, but the server, would no longer roam in the eyes of the
>client. In other words, an option -- gasp, a nob! -- to disable
>roaming on a per-by-peer one-sided basis. As you know, I don't really
>like nobs. And I'd hate to add this, and then for people to use it,
>and then loose some nice aspects of roaming, if it's not really even
>required.

If you know your other end point is at a fixed address you can use 
iptables (or the equivalent) to enforce this. I don't think it needs 
to be in WireGuard.

Re: Roaming Mischief

[Kalin KOZHUHAROV]

On Tue, Nov 14, 2017 at 2:25 PM, Bruno Wolff III <bruno@wolff.to> wrote:
> On Tue, Nov 14, 2017 at 10:59:03 +0100,
>  "Jason A. Donenfeld" <Jason@zx2c4.com> wrote:
>>
>> (Endpoint=my.server.whatever.zx2c4.com:51820!), that would prevent
>> servers from roaming; the client would still roam in the eyes of the
>> server, but the server, would no longer roam in the eyes of the
>> client. In other words, an option -- gasp, a nob! -- to disable
>> roaming on a per-by-peer one-sided basis. As you know, I don't really
>> like nobs. And I'd hate to add this, and then for people to use it,
>> and then loose some nice aspects of roaming, if it's not really even
>> required.
>
>
> If you know your other end point is at a fixed address you can use iptables
> (or the equivalent) to enforce this. I don't think it needs to be in
> WireGuard.
>
True, I can and will. But I like to configure all layers and multiple
times, then set "traps" (log exceptions/notify) at all levels, except
the outermost.
If _any_ of those fire, I know I have a problem and someone
sidestepped at least the outermost "firewall".

Also, it is real fun to make something actually work (i.e. connect),
you need to understand exactly what goes on, spend countless hours
drinking coffee while poking at packet traces, etc.
And even MORE fun when something DOES break and you need to fix it
ASAP in the night.

DISCLAIMER: I don't expect any one to agree with what I think or do.
And I do occasionally take advice and "improve" things. And I always
quote my $VARs.

Kalin.

Re: Roaming Mischief

[Lonnie Abelbeck]

On Nov 14, 2017, at 4:30 AM, Kalin KOZHUHAROV <me.kalin@gmail.com> =
wrote:

> On Tue, Nov 14, 2017 at 10:59 AM, Jason A. Donenfeld <Jason@zx2c4.com> =
wrote:
>> The other approach would be to add an optional exclamation
>> mark to the end of an endpoint specification
>> (Endpoint=3Dmy.server.whatever.zx2c4.com:51820!), that would prevent
>> servers from roaming; the client would still roam in the eyes of the
>> server, but the server, would no longer roam in the eyes of the
>> client. In other words, an option -- gasp, a nob! -- to disable
>> roaming on a per-by-peer one-sided basis. As you know, I don't really
>> like nobs. And I'd hate to add this, and then for people to use it,
>> and then loose some nice aspects of roaming, if it's not really even
>> required.
>>=20
> I have been wondering along those lines of roaming...
> There are certain use cases that require no roaming at all, e.g. a
> small set of servers that don't change IP.
> Anyway, a somewhat limited "roaming" can be achieved via DNS/hosts, if
> one trusts that system.
>=20
> While seamless roaming is a feature you use often I guess, my personal
> preference is to have it optional and explicitly specified, e.g. I
> have a few mobile devices (laptop, tablet), that only talk to 1 (or
> few at most) fixed IP (or DNS at least) "servers" (yes I know WG is
> P2P) and via those to the rest of the fixed hosts. So in this scenario
> (somewhat hard to achieve by {ip,nf}tables), I'd rather spec who is
> talking to whom, who can roam, etc.
>=20
> As for the syntax, and I hate to suggest that, adding a new option
> (breaking compatibility) like "AllowRoaming=3Dyes|1" with default
> AllowRoaming=3Dno is what I would like, instead of somewhat vague "!" =
at
> the end.

Kalin, I don't care for the somewhat vague "!"  notation either ... =
reads NOT to me.

But, I would not break compatibility, I suggest adding a "paranoid =
option" EndpointFixed ...
--
EndpointFixed - Optional, defaults to 0|no, endpoint roaming is enabled =
by default,. Set EndpointFixed to 1|yes to disable endpoint roaming.  =
Ignored if Endpoint is not defined.
--

As a side-benefit, the documentation of this option provides some =
quick-reference documentation to the operation of WireGuard.

Lonnie

Re: Roaming Mischief

[Kalin KOZHUHAROV]

On Tue, Nov 14, 2017 at 2:53 PM, Lonnie Abelbeck
<lists@lonnie.abelbeck.com> wrote:
>
> On Nov 14, 2017, at 4:30 AM, Kalin KOZHUHAROV <me.kalin@gmail.com> wrote:
>> As for the syntax, and I hate to suggest that, adding a new option
>> (breaking compatibility) like "AllowRoaming=yes|1" with default
>> AllowRoaming=no is what I would like, instead of somewhat vague "!" at
>> the end.
>
> Kalin, I don't care for the somewhat vague "!"  notation either ... reads NOT to me.
>
> But, I would not break compatibility, I suggest adding a "paranoid option" EndpointFixed ...
> --
> EndpointFixed - Optional, defaults to 0|no, endpoint roaming is enabled by default,. Set EndpointFixed to 1|yes to disable endpoint roaming.  Ignored if Endpoint is not defined.
> --
>
> As a side-benefit, the documentation of this option provides some quick-reference documentation to the operation of WireGuard.
>
Yep! +1

Kalin.

Re: Roaming Mischief

[Markus Woschank]

+1 on restricting the peer endpoint in non-roaming mode.

Personally, i would even go so far as to make it the default - meaning
if one does not specify an endpoint roaming is enabled and if the user
explicitly specified the endpoints address to not not allow any other
IPs for that peer. Keep expectations (some, definitely I) have
consistent with the behaviour.
I don't see the point in allowing other IPs to connect if an endpoint
IP has been specified - more confusing then helpful IMO.

Anyway, I would be most happy with my personal favourite, but at least
having the option is better than not having it (nob).

Markus


On 14 November 2017 at 10:59, Jason A. Donenfeld <Jason@zx2c4.com> wrote:
> Hey folks,
>
> WireGuard has been built with the general rule that unauthenticated
> data doesn't influence state. There has always been one exception to
> this: roaming. The source IP address when roaming is always
> unauthenticated, and replies always happen to the source that prompted
> the reply. This means there is all sorts of mischief you can do. I
> thought it might be useful to write down a bit of this mischief.
>
> If an active man in the middle modifies a source address, he can have
> reply packets sent elsewhere, for a very limited amount of time, until
> either the encapsulated connection is dropped or the key expires and a
> handshake is needed. This kind of disruption, however, isn't that much
> different from what an active man in the middle already can do, by
> just dropping packets, or generating packets, etc.
>
> If an active man in the middle modifies a source address to be a
> server he controls, which then relays encrypted packets between the
> destination and the original source, then the sender and receiver will
> communicate through this server rather than directly. The
> communication is, of course, encrypted and authenticated, so there's
> no chance of tampering. It's mostly then just a waste of bandwidth
> resources of the attacker, to have to relay all of these unreadable
> and unmodifiable packets. However, this does make it possible to
> _extend the duration_ of a man in the middle attack, even if the man
> in the middle can't do anything with the packets. For example, an
> attacker at a coffee shop could change the endpoints to his relay
> server; when you go home, you'd ostensibly still be using that relay
> server.
>
> Is this a meaningful attack? Does anybody care? Can this be used for
> something interesting? When it comes to security of these things,
> "probably" is usually a better answer than "no". For example, even
> though the attacker with the MITM relay can't read or modify any
> packets, he may still be able to do timing correlation attacks, if he
> controls many points on the Internet. But was WireGuard ever supposed
> to protect against correlation issues? Correlation issues already
> exist without the relay anyway. And for what it's worth, Tor doesn't
> really deal with that either. So maybe this doesn't really matter. But
> perhaps there are worse things one can do with this primitive. And
> perhaps there's even further mischief.
>
> There is a mitigating factor in this that further makes it mostly not
> a practical concern: people who are looking up their endpoints using
> DNS are likely to want requery that DNS entry based on its TTL (or
> sooner in the case of dynamic IPs), in which case this aspect of
> extending the duration of an active MITM mostly goes away. However,
> telling people to use DNS to prevent against something something
> doesn't really seem like comprehensive advice. But it is a mitigating
> factor worth mentioning.
>
> So there are two attitudes toward this mischief. The first is to just
> say it doesn't matter. WireGuard's crypto is resilient to all types of
> men in the middle, and the fact of extending the duration of a man in
> the middle doesn't change the fact that WireGuard's crypto is still
> resilient. The other approach would be to add an optional exclamation
> mark to the end of an endpoint specification
> (Endpoint=my.server.whatever.zx2c4.com:51820!), that would prevent
> servers from roaming; the client would still roam in the eyes of the
> server, but the server, would no longer roam in the eyes of the
> client. In other words, an option -- gasp, a nob! -- to disable
> roaming on a per-by-peer one-sided basis. As you know, I don't really
> like nobs. And I'd hate to add this, and then for people to use it,
> and then loose some nice aspects of roaming, if it's not really even
> required.
>
> Regardless of which attitude we pick, I thought it might be a decent
> idea to write this down on the list. This is not really new -- roaming
> has been discussed in the literature for a long time now -- but it is
> interesting. And of course I'm interested to hear your thoughts.
>
> Jason
> _______________________________________________
> WireGuard mailing list
> WireGuard@lists.zx2c4.com
> https://lists.zx2c4.com/mailman/listinfo/wireguard

Re: Roaming Mischief

[Aaron Jones]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 15/11/17 18:38, Markus Woschank wrote:
> I don't see the point in allowing other IPs to connect if an
> endpoint IP has been specified - more confusing then helpful IMO.

Endpoint is also used so that this machine can initiate sessions with
the peer. WireGuard is not a client-server architecture; by removing the
endpoint, you are preventing this peer from initiating. This is only
useful if you're using it *as* a server, in which case roaming is
usually what you want, but not always.

- -- 
Aaron Jones

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBCAAGBQJaDLm9AAoJEIrwc3SIqzASbN4P/iPQ3lMU48ehqDG7g3bOyxzV
qPGdipvtjslsykZaEPV5ZaL+olg1IvV3fG0eXuYny1pU55TMS+eJzQcc2Y1C6ovv
Qdm0C82GQahuy8GaPH5KTMMxTpw5M1rP/ffpW5tujzegLnoCY/zov3gs0ejsahU4
fEABmagk/d6k8ct2bJvFoKLvVr1PQel0gMv1D2LY1wdZBus6P6xbM7uVH346CJU7
Y5Gx/qo2e++PNtPJLNuXEWqaB/GvuCNsnYyZwec1J9h2ZHEhaaJOl+tQvFf/dHCk
BMj/OEopN8+7u00N8LTQdsUiG6Pb6klIZyKN3fuLNhTmIaox+Gwi7mgEzOOYmGgn
ft8YiwFumBbU+E9P0DCwScOC+6jPKPFsYUfXtWqAjKGPsJRfeBaRk//v9weqqt6p
jNpyfOCk5GxtG26U9gYqBldAMdl3OdlEYeN7ve1FXpoT4CbhuDfm7XzPFkMzirON
EjXyqLaqhRW7Jd1yAnp585FLuQ/tXw284hQFSimVSZ+WuWwnm21IL/7JfRMIPXUa
B3wbNIAmpFwBZKdO8mcgZjakt7pVheT7aVbIJpWOuWpFvJvCltI/jQvY1O9V+ZcU
sRAF6bK2m+4eupFe6Wex3s692sLnaX942gCWZvzZIx01ZRCITqYsdyabdwVxtb3X
z3FPheigDitxgt15oMKP
=61HN
-----END PGP SIGNATURE-----

Re: Roaming Mischief

[Stephen Major]

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

I am by no means an expert in crypto but lets just for the sake of paranoia
say that an advanced attacker was able to successfully pull off a MITM like
is possible with TLS and rumored OpenVPN.Personally, my approach to
security is having the mindset of everything can be compromised and basing
all decisions on that. So when I think of VPN's I think well if someone is
listening in, whether it be an ISP or a sophisticated encryption cracking
farm installed in the Westin building in Seattle.... How do I handle this
scenario? VPN Bonding, multiple tunnels 2 to a random number of tunnels
bonded. a successful MITM attack only would see garbled packets and the
complexity in cracking a random number of tunnels and correctly
re-assembling the packets would be seriously epic, at that point there are
easier ways and makes MITM pointless. So here comes the question, would
Bonding also solve your issue?


On Tue, Nov 14, 2017 at 1:59 AM, Jason A. Donenfeld <Jason@zx2c4.com> wrote:

> Hey folks,
>
> WireGuard has been built with the general rule that unauthenticated
> data doesn't influence state. There has always been one exception to
> this: roaming. The source IP address when roaming is always
> unauthenticated, and replies always happen to the source that prompted
> the reply. This means there is all sorts of mischief you can do. I
> thought it might be useful to write down a bit of this mischief.
>
> If an active man in the middle modifies a source address, he can have
> reply packets sent elsewhere, for a very limited amount of time, until
> either the encapsulated connection is dropped or the key expires and a
> handshake is needed. This kind of disruption, however, isn't that much
> different from what an active man in the middle already can do, by
> just dropping packets, or generating packets, etc.
>
> If an active man in the middle modifies a source address to be a
> server he controls, which then relays encrypted packets between the
> destination and the original source, then the sender and receiver will
> communicate through this server rather than directly. The
> communication is, of course, encrypted and authenticated, so there's
> no chance of tampering. It's mostly then just a waste of bandwidth
> resources of the attacker, to have to relay all of these unreadable
> and unmodifiable packets. However, this does make it possible to
> _extend the duration_ of a man in the middle attack, even if the man
> in the middle can't do anything with the packets. For example, an
> attacker at a coffee shop could change the endpoints to his relay
> server; when you go home, you'd ostensibly still be using that relay
> server.
>
> Is this a meaningful attack? Does anybody care? Can this be used for
> something interesting? When it comes to security of these things,
> "probably" is usually a better answer than "no". For example, even
> though the attacker with the MITM relay can't read or modify any
> packets, he may still be able to do timing correlation attacks, if he
> controls many points on the Internet. But was WireGuard ever supposed
> to protect against correlation issues? Correlation issues already
> exist without the relay anyway. And for what it's worth, Tor doesn't
> really deal with that either. So maybe this doesn't really matter. But
> perhaps there are worse things one can do with this primitive. And
> perhaps there's even further mischief.
>
> There is a mitigating factor in this that further makes it mostly not
> a practical concern: people who are looking up their endpoints using
> DNS are likely to want requery that DNS entry based on its TTL (or
> sooner in the case of dynamic IPs), in which case this aspect of
> extending the duration of an active MITM mostly goes away. However,
> telling people to use DNS to prevent against something something
> doesn't really seem like comprehensive advice. But it is a mitigating
> factor worth mentioning.
>
> So there are two attitudes toward this mischief. The first is to just
> say it doesn't matter. WireGuard's crypto is resilient to all types of
> men in the middle, and the fact of extending the duration of a man in
> the middle doesn't change the fact that WireGuard's crypto is still
> resilient. The other approach would be to add an optional exclamation
> mark to the end of an endpoint specification
> (Endpoint=my.server.whatever.zx2c4.com:51820!), that would prevent
> servers from roaming; the client would still roam in the eyes of the
> server, but the server, would no longer roam in the eyes of the
> client. In other words, an option -- gasp, a nob! -- to disable
> roaming on a per-by-peer one-sided basis. As you know, I don't really
> like nobs. And I'd hate to add this, and then for people to use it,
> and then loose some nice aspects of roaming, if it's not really even
> required.
>
> Regardless of which attitude we pick, I thought it might be a decent
> idea to write this down on the list. This is not really new -- roaming
> has been discussed in the literature for a long time now -- but it is
> interesting. And of course I'm interested to hear your thoughts.
>
> Jason
> _______________________________________________
> WireGuard mailing list
> WireGuard@lists.zx2c4.com
> https://lists.zx2c4.com/mailman/listinfo/wireguard
>

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

Re: Roaming Mischief

[Markus Woschank]

> WireGuard is not a client-server architecture
Did not claim otherwise.

> by removing the endpoint, you are preventing this peer from initiating.

Two peers forming a connection have the following properties/aspects:
* at least one has a fixed IP/DNS entry and this is set in the
configuration as endpoint in the other peer's configuration
* if one peer is in roaming mode it makes no sense to specify it's
endpoint in the other peers's configuration
* if both peers have fixed addresses it makes sense to specify each
other endpoint IPs in the configuration so the connection can be
established from both sides at any time

Please prove me wrong and supply an example where it makes sense to
have a roaming peer's endpoint set, where the roaming peer _really_
roams (changes it's IP) and where on reboot/reset/whatsoever the
originally set endpoint IP in the configuration magically makes any
sense again.

Markus

Re: Roaming Mischief

[Aaron Jones]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 17/11/17 17:23, Markus Woschank wrote:
> Please prove me wrong and supply an example where it makes sense
> to have a roaming peer's endpoint set, where the roaming peer
> _really_ roams (changes it's IP) and where on
> reboot/reset/whatsoever the originally set endpoint IP in the
> configuration magically makes any sense again.
> 
> Markus

"Originally" is the fallacy. wg-quick(8) can persist the current state
of the interface to the configuration file on shutdown, and restore it
on reboot. This is precisely what you would enable in an actual roaming
scenario.

Roaming means that the current endpoint (at shutdown time) would be
persisted, and if the reboot doesn't take very long, it is highly
likely that the (new) endpoint does still make sense, particularly
because UDP is used which means new sessions can usually resume as if
nothing happened, even through a NAT (though if you are also behind a
NAT, source port randomisation may trip you up if you don't have it
forwarded through the remote one, but that's beside the point).

- -- 
Aaron Jones

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBCAAGBQJaDx4MAAoJEIrwc3SIqzAS36sQAK6RCyxC1QZROnrGT40YxjUq
cu/2yY/jUvyhN+O7vaPslw74A+DQGCmFyjSYjr7bw6zzS1fV0nH9IKa+3gRUmPke
Q9qEIdw+z39bNbpqWewBFYkIEBXj00/M50+CzWEKncrnbbAG8oUKxtM3sgjuNTpd
uDBe2yzxeYORkUt/WhFz4GR9bggmyNR8AzHBZ8MedSuceLgQQ+65G7+LZ2jixna+
3jpO7BGdQxM4hv+oTgHJ2IlTjK+LjCJ0HnR2j+sFas9KvZFXbNEi46bS3/+HZ8w5
fncVTZyh8Ez+GC6lCX4UfdMyTKc3U72XdL42LaoW+biketJ9S5GyY1MeDMVhtBWR
h/rO4aiRGZMUkxdpS4geUQ1tIPnLzIDN42tORrszE80o8Fd5iF/mj2IyXVRLkvj2
iyaERFeyTgKw3jvjPFKXeRjgUgGfwFtqpdA+ycXtI8heO/8GxZIqlrVwgpRyD/iA
JuCAucCF1HQtLJp51QfvJ3eEH2JmZvGgDk2COLhKt0hH6Wr4p/nDRasA9NS2HJEe
xJKKvERPTNSsmA+0a/WLRGrSPDxJJVLy0nQW9c/9dtwUZspUGJ7DHfSutCuShy6r
OSkTITSuZk7fjtEfVF1X7nV8F6GIVq8Xu7gk4B7EkekW6Z/QD9x7+PniLhjTkha7
+uGtIXqsnKaQ6miBKduu
=PxWC
-----END PGP SIGNATURE-----

Re: Roaming Mischief

[Markus Woschank]

> Roaming means that the current endpoint (at shutdown time) would be
> persisted, and if the reboot doesn't take very long, it is highly
> likely that the (new) endpoint does still make sense, particularly
> because UDP is used which means new sessions can usually resume as if
> nothing happened, even through a NAT (though if you are also behind a
> NAT, source port randomisation may trip you up if you don't have it
> forwarded through the remote one, but that's beside the point).

Thanks for the example, did not yet have look at wg-quick.

But I argue that the concept of configuration and state should not be mixed.
Having the configuration the same and saving the current state, not
via showconf which should be used for configuration and not state as
the name implies, to a different location and restoring that state
(the current endpoint of the roaming peers) would be much cleaner and
not mix up a state-store-operation that stores a so called
configuration mixed with state that includes the private key.

Markus

Re: Roaming Mischief

[Markus Woschank]

After some more thoughts, in the scenario that you are describing,
where does persisting the state on the roaming peer help?
The roaming peer has the fixed peer's address in his configuration
(his IP does not change), and the remote side did not suspend.
Am I missing something here?

Markus

On 17 November 2017 at 18:36, Aaron Jones <aaronmdjones@gmail.com> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>
> On 17/11/17 17:23, Markus Woschank wrote:
>> Please prove me wrong and supply an example where it makes sense
>> to have a roaming peer's endpoint set, where the roaming peer
>> _really_ roams (changes it's IP) and where on
>> reboot/reset/whatsoever the originally set endpoint IP in the
>> configuration magically makes any sense again.
>>
>> Markus
>
> "Originally" is the fallacy. wg-quick(8) can persist the current state
> of the interface to the configuration file on shutdown, and restore it
> on reboot. This is precisely what you would enable in an actual roaming
> scenario.
>
> Roaming means that the current endpoint (at shutdown time) would be
> persisted, and if the reboot doesn't take very long, it is highly
> likely that the (new) endpoint does still make sense, particularly
> because UDP is used which means new sessions can usually resume as if
> nothing happened, even through a NAT (though if you are also behind a
> NAT, source port randomisation may trip you up if you don't have it
> forwarded through the remote one, but that's beside the point).
>
> - --
> Aaron Jones
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v2
> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
>
> iQIcBAEBCAAGBQJaDx4MAAoJEIrwc3SIqzAS36sQAK6RCyxC1QZROnrGT40YxjUq
> cu/2yY/jUvyhN+O7vaPslw74A+DQGCmFyjSYjr7bw6zzS1fV0nH9IKa+3gRUmPke
> Q9qEIdw+z39bNbpqWewBFYkIEBXj00/M50+CzWEKncrnbbAG8oUKxtM3sgjuNTpd
> uDBe2yzxeYORkUt/WhFz4GR9bggmyNR8AzHBZ8MedSuceLgQQ+65G7+LZ2jixna+
> 3jpO7BGdQxM4hv+oTgHJ2IlTjK+LjCJ0HnR2j+sFas9KvZFXbNEi46bS3/+HZ8w5
> fncVTZyh8Ez+GC6lCX4UfdMyTKc3U72XdL42LaoW+biketJ9S5GyY1MeDMVhtBWR
> h/rO4aiRGZMUkxdpS4geUQ1tIPnLzIDN42tORrszE80o8Fd5iF/mj2IyXVRLkvj2
> iyaERFeyTgKw3jvjPFKXeRjgUgGfwFtqpdA+ycXtI8heO/8GxZIqlrVwgpRyD/iA
> JuCAucCF1HQtLJp51QfvJ3eEH2JmZvGgDk2COLhKt0hH6Wr4p/nDRasA9NS2HJEe
> xJKKvERPTNSsmA+0a/WLRGrSPDxJJVLy0nQW9c/9dtwUZspUGJ7DHfSutCuShy6r
> OSkTITSuZk7fjtEfVF1X7nV8F6GIVq8Xu7gk4B7EkekW6Z/QD9x7+PniLhjTkha7
> +uGtIXqsnKaQ6miBKduu
> =PxWC
> -----END PGP SIGNATURE-----

Re: Roaming Mischief

[Aaron Jones]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 17/11/17 18:46, Markus Woschank wrote:
> Am I missing something here?

My example is most useful when both endpoints are roaming and either
endpoint needs to be able to initiate sessions. It's not a very
common scenario I'll give you that, but the current full roaming
support does enable it seamlessly (when you also enable keep-alives).

- -- 
Aaron Jones

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBCAAGBQJaD1SvAAoJEIrwc3SIqzASeGEP/jM0ibvZPNF3LDXnRTVlsSQW
CCG4cAFmTkemV3MHoOjTIyzmpXHVSEJVqoJCPPqjeMkQp7tENJyUuuHt4JMu0ZSb
RW/mUr6DHtl1QvIeT0u/zb88NX36NyR0KalUE6R3yA5LHlUjqx1OVVpq+sEQMT9p
iRUAusn2psJGQAyu+QW9faU+4HQdbv2d8khLdZqC/0g+YxG24/B+3xVJYtv4Ou9Z
1M8MRWggiSyEOx/LoifxVYRlW0d8mgJV75e921bV9NkGFLATQ6tFvbaJn9ZP98iP
uGBP0XIT2NUb6HuekxJaTud7wsoTNiX1g57UdQtrgH0rTIjBzqlRG3atBgxCJ682
dpN1vvuAaiQrXoieHTek/d9pMAa8xwhc2uNQ36pi3xHrEFveqMIhQv95Qh0cwcpL
PoqciZyVDNrFdDkDajdhKMOhcH6qs2uWP8vYPkxZRaN5INU1kMZbIuBsBefr/yzl
4FqKuYRBHrKHZmrltLo0ek5B0Ib9oACE1HnTy4SyvonVOQwy6bKEQLw5D3/P+u1T
cX5bk0PWyVDLrc9zegxsl68tNjw9QYyxSV3rjleTUZatXu4CYGA9EgtkAICQ8TU0
Y0Gy325nAoKP/jXZWxUlXx75uU86ul12HoqrNgVYBcAYokDTz8U9qReBUCCGhqAP
neeE8d6rJBN9ZRWsBQzz
=BDlR
-----END PGP SIGNATURE-----

Re: Roaming Mischief

[Markus Woschank]

> My example is most useful when both endpoints are roaming and either
> endpoint needs to be able to initiate sessions. It's not a very
> common scenario I'll give you that, but the current full roaming
> support does enable it seamlessly (when you also enable keep-alives).

Thank you for clarifying.

This really sound like an unusual situation, where you need to make
sure that while one peer is down the other doesn't move.
I wonder if this could not, should the need arise, be solved in another fashion.

>From experience I have another concern towards the current mechanism.
When configuring two peers pointing at each other and by mistake
setting one endpoint IP to a wrong value (typo in the IP) there is a
good chance this mistake may not be noticed for quiet some time, if
the correctly configured endpoint initiates the connection most of the
time. The user (me), believing to have correctly configured the link,
may be taken by surprise at a later point in time when the link is not
established, as he expects, when the wrongly configured side tries to
initiate it after say a reboot. This is more of a concern to me than
supporting to roaming  peers.

Also the thought of something like `wg showconf wg0 >
/etc/wireguard/wg0.conf` happening at shutdown frightens me a little.
Because if the command fails for whatever reason the configuration
will be truncated and after the reboot completes the link will be
non-functional (conf vs state).

Please don't interpret my comments the wrong way, I grew to love
wireguard. Just trying to state the kinks (IMO) I see, and this is one
of them.
I still vote for: if an endpoint is specified, don't allow the peer
from another source - no config syntax change needed ;).

Markus

Re: Roaming Mischief

[Markus Woschank]

>  where you need to make sure that while one peer is down the other doesn't move.

This is obviously wrong, should be:
"where you need to make sure that only one side changes it's network
while one is down."

On 17 November 2017 at 23:06, Markus Woschank <markus.woschank@gmail.com> wrote:
>> My example is most useful when both endpoints are roaming and either
>> endpoint needs to be able to initiate sessions. It's not a very
>> common scenario I'll give you that, but the current full roaming
>> support does enable it seamlessly (when you also enable keep-alives).
>
> Thank you for clarifying.
>
> This really sound like an unusual situation, where you need to make
> sure that while one peer is down the other doesn't move.
> I wonder if this could not, should the need arise, be solved in another fashion.
>
> From experience I have another concern towards the current mechanism.
> When configuring two peers pointing at each other and by mistake
> setting one endpoint IP to a wrong value (typo in the IP) there is a
> good chance this mistake may not be noticed for quiet some time, if
> the correctly configured endpoint initiates the connection most of the
> time. The user (me), believing to have correctly configured the link,
> may be taken by surprise at a later point in time when the link is not
> established, as he expects, when the wrongly configured side tries to
> initiate it after say a reboot. This is more of a concern to me than
> supporting to roaming  peers.
>
> Also the thought of something like `wg showconf wg0 >
> /etc/wireguard/wg0.conf` happening at shutdown frightens me a little.
> Because if the command fails for whatever reason the configuration
> will be truncated and after the reboot completes the link will be
> non-functional (conf vs state).
>
> Please don't interpret my comments the wrong way, I grew to love
> wireguard. Just trying to state the kinks (IMO) I see, and this is one
> of them.
> I still vote for: if an endpoint is specified, don't allow the peer
> from another source - no config syntax change needed ;).
>
> Markus

Re: Roaming Mischief

[Matthias Urlichs]

On 17.11.2017 19:46, Markus Woschank wrote:
> After some more thoughts, in the scenario that you are describing,
> where does persisting the state on the roaming peer help?
> The roaming peer has the fixed peer's address in his configuration
> (his IP does not change), and the remote side did not suspend.
> Am I missing something here?

Simple example: a mobile IP phone. Rebooting your telephony server
causes you to drop the connection to the client until _it_ next issues a
call. However, if you persist the phone's address, you don't lose
incoming service.

-- 
-- Matthias Urlichs

Re: Roaming Mischief

[Markus Woschank]

@matthias


On 15 November 2017 at 23:03, Aaron Jones <aaronmdjones@gmail.com> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>
> On 15/11/17 18:38, Markus Woschank wrote:
>> I don't see the point in allowing other IPs to connect if an
>> endpoint IP has been specified - more confusing then helpful IMO.
>
> Endpoint is also used so that this machine can initiate sessions with
> the peer. WireGuard is not a client-server architecture; by removing the
> endpoint, you are preventing this peer from initiating. This is only
> useful if you're using it *as* a server, in which case roaming is
> usually what you want, but not always.
>
> - --
> Aaron Jones
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v2
> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
>
> iQIcBAEBCAAGBQJaDLm9AAoJEIrwc3SIqzASbN4P/iPQ3lMU48ehqDG7g3bOyxzV
> qPGdipvtjslsykZaEPV5ZaL+olg1IvV3fG0eXuYny1pU55TMS+eJzQcc2Y1C6ovv
> Qdm0C82GQahuy8GaPH5KTMMxTpw5M1rP/ffpW5tujzegLnoCY/zov3gs0ejsahU4
> fEABmagk/d6k8ct2bJvFoKLvVr1PQel0gMv1D2LY1wdZBus6P6xbM7uVH346CJU7
> Y5Gx/qo2e++PNtPJLNuXEWqaB/GvuCNsnYyZwec1J9h2ZHEhaaJOl+tQvFf/dHCk
> BMj/OEopN8+7u00N8LTQdsUiG6Pb6klIZyKN3fuLNhTmIaox+Gwi7mgEzOOYmGgn
> ft8YiwFumBbU+E9P0DCwScOC+6jPKPFsYUfXtWqAjKGPsJRfeBaRk//v9weqqt6p
> jNpyfOCk5GxtG26U9gYqBldAMdl3OdlEYeN7ve1FXpoT4CbhuDfm7XzPFkMzirON
> EjXyqLaqhRW7Jd1yAnp585FLuQ/tXw284hQFSimVSZ+WuWwnm21IL/7JfRMIPXUa
> B3wbNIAmpFwBZKdO8mcgZjakt7pVheT7aVbIJpWOuWpFvJvCltI/jQvY1O9V+ZcU
> sRAF6bK2m+4eupFe6Wex3s692sLnaX942gCWZvzZIx01ZRCITqYsdyabdwVxtb3X
> z3FPheigDitxgt15oMKP
> =61HN
> -----END PGP SIGNATURE-----

Re: Roaming Mischief

[Markus Woschank]

Sorry for the previous message.

@matthias

> Simple example: a mobile IP phone. Rebooting your telephony server
> causes you to drop the connection to the client until _it_ next issues a
> call. However, if you persist the phone's address, you don't lose
> incoming service.

Thank you for the example.

While a reboot already impacts the service of the telephony system
this might be also tackled via the persistent keepalive, but I see
your point.

But then again the original configuration did not specify any endpoint
and suddenly, after reboot, it does.
I strongly believe the state (current endpoint of roaming peers) needs
to be separated from the configuration.
Take the dhcpd server for example, it does _not_ store leases in the
configuration and rewrites it on every shutdown, it stores the _state_
at a different location.

 Again ;) my proposal: if a peer's endpoint is specified this makes it
a non roaming peer, make it possible to store and restore, and/or set
current roaming peers endpoints, for special situations and don't
change the configuration syntax.

Markus