Re: WG: Need for HW-clock independent timestamps

Hi, On Sat, Feb 23, 2019 at 05:00:57AM +0100, Axel Neumann wrote: > .. > Regarding > > Initiation of a wireguard > > tunnel for those devices would be: read last counter to variable X, > > increment last counter, store incremented counter to flash, tell > > wireguard to use X as basetime. > > Do

Re: WG: Need for HW-clock independent timestamps

I really appreciate the resumption. Whatever mechanisms wireguard introduces to handle non-RTC devices with limited flash-write cycles (which far most of the openWrt community uses) would significantly ease the configuration of every-even-ntp-traffic-secured networks. Regarding > Initiation of

Re: WG: Need for HW-clock independent timestamps

An update on this old thread: The only requirement for the "timestamp" field is that it's monotonically increasing. I've been mulling over some improvements to the current situation of just sticking a nanosecond resolution timestamp in there raw, after discussing with Jann a few months ago and

Re: WG: Need for HW-clock independent timestamps

On 22.05.2018 22:25, Ivan Labáth wrote: > How about allowing counter wrapping, if it has been at least > 2 * REKEY_TIMEOUT from last handshake? Perhaps reusing the cookie > protocol for a 2-RTT handshake? > > Losing access to a device, because its clock has gone wonky is not pleasant. If that

Re: WG: Need for HW-clock independent timestamps

On Mon, May 21, 2018 at 05:34:42PM +0200, Matthias Urlichs wrote: > I might also wonder why you'd peer with somebody whom you don't trust > not to collect and/or abuse the information that you just rebooted … You might wish to connect with someone because he provides services. Active monitoring

Re: WG: Need for HW-clock independent timestamps

On 21.05.2018 16:56, Bruno Wolff III wrote: > If you want to go that route, you should just treat it as a two part > number. One for a boot count, that would get incremented every boot > and saved and a low order part that is reset to 0 at every boot. That'd work for me, though I prefer to use an

Re: WG: Need for HW-clock independent timestamps

On Mon, May 21, 2018 at 15:53:10 +0200, Matthias Urlichs wrote: On 21.05.2018 14:35, Reto Brunner wrote: If you just want a single write cycle, then you loose the ability to graceful handle unexpected shutdowns. Why? Even if you increment the counter by 10'000 when

Re: WG: Need for HW-clock independent timestamps

On 21.05.2018 14:35, Reto Brunner wrote: > If you just want a single write cycle, then you loose the ability to graceful > handle unexpected shutdowns. Why? > Even if you increment the counter by 10'000 when restoring it, who's to > say the device hasn't been running for several weeks before the >

Re: WG: Need for HW-clock independent timestamps

On Mon, May 21, 2018 at 01:52:34PM +0200, Axel Neumann wrote: > yes, can be an option, but would only work in "normal" soft-shut-down > cases, not in case of a hard reset or power cycle. A not-so-uncommon > scenario for embedded home-network devices and community-network > deployments. Especially

Re: WG: Need for HW-clock independent timestamps

On 21.05.2018 13:52, Axel Neumann wrote: > On 21.05.2018 13:22, Reto Brunner wrote: >> On Mon, May 21, 2018 at 12:07:38PM +0200, Axel Neumann wrote: >>> entirely superfluous. As discussed earlier [3] it can be achieved with >>> essentially one file-system write operation each boot. >> >> You might

Re: WG: Need for HW-clock independent timestamps

am Mo, 21.5.2018: Betreff: Re: WG: Need for HW-clock independent timestamps An: wireguard@lists.zx2c4.com Datum: Montag, 21. Mai, 2018 14:52 Uhr On 21.05.2018 13:22, Reto Brunner wrote: > On Mon, May 21, 2018 at 12:07:38PM +0200, Axel Neumann wrote: >> entirely superfluous. As disc

Re: WG: Need for HW-clock independent timestamps

On 21.05.2018 13:22, Reto Brunner wrote: > On Mon, May 21, 2018 at 12:07:38PM +0200, Axel Neumann wrote: >> entirely superfluous. As discussed earlier [3] it can be achieved with >> essentially one file-system write operation each boot. > > You might as well achieve the same with the timestamp. >

