Re: RFC: wg syncpeers wg0 wireguard.conf

["Ivan Labáth" <wg@labo.rs>]

Hi,

walk_remove_by_peer does seem inefficient. Judging by the stack, I guess
it walks the tree looking for addresses from a specific peer. That would
be roughly O(A log A) operations for A addresses, in total O(N A log A)
if removing all of them.

A simple fix would be to know what you want to remove. Then you can find
it fast in the search tree. Does showing peer configuration also scan
the entire tree? If you need to store a list of addresses associated
with a peer (seems like a good idea), memory needed should be no more
and probably less than the tree itself.

I can explain an algorithm, or tell you how to fix it, but I'm not
saying I will code it (yet).


WRT setconf/addconf/syncconf

From a user point of view, I do not see a reason to disconnect peers
which are not modified when changing confguration. It seems excessive
and not quite useful.

After reading wg man page [1], I do have questions about what these
commands do.

1) When setconf-ing an interface without optional parameters, and the
interface was configured with a non-default values, do they remain or
are they reset to defaults?
I guess either would be fine as long as it is consistent. Both interface
and peer configuration.

a) Listen port - if not specified, I would leave as is. It has already
been chosen (perhaps) randomly.

2) If a peer is connected and the configured endpoint changes, does the
endpoint change? Does the peer get disconnected?
If a peer has roamed, you edit another peer and run setconf, it doesn't
seems nice to disconnect the roaming peers. OTOH, if you want change the
address (e.g. to a another valid one), it would be nice if the peers
moved to the new addresses in a reasonable time.

3) Regarding addconf - after reading the man page, I'm not sure what the
intent is, or what does it do.
a) It says only one interface section can be in a file, is changing the
interface configuration permitted? If not, it should probably be called
addpeers.
b) Are multiple definitions of the same peer permitted? If so, what is
the result - can I split the definitions, or are the previous ones
discarded? What about ips, are they summed or overriden?

Regards,
Ivan

[1] https://git.zx2c4.com/WireGuard/about/src/tools/man/wg.8


On 14. 6. 2019 20:09, Jason A. Donenfeld wrote:
> Hey Lonnie,
> 
> If your changes are user-facing, it's probably not a good idea to
> create confusion by introducing distro-specific subcommands.
> 
> I'm leaning toward Steven's suggestion of nixing addconf and making
> setconf behave like syncconf. But two hurdles remain:
> 
> - walk_remove_by_peer is very inefficient. That *must* be to be
> improved for this to be feasible. There's some interesting algorithms
> programming in allowedips.c to be tackled for that. Maybe
> node->peer_list can be used. (CC'ing Ivan in case he wants to put his
> mind to work on that.)
> - A decision needs to be made on consistency: do we want to read back
> the end result and compare it? Or will that kind of looping logic lead
> to other types of DoS or latency spikes?
> 
> Jason
> 
_______________________________________________
WireGuard mailing list
WireGuard@lists.zx2c4.com
https://lists.zx2c4.com/mailman/listinfo/wireguard