WG: Need for HW-clock independent timestamps

Ivan Labáth labawi-wg at matrix-dream.net
Sat Feb 23 13:35:00 CET 2019


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 you mean update counter to flash for each peer for each handshake?
> That may again result in a lot (10..100++ ???) of write cycles per day, no?
> ..
> Incrementing by e.g. 16000 (corresponding 16ms in real time) would allow
> 16k handshakes before the stored value had to be updated again.

You've got the right idea. Counter is a 12-byte (96-bit) number,
which is quite big. Increase it enough and you won't go past
your next initialization number in a sufficiently long time,
or more precisely number of handshakes.

You could periodically increase and save the counter each hour or day,
100 years or whatever, or just increase it enough so you don't need
periodic updates. Just remember to store your next initialization
number before using the current one so you won't end up using expired
numbers.

> Wireguard could even delay first handshake by 16ms to 100% ensure that
> SQNs have never be used before.
> 
> Then, by setting system base time to stored counter value on wireguard
> init, and
> > choose a per-peer base
> > time for the first handshake, and then simply increment that on each
> > handshake
> would be sufficient for our use case.
> 
> Just important that the peer base time used for all peers is always
> given by the system base time when wireguard initialized (and NOT the
> current time when the handshake is made).
> Otherwise, an unexpected reboot of the system after >16ms may again lead
> to re-used handshake SQNs.

I guess you could rig something up via system time with current
wireguard API, but it's not nice to devices that do things other
than wireguard tunneling and it would have lots of corner cases.
Adding a wireguard set-counter API should be clearer and much
simpler to use.

Regards,
Ivan


More information about the WireGuard mailing list