Re: WG: Need for HW-clock independent timestamps

On Mon, May 21, 2018 at 12:07:38PM +0200, Axel Neumann wrote: > entirely superfluous. As discussed earlier [3] it can be achieved with > essentially one file-system write operation each boot. You might as well achieve the same with the timestamp. Just add a pre-shutdown hook, which touches a

Re: WG: Need for HW-clock independent timestamps

Hello, With regards to the subject, ...to discuss the demand and identify solutions for a "HW-clock INDEPENDENT WG solution", I've seen essentially three different suggestions so fare: a) Buy and connect a HW clock. IMO: Often difficult considering available HW, budget, and skills. b) Rely on

Re: Need for HW-clock independent timestamps

On 17.05.2018 09:07, Axel Neumann wrote: >> Wireguard's connection setup is a whole lot simpler than most other > But only if you ignore the implications coming with NTP transmissions. The implication is to require a monotonically increasing 96-bit value. Using NTP is one way to do that. There

Re: Need for HW-clock independent timestamps

Am 17. Mai 2018 07:53:17 MESZ schrieb Matthias Urlichs : >On 17.05.2018 07:03, Roman Mamedov wrote: >> Personally I am puzzled this is even an issue in WG. Not a single >other VPN >> protocol mandates every node to keep a monotonically increasing >counter, >> including even

Re: Need for HW-clock independent timestamps

On 17.05.2018 07:03, Roman Mamedov wrote: > Personally I am puzzled this is even an issue in WG. Not a single other VPN > protocol mandates every node to keep a monotonically increasing counter, > including even over reboots. Wireguard's connection setup is a whole lot simpler than most other

Re: Need for HW-clock independent timestamps

On Thu, 17 May 2018 12:40:55 +0900 Paul wrote: > For me it looks like a problem solvable in software (as done for the > BMX routing protocol). Why even bother to get hardware involved? Personally I am puzzled this is even an issue in WG. Not a single other VPN protocol

Re: Need for HW-clock independent timestamps

Hi all, If I'm not mistaken replay attacks are checked here [1] and only compare integers with no reference to local time of the receiving node. The sending nodes timestamp is generated via tai64n_now [2][3]. From my understanding this function could simply be changed to a auto increased

Re: Need for HW-clock independent timestamps

Hello Axel, I may have not been clear in my last response, it was to be taken in the context of the whole thread... On Wed, May 16, 2018 at 9:32 PM, Axel Neumann wrote: > > > Am 15. Mai 2018 22:49:15 MESZ schrieb Kalin KOZHUHAROV : >>On Tue, May 15, 2018 at

Re: Need for HW-clock independent timestamps

> $20 would increase the HW cost of many typical community-networks (CN) deployments significantly. This seems unlikely. In most cases, $20 is notably less than the cost of a single node. > Plus requiering more knowledge, maintenence, and power supply for sometimes solar-powered setups... no

Re: Need for HW-clock independent timestamps

Am 16. Mai 2018 11:38:23 MESZ schrieb "Toke Høiland-Jørgensen" : >Axel Neumann writes: > >> On 13.05.2018 14:37, Toke Høiland-Jørgensen wrote:> Matthias Urlichs >> writes: >>> Can anybody think of problems with this solution? >>> >>>

Re: Need for HW-clock independent timestamps

On 16.05.2018 11:38, Toke Høiland-Jørgensen wrote: > No I meant DOS if you fail to save state properly. I.e., I send seqno > 10, lose my state, reboot, and re-initialise to seqno 100. So don't do that then. Your saved state needs to be substantially higher than any seqno you could possibly

Re: Need for HW-clock independent timestamps

Axel Neumann writes: > On 13.05.2018 14:37, Toke Høiland-Jørgensen wrote:> Matthias Urlichs > writes: >> >>> Can anybody think of problems with this solution? >> >> Well, the possibility of DOS if you set the counter too high, > > Correct me please, but

Re: Need for HW-clock independent timestamps

On 15.05.2018 22:49, Kalin KOZHUHAROV wrote: > [1] Can anyone point me to the piece in code that shows that > precision? In other words, how far apart can 2 peers' clocks be and > still connect. Infinite. Seriously. The timestamp field is essentially a counter. It just counts up in rather large

