wireguard.lists.zx2c4.com archive mirror
 help / color / mirror / Atom feed
From: "Ivan Labáth" <labawi-wg@matrix-dream.net>
To: Axel Neumann <axel@notmail.org>
Cc: neumann@cgws.de,
	WireGuard mailing list <wireguard@lists.zx2c4.com>,
	Jann Horn <jannh@google.com>
Subject: Re: WG: Need for HW-clock independent timestamps
Date: Sat, 23 Feb 2019 12:35:00 +0000	[thread overview]
Message-ID: <20190223123500.GA3305@matrix-dream.net> (raw)
In-Reply-To: <48ac1469-a8f3-7841-95c5-4d0610078d41@notmail.org>

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
_______________________________________________
WireGuard mailing list
WireGuard@lists.zx2c4.com
https://lists.zx2c4.com/mailman/listinfo/wireguard

  reply	other threads:[~2019-02-23 12:35 UTC|newest]

Thread overview: 39+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-05-11 22:07 WG: Need for HW-clock independent timestamps Axel Neumann
2018-05-11 22:45 ` Kalin KOZHUHAROV
2018-05-12  0:05   ` Glen Bojsza
2018-05-12 19:29   ` Axel Neumann
2018-05-12 19:41     ` Aaron Jones
2018-05-15 20:21       ` Devan Carpenter
2018-05-15 20:49         ` Kalin KOZHUHAROV
2018-05-16  7:10           ` Matthias Urlichs
2018-05-16 19:32           ` Axel Neumann
2018-05-16 20:32             ` Steve Gilberd
2018-05-17  3:40               ` Paul
2018-05-17  5:03                 ` Roman Mamedov
2018-05-17  5:53                   ` Matthias Urlichs
2018-05-17  7:07                     ` Axel Neumann
2018-05-17  8:28                       ` Matthias Urlichs
2018-05-16 20:35             ` Kalin KOZHUHAROV
2018-05-12 22:10     ` Toke Høiland-Jørgensen
2018-05-12 23:05     ` Reuben Martin
2018-05-13  6:11     ` Matthias Urlichs
2018-05-13 12:37       ` Toke Høiland-Jørgensen
2018-05-16  7:01         ` Axel Neumann
2018-05-16  9:38           ` Toke Høiland-Jørgensen
2018-05-16 11:08             ` Matthias Urlichs
2018-05-16 11:12             ` Axel Neumann
2018-05-13 14:21   ` Wang Jian
2018-05-21 10:07 ` WG: " Axel Neumann
2018-05-21 11:22   ` Reto Brunner
2018-05-21 11:52     ` Axel Neumann
2018-05-21 12:31       ` Axel Neumann
2018-05-21 12:35       ` Reto Brunner
2018-05-21 13:53         ` Matthias Urlichs
2018-05-21 14:56           ` Bruno Wolff III
2018-05-21 15:34             ` Matthias Urlichs
2018-05-22 20:25               ` Ivan Labáth
2018-05-23  2:51                 ` Matthias Urlichs
2019-02-04 14:56                 ` Jason A. Donenfeld
2019-02-23  4:00                   ` Axel Neumann
2019-02-23 12:35                     ` Ivan Labáth [this message]
     [not found] <1522499692.6109802.1526903933505.ref@mail.yahoo.com>
2018-05-21 11:58 ` reiner otto

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20190223123500.GA3305@matrix-dream.net \
    --to=labawi-wg@matrix-dream.net \
    --cc=axel@notmail.org \
    --cc=jannh@google.com \
    --cc=neumann@cgws.de \
    --cc=wireguard@lists.zx2c4.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).