* Re: WG: Need for HW-clock independent timestamps [not found] <1522499692.6109802.1526903933505.ref@mail.yahoo.com> @ 2018-05-21 11:58 ` reiner otto 0 siblings, 0 replies; 15+ messages in thread From: reiner otto @ 2018-05-21 11:58 UTC (permalink / raw) To: wireguard, neumann +1;=20 Not just to consider the "very standard case", which why quality of softwar= e nowadays goes down. Although you are correct here, that power cycle is almost normal usage proc= edure. -------------------------------------------- Axel Neumann <neumann@cgws.de> schrieb 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 =20 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. >=20 > You might as well achieve the same with the timestamp. > Just add a pre-shutdown hook, which touches a file. =20 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 when considering the first choice of a=C2=A0 normal user (desperately trying to fix its internet-via-WG tunnel connection): Power cycle the device. =20 /axel =20 > Restore the system clock to this upon boot (which may very well be off > but who cares). >=20 > After the wg tunnel is back up, sync with any NTP server you trust and you > are back up and running. >=20 > What is the advantage of doing it with a counter? > I fail to see the benefit. > _______________________________________________ > WireGuard mailing list > WireGuard@lists.zx2c4.com > https://lists.zx2c4.com/mailman/listinfo/wireguard > =20 =20 _______________________________________________ WireGuard mailing list WireGuard@lists.zx2c4.com https://lists.zx2c4.com/mailman/listinfo/wireguard =20 ^ permalink raw reply [flat|nested] 15+ messages in thread
* WG: Need for HW-clock independent timestamps @ 2018-05-11 22:07 Axel Neumann 2018-05-21 10:07 ` Axel Neumann 0 siblings, 1 reply; 15+ messages in thread From: Axel Neumann @ 2018-05-11 22:07 UTC (permalink / raw) To: wireguard Hello, 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 internet and network-time services (NTP) is not available unless WG works properly. But, guess, to reconnect, WG needs a greater time than before it rebooted :-( I heard that a suggested solution is to periodically save the current time to filesystem and then fix it during boot based on the last saved one. But all embedded devices use flash memory with a limited amount (about 10^5) of write cycles before they become unstable which would destroy the flash within weeks. Any ideas how to circumvent this problem? As a remark, BMX7 is doing it the following way: Instead of using timestamps to protect against replay attacks the approach is to use just an always increasing integer (sqn), for each new signature (from the WG white paper I understand that that should be possible). Sqn Jumps, as long as they are just increasing the sqn, are fine. Now, to save the sqn over reboot it is read from filesystem as current_sqn during boot and immediately saved as save_sqn=current_sqn+100000 and then only be re-saved (again as new current_sqn+100000) when the last used current_sqn equals the last saved save_sqn. This way, jumps of at most 100000 occur only in case of node reboots. But as such jumps are harmless anyway its ok. And with a 48-bit-timestamp field it would still survive 28^9 reboots till the timestamp reaches end-of-life. Of course the 100000 is debatable as I do not know how much DH-based connection attempts may happen over a day or week. But given that no more than one sqn save occurs in average per day the flash lifetime could already be increased significantly. Best regards /Axel ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: WG: Need for HW-clock independent timestamps 2018-05-11 22:07 Axel Neumann @ 2018-05-21 10:07 ` Axel Neumann 2018-05-21 11:22 ` Reto Brunner 0 siblings, 1 reply; 15+ messages in thread From: Axel Neumann @ 2018-05-21 10:07 UTC (permalink / raw) To: wireguard 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 the (HW) clock of somebody else, considering network time protocols (e.g. NTP, RFC867, RFC868,...) and related (security) implications (such as new dependencies on remote services, IP or DNS spoofing, firewall settings, boot-service order, ...). Some experience [1] suggest to go for a). IMO: A concrete best practice would be good here but would likely overshoot the complexity and other-systems-dependencies of WG by magnitudes. c) Modify WG to use (time-independent) counter-based values to prevent replay-attacks. Paul [2] gave a pretty nice overview of the yet identified advantages and implications, suggesting that it requires only few and simple code changes, introduces no security drawbacks, could be fully compatible with existing protocol and implementations, and makes HWC or NTP entirely superfluous. As discussed earlier [3] it can be achieved with essentially one file-system write operation each boot. There have been many good comments for a) and b). Still, I'd be happy to elaborate the case of c), or a maybe a fourth idea, a bit further... What technical concerns do you see with c) or what suggestions would you make to somebody working out a patch? [1] https://lists.zx2c4.com/pipermail/wireguard/2018-May/002832.html [2] https://lists.zx2c4.com/pipermail/wireguard/2018-May/002875.html [3] https://lists.zx2c4.com/pipermail/wireguard/2018-May/002865.html /axel ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: WG: Need for HW-clock independent timestamps 2018-05-21 10:07 ` Axel Neumann @ 2018-05-21 11:22 ` Reto Brunner 2018-05-21 11:52 ` Axel Neumann 0 siblings, 1 reply; 15+ messages in thread From: Reto Brunner @ 2018-05-21 11:22 UTC (permalink / raw) To: wireguard 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 file. Restore the system clock to this upon boot (which may very well be off but who cares). After the wg tunnel is back up, sync with any NTP server you trust and you are back up and running. What is the advantage of doing it with a counter? I fail to see the benefit. ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: WG: Need for HW-clock independent timestamps 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 0 siblings, 2 replies; 15+ messages in thread From: Axel Neumann @ 2018-05-21 11:52 UTC (permalink / raw) To: wireguard 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. > Just add a pre-shutdown hook, which touches a file. 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 when considering the first choice of a normal user (desperately trying to fix its internet-via-WG tunnel connection): Power cycle the device. /axel > Restore the system clock to this upon boot (which may very well be off > but who cares). > > After the wg tunnel is back up, sync with any NTP server you trust and you > are back up and running. > > What is the advantage of doing it with a counter? > I fail to see the benefit. > _______________________________________________ > WireGuard mailing list > WireGuard@lists.zx2c4.com > https://lists.zx2c4.com/mailman/listinfo/wireguard > ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: WG: Need for HW-clock independent timestamps 2018-05-21 11:52 ` Axel Neumann @ 2018-05-21 12:31 ` Axel Neumann 2018-05-21 12:35 ` Reto Brunner 1 sibling, 0 replies; 15+ messages in thread From: Axel Neumann @ 2018-05-21 12:31 UTC (permalink / raw) To: wireguard 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 as well achieve the same with the timestamp. >> Just add a pre-shutdown hook, which touches a file. > > 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 when considering the first choice of a normal > user (desperately trying to fix its internet-via-WG tunnel connection): > Power cycle the device. > > /axel > >> Restore the system clock to this upon boot (which may very well be off >> but who cares). >> >> After the wg tunnel is back up, sync with any NTP server you trust and you >> are back up and running. >> >> What is the advantage of doing it with a counter? >> I fail to see the benefit. Sorry, forgot to reply here: The advantage is that you could save a counter value in advance that is to-be-used after the NEXT reboot. It can be saved during boot or before WG starts (not during shut-down), so you are safe against unexpected hard resets. The (WG) boot procedure would be: 1) Read saved_counter from disk (take zero first time) and memorize it as current_counter. 2) Write saved_counter + NextBootOffset to disk. 3) Use and incremented current_counter by +1 with each new WG handshake. Considering NextBootOffset = (2^16 * 10^9): With 1 WG handshake per ms the NextBootOffset would be exhausted every ~1800 years. With 1 system reboot every ms the total 96bits counter range would overlap in ~9000 years. /axel >> _______________________________________________ >> WireGuard mailing list >> WireGuard@lists.zx2c4.com >> https://lists.zx2c4.com/mailman/listinfo/wireguard >> > > _______________________________________________ > WireGuard mailing list > WireGuard@lists.zx2c4.com > https://lists.zx2c4.com/mailman/listinfo/wireguard > ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: WG: Need for HW-clock independent timestamps 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 1 sibling, 1 reply; 15+ messages in thread From: Reto Brunner @ 2018-05-21 12:35 UTC (permalink / raw) To: wireguard 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 when considering the first choice of a normal > user (desperately trying to fix its internet-via-WG tunnel connection): > Power cycle the device. But the same issue would be occurring if you used a counter instead. At one point you *have* to write a checkpoint somewhere. If you just want a single write cycle, then you loose the ability to graceful handle unexpected shutdowns. 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 unexpected power cycle happened? Even the +10'000 counter would then already be way smaller than the *actual* counter from the servers perspective. ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: WG: Need for HW-clock independent timestamps 2018-05-21 12:35 ` Reto Brunner @ 2018-05-21 13:53 ` Matthias Urlichs 2018-05-21 14:56 ` Bruno Wolff III 0 siblings, 1 reply; 15+ messages in thread From: Matthias Urlichs @ 2018-05-21 13:53 UTC (permalink / raw) To: wireguard 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 > unexpected power cycle happened? So increment the counter by a trillion instead. It's large enough and you're not going to send a trillion packets before the next reboot. -- -- Matthias Urlichs ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: WG: Need for HW-clock independent timestamps 2018-05-21 13:53 ` Matthias Urlichs @ 2018-05-21 14:56 ` Bruno Wolff III 2018-05-21 15:34 ` Matthias Urlichs 0 siblings, 1 reply; 15+ messages in thread From: Bruno Wolff III @ 2018-05-21 14:56 UTC (permalink / raw) To: Matthias Urlichs; +Cc: wireguard On Mon, May 21, 2018 at 15:53:10 +0200, Matthias Urlichs <matthias@urlichs.de> 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 restoring it, who's to >> say the device hasn't been running for several weeks before the >> unexpected power cycle happened? > >So increment the counter by a trillion instead. It's large enough and >you're not going to send a trillion packets before the next reboot. 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. Note that this scheme leaks information to the peer. ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: WG: Need for HW-clock independent timestamps 2018-05-21 14:56 ` Bruno Wolff III @ 2018-05-21 15:34 ` Matthias Urlichs 2018-05-22 20:25 ` Ivan Labáth 0 siblings, 1 reply; 15+ messages in thread From: Matthias Urlichs @ 2018-05-21 15:34 UTC (permalink / raw) To: Bruno Wolff III; +Cc: wireguard 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 opaque number / base64string-of-12-bytes that doesn't look like it means something. > Note that this scheme leaks information to the peer. Rebooting is likely to leak that information anyway, because the peer sees a period with no packets from you (also, it can't ping you) followed by a possibly-premature re-key (depending on how long your boot process takes). 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 … -- -- Matthias Urlichs ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: WG: Need for HW-clock independent timestamps 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 0 siblings, 2 replies; 15+ messages in thread From: Ivan Labáth @ 2018-05-22 20:25 UTC (permalink / raw) To: Matthias Urlichs; +Cc: wireguard 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 can provide similar information, but there is no need to send your running reboot count and time since last reboot in every handshake message. It seems wireguard requires external/persistent state (time is state) to prevent replays, because of its 1-RTT key exchange. A 2-RTT design wouldn't require such dependencies. 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. -- Ivan Labáth ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: WG: Need for HW-clock independent timestamps 2018-05-22 20:25 ` Ivan Labáth @ 2018-05-23 2:51 ` Matthias Urlichs 2019-02-04 14:56 ` Jason A. Donenfeld 1 sibling, 0 replies; 15+ messages in thread From: Matthias Urlichs @ 2018-05-23 2:51 UTC (permalink / raw) To: Ivan Labáth; +Cc: wireguard 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 happens, you can remove and re-add the peer. -- -- Matthias Urlichs ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: WG: Need for HW-clock independent timestamps 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 1 sibling, 1 reply; 15+ messages in thread From: Jason A. Donenfeld @ 2019-02-04 14:56 UTC (permalink / raw) To: WireGuard mailing list; +Cc: Jann Horn, neumann 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 then with Ivan the last two days at FOSDEM. First, it's quite trivial to whiten that by only allowing a resolution of 16 or so ms, which might mitigate various unrelated sidechannels that think they have an oracle in WireGuard. Second, both Ivan and Jann have suggested that rather than always adding a fresh timestamp, we should instead choose a per-peer base time for the first handshake, and then simply increment that on each handshake (making sure that the stamp never exceeds the current time). While we're holding off on new features and nobs and whatnot until post kernel merge, this would then enable us to potentially add a specialized option for manually setting the base time. It would by default remain the time, as it is now, since that's almost always a reasonable decision. But for devices without an RTC and whose flash chips prohibit writing out a new timestamp once a second or minute or whatever, this would allow, instead, to just write out a counter once per boot, which is much more reasonable. 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. I think this dance should handle a lot of the issues discussed in this thread. Third, Ivan suggested that we actually add a blinding factor to the timestamps, simply by adding HASH(label||private||public) or similar to the stamp itself. I'll need to think carefully about the crypto before committing to anything, but this kind of transformation does not seem infeasible and might lessen a potential infoleak. A good idea, in other words. _______________________________________________ WireGuard mailing list WireGuard@lists.zx2c4.com https://lists.zx2c4.com/mailman/listinfo/wireguard ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: WG: Need for HW-clock independent timestamps 2019-02-04 14:56 ` Jason A. Donenfeld @ 2019-02-23 4:00 ` Axel Neumann 2019-02-23 12:35 ` Ivan Labáth 0 siblings, 1 reply; 15+ messages in thread From: Axel Neumann @ 2019-02-23 4:00 UTC (permalink / raw) To: Jason A. Donenfeld, WireGuard mailing list; +Cc: neumann, Jann Horn 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 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? Otherwise, if done only once per overall wireguard initialization then incrementing last counter by one would not be enough to ensure that already used SQNs are not used again after a reboot. Incrementing by e.g. 16000 (corresponding 16ms in real time) would allow 16k handshakes before the stored value had to be updated again. 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. On 04.02.19 15:56, Jason A. Donenfeld wrote: > 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 then with Ivan the last two days at FOSDEM. > > First, it's quite trivial to whiten that by only allowing a resolution > of 16 or so ms, which might mitigate various unrelated sidechannels > that think they have an oracle in WireGuard. > > Second, both Ivan and Jann have suggested that rather than always > adding a fresh timestamp, we should instead choose a per-peer base > time for the first handshake, and then simply increment that on each > handshake (making sure that the stamp never exceeds the current time). > While we're holding off on new features and nobs and whatnot until > post kernel merge, this would then enable us to potentially add a > specialized option for manually setting the base time. It would by > default remain the time, as it is now, since that's almost always a > reasonable decision. But for devices without an RTC and whose flash > chips prohibit writing out a new timestamp once a second or minute or > whatever, this would allow, instead, to just write out a counter once > per boot, which is much more reasonable. 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. I think this dance should handle a lot > of the issues discussed in this thread. > > Third, Ivan suggested that we actually add a blinding factor to the > timestamps, simply by adding HASH(label||private||public) or similar > to the stamp itself. I'll need to think carefully about the crypto > before committing to anything, but this kind of transformation does > not seem infeasible and might lessen a potential infoleak. A good > idea, in other words. > _______________________________________________ > WireGuard mailing list > WireGuard@lists.zx2c4.com > https://lists.zx2c4.com/mailman/listinfo/wireguard > _______________________________________________ WireGuard mailing list WireGuard@lists.zx2c4.com https://lists.zx2c4.com/mailman/listinfo/wireguard ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: WG: Need for HW-clock independent timestamps 2019-02-23 4:00 ` Axel Neumann @ 2019-02-23 12:35 ` Ivan Labáth 0 siblings, 0 replies; 15+ messages in thread From: Ivan Labáth @ 2019-02-23 12:35 UTC (permalink / raw) To: Axel Neumann; +Cc: neumann, WireGuard mailing list, Jann Horn 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 ^ permalink raw reply [flat|nested] 15+ messages in thread
end of thread, other threads:[~2019-02-23 12:35 UTC | newest] Thread overview: 15+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- [not found] <1522499692.6109802.1526903933505.ref@mail.yahoo.com> 2018-05-21 11:58 ` WG: Need for HW-clock independent timestamps reiner otto 2018-05-11 22:07 Axel Neumann 2018-05-21 10:07 ` 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 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).