Need for HW-clock independent timestamps

On 13.05.2018 14:37, Toke Høiland-Jørgensen wrote:> Matthias Urlichs writes: > >> Can anybody think of problems with this solution? > > Well, the possibility of DOS if you set the counter too high, Correct me please, but skipping even many counter values should not be a

Re: Need for HW-clock independent timestamps

On Tue, May 15, 2018 at 10:21 PM, Devan Carpenter wrote: > Aaron Jones transcribed 3.1K bytes: >> On 12/05/18 19:29, Axel Neumann wrote: >> > You want WG to secure your network. So the suggestion can not be to open >> > your network for a pretty insecure deamon in order to get WG

Re: Need for HW-clock independent timestamps

Aaron Jones transcribed 3.1K bytes: > On 12/05/18 19:29, Axel Neumann wrote: > > You want WG to secure your network. So the suggestion can not be to open > > your network for a pretty insecure deamon in order to get WG working. > > This would essentially allow attackers to a fake the ntp server

Re: Need for HW-clock independent timestamps

Matthias Urlichs writes: > Can anybody think of problems with this solution? Well, the possibility of DOS if you set the counter too high, and the possibility of replay attacks if you fail to save the last state when you shut down comes to mind :) (Not saying it's not

Re: Need for HW-clock independent timestamps

reiner otto writes: > Having implemented this solution already, I consider it some type of > hack, as the standard time sync unfortunately happens very late in the > start of the services, after rc.local called. And the sync might take > quite some time. > > Which means,

Re: Need for HW-clock independent timestamps

On 12.05.2018 21:29, Axel Neumann wrote: > Thanks a lot for your replies. But as you can see from my comments below > this all does not look like a valid option for many embedded use cases. > BTW, my background are community mesh networks which are maintained by > all kind of different individuals

Re: Need for HW-clock independent timestamps

Having implemented this solution already, I consider it some type of hack, as the standard time sync unfortunately happens very late in the start of the services, after rc.local called. And the sync might take quite some time. Which means, I had to "hack" the time sync immediately after WAN

Re: Need for HW-clock independent timestamps

On Saturday, May 12, 2018 2:29:24 PM CDT Axel Neumann wrote: > Thanks a lot for your replies. But as you can see from my comments below > this all does not look like a valid option for many embedded use cases. Perhaps it might make sense to add functionality for WG to request a timestamp from

Re: Need for HW-clock independent timestamps

Axel Neumann writes: > Thanks a lot for your replies. But as you can see from my comments below > this all does not look like a valid option for many embedded use cases. > BTW, my background are community mesh networks which are maintained by > all kind of different individuals

Re: Need for HW-clock independent timestamps

On 12/05/18 19:29, Axel Neumann wrote: > You want WG to secure your network. So the suggestion can not be to open > your network for a pretty insecure deamon in order to get WG working. > This would essentially allow attackers to a fake the ntp server and then > block WG forever. Someone in a

Re: Need for HW-clock independent timestamps

Thanks a lot for your replies. But as you can see from my comments below this all does not look like a valid option for many embedded use cases. BTW, my background are community mesh networks which are maintained by all kind of different individuals using a zoo of different device types. I would

AW: WG: Need for HW-clock independent timestamps

I ran into this problem, too, and fixed it by re-adjusting the time before WG is activated. This needs some fiddling around with standard NTP startup in openwrt, though, so it is some type of hack which I do not really like. Unfortunately, not so many openwrt-devices around having RTC. WG to

Re: Need for HW-clock independent timestamps

Why not add a configurable timer feature to wireguard where you can set the amount of time after power up before the wireguard vpn comes up? This would solve the problem universally and may be the simplest / quickest solution. Disclaimer: I don't have a developer's background only a user's one

Re: Need for HW-clock independent timestamps

On Sat, May 12, 2018 at 12:07 AM, Axel Neumann wrote: > We have the following chicken-egg problem: > We are using WG on openwrt devices which do not have a hardware clock so > that time is resetted after each reboot. > Because internet access shall be routed via WG tunnels the