Need for HW-clock independent timestamps

Toke Høiland-Jørgensen toke at
Wed May 16 11:38:23 CEST 2018

Axel Neumann <neumann at> writes:

> On 13.05.2018 14:37, Toke Høiland-Jørgensen wrote:> Matthias Urlichs
> <matthias at> 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 problem at all. So do you mean DOS in case your hit a wrap around of
> the counter? IMO this can be easily prevented.

No I meant DOS if you fail to save state properly. I.e., I send seqno
100000, lose my state, reboot, and re-initialise to seqno 100. I have
now essentially locked myself out of the network until my seqno goes
above 100000 again. Since I have no way of reliably detecting this
condition, there is no straight-forward manual recovery possible.

>> and the
>> possibility of replay attacks if you fail to save the last state when
>> you shut down comes to mind :)
> Where is that possibility? If you fail then you would send
> handshake_initiation messages with an already outdated timestamp
> field. Exactly what now happens by default with non-HWC equipped
> devices after each reboot.

You'd need to not only save your own seqno, but also the last seen seqno
from every peer. Otherwise you're vulnerable to a replay attack after
rebooting. And if you lose that state you are, well, vulnerable to a
replay attack after rebooting :)

>> (Not saying it's not possible to create a workable solution, just that
>> it's not trivial and requires careful thought to not break the security
>> assumptions of the protocol).
> I agree, but looking at the recent discussion (how to secure NTP as a
> work around for for non-HWC devices) some of the assumptions made by
> the current approach seem already quite questionable to me right now.
> Like super-simple WG and firewall setup. Instead of two-lines
> documentation you will likely need 2 pages plus some references for
> further reading to other tools (like NTP) and also inherit related
> problems. That does not sound like the WG philosophy to me.

Oh, I totally agree that it would be good if a solution could be found
to this. I'm just objecting to the assertion that "it's easy, just
replace the timestamp with an increasing seqno".


More information about the WireGuard mailing list