Need for HW-clock independent timestamps

[Matthias Urlichs]

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
> 100000, 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 send, which is why I advocated adding
a trillion or so to the state you write to disk (NOT to the state you
actually use!). The timestamp field is large enough for that to work.
> 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 

If that were the case you'd be vulnerable to such an attack right now,
as there is no check whatsoever that the timestamp you get corresponds
to any notion of current time, and nothing saves your peers' state at
reboot.

So let's look at what a replay attack can possibly accomplish after a
reboot – essentially, this requires Eve to store a bunch of Alice's
crypto setup packets and then feed them all to Bob after she detects
that he has rebooted. He'll respond to each of those and the attack ties
up one of his CPUs , but Eve doesn't know his private key thus can't do
anything with the replies. Meanwhile either Alice or Bob will send a new
setup packet to each other, which causes all further of Eve's packets to
be ignored.


-- 
-- Matthias Urlichs