WireGuard Archive on lore.kernel.org
 help / Atom feed
* WG: Need for HW-clock independent timestamps
@ 2018-05-11 22:07 Axel Neumann
  2018-05-11 22:45 ` Kalin KOZHUHAROV
  2018-05-21 10:07 ` WG: " Axel Neumann
  0 siblings, 2 replies; 39+ 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] 39+ messages in thread

* Re: Need for HW-clock independent timestamps
  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
                     ` (2 more replies)
  2018-05-21 10:07 ` WG: " Axel Neumann
  1 sibling, 3 replies; 39+ messages in thread
From: Kalin KOZHUHAROV @ 2018-05-11 22:45 UTC (permalink / raw)
  To: neumann; +Cc: WireGuard mailing list

On Sat, May 12, 2018 at 12:07 AM, Axel Neumann <neumann@cgws.de> wrote:
> 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.
>
Good/Hard problem!

> Any ideas how to circumvent this problem?
>
I only see 2 ways:
* hardware: add a cheap RTC (best), or storage (USB, SD)
* policy: add exception for ntpdate on base UDP (not WG) (or have
dedicated server/s for that, which you control).

BTW, while flash write cycles are indeed limited, you are writing a
very small data (that causes a single block to be rewritten).
So a device with say 32 MB(8000 x 4K blocks) will last about 9000
years if you write one block once per hour until 10% (=800) of its
cells are past 10^5 writes.
(or 3 years if you write once per second!)
But my knowledge says 10^3-10^4 write cycles (so still 90-900 years for 1/hour).

If you have a large number of devices of the same hardware, I'd
suggest a "kill test" of one of them, by rewriting its flash. You can
further use specific file-systems optimized for NAND/NOR flash.

Cheers,
Kalin.

^ permalink raw reply	[flat|nested] 39+ messages in thread

* Re: Need for HW-clock independent timestamps
  2018-05-11 22:45 ` Kalin KOZHUHAROV
@ 2018-05-12  0:05   ` Glen Bojsza
  2018-05-12 19:29   ` Axel Neumann
  2018-05-13 14:21   ` Wang Jian
  2 siblings, 0 replies; 39+ messages in thread
From: Glen Bojsza @ 2018-05-12  0:05 UTC (permalink / raw)
  To: WireGuard mailing list

[-- Attachment #1: Type: text/plain, Size: 2410 bytes --]

Why not add a configurable  timer feature to wireguard where you can set
the amount of time after power up before the wireguard vpn comes up? This
would solve the problem universally and may be the simplest / quickest
solution.

Disclaimer: I don't have a developer's background only a user's one so I am
not sure how hard this technically would be to implement...maybe someone
can weigh in from the wireguard team.

Glen

On Fri, May 11, 2018 at 6:46 PM Kalin KOZHUHAROV <me.kalin@gmail.com> wrote:

> On Sat, May 12, 2018 at 12:07 AM, Axel Neumann <neumann@cgws.de> wrote:
> > 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.
> >
> Good/Hard problem!
>
> > Any ideas how to circumvent this problem?
> >
> I only see 2 ways:
> * hardware: add a cheap RTC (best), or storage (USB, SD)
> * policy: add exception for ntpdate on base UDP (not WG) (or have
> dedicated server/s for that, which you control).
>
> BTW, while flash write cycles are indeed limited, you are writing a
> very small data (that causes a single block to be rewritten).
> So a device with say 32 MB(8000 x 4K blocks) will last about 9000
> years if you write one block once per hour until 10% (=800) of its
> cells are past 10^5 writes.
> (or 3 years if you write once per second!)
> But my knowledge says 10^3-10^4 write cycles (so still 90-900 years for
> 1/hour).
>
> If you have a large number of devices of the same hardware, I'd
> suggest a "kill test" of one of them, by rewriting its flash. You can
> further use specific file-systems optimized for NAND/NOR flash.
>
> Cheers,
> Kalin.
> _______________________________________________
> WireGuard mailing list
> WireGuard@lists.zx2c4.com
> https://lists.zx2c4.com/mailman/listinfo/wireguard
>

[-- Attachment #2: Type: text/html, Size: 3165 bytes --]

<div><div dir="auto">Why not add a configurable  timer feature to wireguard where you can set the amount of time after power up before the wireguard vpn comes up? This would solve the problem universally and may be the simplest / quickest solution.</div><div dir="auto"><br></div><div dir="auto">Disclaimer: I don&#39;t have a developer&#39;s background only a user&#39;s one so I am not sure how hard this technically would be to implement...maybe someone can weigh in from the wireguard team.</div><div dir="auto"><br></div><div dir="auto">Glen</div><br><div class="gmail_quote"><div>On Fri, May 11, 2018 at 6:46 PM Kalin KOZHUHAROV &lt;<a href="mailto:me.kalin@gmail.com">me.kalin@gmail.com</a>&gt; wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Sat, May 12, 2018 at 12:07 AM, Axel Neumann &lt;<a href="mailto:neumann@cgws.de" target="_blank">neumann@cgws.de</a>&gt; wrote:<br>
&gt; We have the following chicken-egg problem:<br>
&gt; We are using WG on openwrt devices which do not have a hardware clock so<br>
&gt; that time is resetted after each reboot.<br>
&gt; Because internet access shall be routed via WG tunnels the internet and<br>
&gt; network-time services (NTP) is not available unless WG works properly.<br>
&gt; But, guess, to reconnect, WG needs a greater time than before it<br>
&gt; rebooted :-(<br>
&gt;<br>
&gt; I heard that a suggested solution is to periodically save the current<br>
&gt; time to filesystem and then fix it during boot based on the last saved<br>
&gt; one. But all embedded devices use flash memory with a limited amount<br>
&gt; (about 10^5) of write cycles before they become unstable which would<br>
&gt; destroy the flash within weeks.<br>
&gt;<br>
Good/Hard problem!<br>
<br>
&gt; Any ideas how to circumvent this problem?<br>
&gt;<br>
I only see 2 ways:<br>
* hardware: add a cheap RTC (best), or storage (USB, SD)<br>
* policy: add exception for ntpdate on base UDP (not WG) (or have<br>
dedicated server/s for that, which you control).<br>
<br>
BTW, while flash write cycles are indeed limited, you are writing a<br>
very small data (that causes a single block to be rewritten).<br>
So a device with say 32 MB(8000 x 4K blocks) will last about 9000<br>
years if you write one block once per hour until 10% (=800) of its<br>
cells are past 10^5 writes.<br>
(or 3 years if you write once per second!)<br>
But my knowledge says 10^3-10^4 write cycles (so still 90-900 years for 1/hour).<br>
<br>
If you have a large number of devices of the same hardware, I&#39;d<br>
suggest a &quot;kill test&quot; of one of them, by rewriting its flash. You can<br>
further use specific file-systems optimized for NAND/NOR flash.<br>
<br>
Cheers,<br>
Kalin.<br>
_______________________________________________<br>
WireGuard mailing list<br>
<a href="mailto:WireGuard@lists.zx2c4.com" target="_blank">WireGuard@lists.zx2c4.com</a><br>
<a href="https://lists.zx2c4.com/mailman/listinfo/wireguard" rel="noreferrer" target="_blank">https://lists.zx2c4.com/mailman/listinfo/wireguard</a><br>
</blockquote></div></div>

^ permalink raw reply	[flat|nested] 39+ messages in thread

* Re: Need for HW-clock independent timestamps
  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
                       ` (3 more replies)
  2018-05-13 14:21   ` Wang Jian
  2 siblings, 4 replies; 39+ messages in thread
From: Axel Neumann @ 2018-05-12 19:29 UTC (permalink / raw)
  To: Kalin KOZHUHAROV; +Cc: WireGuard mailing list

Thanks a lot for your replies. But as you can see from my comments below
this all does not look like a valid option for many embedded use cases.
BTW, my background are community mesh networks which are maintained by
all kind of different individuals using a zoo of different device types.

I would really appreciate if WG can further elaborate on this issue.
There are many real-life communities with embedded-device deployments
that would be looking forward to use WG.

Could you also comment on the described approach (see again at the end
of the mail) of allowing (maybe as an alternative) a sequence number
instead of a timestamp?


More inline below...

On 12.05.2018 00:45, Kalin KOZHUHAROV wrote:
> On Sat, May 12, 2018 at 12:07 AM, Axel Neumann <neumann@cgws.de> wrote:
>> 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.
>>
> Good/Hard problem!
> 
>> Any ideas how to circumvent this problem?
>>
> I only see 2 ways:
> * hardware: add a cheap RTC (best), or storage (USB, SD)

That is not convenient. People buy standard devices, often for outdoor,
which can not easily be extended with extra storage.

> * policy: add exception for ntpdate on base UDP (not WG) (or have
> dedicated server/s for that, which you control).

You want WG to secure your network. So the suggestion can not be to open
your network for a pretty insecure deamon in order to get WG working.
This would essentially allow attackers to a fake the ntp server and then
block WG forever.

> 
> BTW, while flash write cycles are indeed limited, you are writing a
> very small data (that causes a single block to be rewritten).
> So a device with say 32 MB(8000 x 4K blocks) will last about 9000
> years if you write one block once per hour until 10% (=800) of its
> cells are past 10^5 writes.
> (or 3 years if you write once per second!)
> But my knowledge says 10^3-10^4 write cycles (so still 90-900 years for 1/hour).

Actually, many devices have only 8MB flash (some only 4MB almost
entirely used) and from this there is only few space left. So the blocks
used for storing can not be cycled as much as you suggest. And time
should not be saved 1/hour because nobody wants to wait an hour after a
reboot to let his connectivity recover. Such effects would likely cause
users to do any kind of panic-like rescue measures which usually hits
security first. So again, I don't think its a way to go.

> 
> If you have a large number of devices of the same hardware, 

Community networks don't !

> I'd
> suggest a "kill test" of one of them, by rewriting its flash. You can

I do not understand this. Could you explain in more detail?

> further use specific file-systems optimized for NAND/NOR flash.

I think openwrt already does a lot to optimize this. Still it would not
solve but only mitigate the problem.



On 12.05.2018 00:07, Axel Neumann wrote:
> 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.


Thanks a lot
/Axel

^ permalink raw reply	[flat|nested] 39+ messages in thread

* Re: Need for HW-clock independent timestamps
  2018-05-12 19:29   ` Axel Neumann
@ 2018-05-12 19:41     ` Aaron Jones
  2018-05-15 20:21       ` Devan Carpenter
  2018-05-12 22:10     ` Toke Høiland-Jørgensen
                       ` (2 subsequent siblings)
  3 siblings, 1 reply; 39+ messages in thread
From: Aaron Jones @ 2018-05-12 19:41 UTC (permalink / raw)
  To: neumann; +Cc: WireGuard mailing list

[-- Attachment #1.1: Type: text/plain, Size: 589 bytes --]

On 12/05/18 19:29, Axel Neumann wrote:
> You want WG to secure your network. So the suggestion can not be to open
> your network for a pretty insecure deamon in order to get WG working.
> This would essentially allow attackers to a fake the ntp server and then
> block WG forever.

Someone in a position to fake NTP (which needs bidirectional
communication) is already in a position to block WG forever (by simply
refusing to forward its packets).

Additionally, there are a few very well-designed and secure NTP daemons
out there (such as OpenNTPd).

-- 
Aaron Jones




[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 884 bytes --]

^ permalink raw reply	[flat|nested] 39+ messages in thread

* Re: Need for HW-clock independent timestamps
  2018-05-12 19:29   ` Axel Neumann
  2018-05-12 19:41     ` Aaron Jones
@ 2018-05-12 22:10     ` Toke Høiland-Jørgensen
  2018-05-12 23:05     ` Reuben Martin
  2018-05-13  6:11     ` Matthias Urlichs
  3 siblings, 0 replies; 39+ messages in thread
From: Toke Høiland-Jørgensen @ 2018-05-12 22:10 UTC (permalink / raw)
  To: neumann, Kalin KOZHUHAROV; +Cc: WireGuard mailing list

Axel Neumann <neumann@cgws.de> writes:

> Thanks a lot for your replies. But as you can see from my comments below
> this all does not look like a valid option for many embedded use cases.
> BTW, my background are community mesh networks which are maintained by
> all kind of different individuals using a zoo of different device
> types.

We had a long discussion on the issue of time on embedded routers with
no RTC around the time support for DNSSEC was added to dnsmasq. The
solution we ended up with in OpenWrt was that dnsmasq will run without
validating signatures until NTP indicates that it has synced to a time
server. See the --dnssec-no-timecheck and --dnssec-timestamp options to
dnsmasq for details on how this works.

You're right, of course, that "just add an RTC" is not a solution...

The analogue for a wireguard deployment would be to run NTP on the
unsecured links and not configure the wireguard tunnels until NTP has
synced. This has different security implications for a VPN than for
dnssec, of course, but it could be doable. Depends on your setup how
this is best done; you don't give enough details for me to have an
informed opinion :)

> I would really appreciate if WG can further elaborate on this issue.
> There are many real-life communities with embedded-device deployments
> that would be looking forward to use WG.
>
> Could you also comment on the described approach (see again at the end
> of the mail) of allowing (maybe as an alternative) a sequence number
> instead of a timestamp?

Can't comment on the security implications of this; but even if it is
possible without degrading the security of the protocol, this is a
non-trivial change at the protocol level; so if you want to deploy
anything within the next ~6-12 months, I'd suggest finding a
workaround...

-Toke

^ permalink raw reply	[flat|nested] 39+ messages in thread

* Re: Need for HW-clock independent timestamps
  2018-05-12 19:29   ` Axel Neumann
  2018-05-12 19:41     ` Aaron Jones
  2018-05-12 22:10     ` Toke Høiland-Jørgensen
@ 2018-05-12 23:05     ` Reuben Martin
  2018-05-13  6:11     ` Matthias Urlichs
  3 siblings, 0 replies; 39+ messages in thread
From: Reuben Martin @ 2018-05-12 23:05 UTC (permalink / raw)
  To: WireGuard mailing list

On Saturday, May 12, 2018 2:29:24 PM CDT Axel Neumann wrote:
> Thanks a lot for your replies. But as you can see from my comments below
> this all does not look like a valid option for many embedded use cases.

Perhaps it might make sense to add functionality for WG to request a timest=
amp=20
from peers and to reply to TS requests so long as they are signed with a va=
lid=20
key.

Implementing the WG side of a TS exchange would probably be fairly trivial,=
=20
but I don=E2=80=99t know what is involved to take the received timestamp an=
d use that=20
to set the system clock. That part might present a whole can of worms that=
=20
Jason may not want to deal with.

=2DReuben

^ permalink raw reply	[flat|nested] 39+ messages in thread

* Re: Need for HW-clock independent timestamps
  2018-05-12 19:29   ` Axel Neumann
                       ` (2 preceding siblings ...)
  2018-05-12 23:05     ` Reuben Martin
@ 2018-05-13  6:11     ` Matthias Urlichs
  2018-05-13 12:37       ` Toke Høiland-Jørgensen
  3 siblings, 1 reply; 39+ messages in thread
From: Matthias Urlichs @ 2018-05-13  6:11 UTC (permalink / raw)
  To: wireguard

[-- Attachment #1.1.1: Type: text/plain, Size: 1720 bytes --]

On 12.05.2018 21:29, Axel Neumann wrote:
> Thanks a lot for your replies. But as you can see from my comments below
> this all does not look like a valid option for many embedded use cases.
> BTW, my background are community mesh networks which are maintained by
> all kind of different individuals using a zoo of different device types.
>
> I would really appreciate if WG can further elaborate on this issue.
> There are many real-life communities with embedded-device deployments
> that would be looking forward to use WG.
>
> Could you also comment on the described approach (see again at the end
> of the mail) of allowing (maybe as an alternative) a sequence number
> instead of a timestamp?
What's the problem? the protocol documentation states

> The server keeps track of the greatest timestamp received /per client/
> and discards packets containing timestamps less than or equal to it.

I just checked the C implementation; it does this check (and no others).
In particular it doesn't check whether the timestamp field corresponds
to anybody's idea of the current time.

Thus you don't need current time; you just need to seed a counter. I
would thus add an option to wg.conf that, if present, sets the
interface's current timestamp to some value and uses it as a counter
instead of a timestamp.

Then, when you set up your WG instance, you should immediately rewrite
your wg.conf file (just add 2^32) so that a reboot doesn't DoS yourself.
Additionally, when you acquire NTP sync, set the parameter to the
TAI64N() of the current time. To be extra safe, repeat this every week
or month or so.

Can anybody think of problems with this solution?

-- 
-- Matthias Urlichs


[-- Attachment #1.1.2: Type: text/html, Size: 2269 bytes --]

<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=utf-8">
  </head>
  <body text="#000000" bgcolor="#FFFFFF">
    <div class="moz-cite-prefix">On 12.05.2018 21:29, Axel Neumann
      wrote:<br>
    </div>
    <blockquote type="cite"
      cite="mid:793381ba-b59d-50e4-6d7b-cbe9bef91ba1@cgws.de">
      <pre wrap="">Thanks a lot for your replies. But as you can see from my comments below
this all does not look like a valid option for many embedded use cases.
BTW, my background are community mesh networks which are maintained by
all kind of different individuals using a zoo of different device types.

I would really appreciate if WG can further elaborate on this issue.
There are many real-life communities with embedded-device deployments
that would be looking forward to use WG.

Could you also comment on the described approach (see again at the end
of the mail) of allowing (maybe as an alternative) a sequence number
instead of a timestamp?
</pre>
    </blockquote>
    What's the problem? the protocol documentation states<br>
    <br>
    &gt; The server keeps track of the greatest timestamp received <em>per
      client</em> <br>
    &gt; and discards packets containing timestamps less than or equal
    to it.<br>
    <br>
    I just checked the C implementation; it does this check (and no
    others). In particular it doesn't check whether the timestamp field
    corresponds to anybody's idea of the current time.<br>
    <br>
    Thus you don't need current time; you just need to seed a counter. I
    would thus add an option to wg.conf that, if present, sets the
    interface's current timestamp to some value and uses it as a counter
    instead of a timestamp.<br>
    <br>
    Then, when you set up your WG instance, you should immediately
    rewrite your wg.conf file (just add 2^32) so that a reboot doesn't
    DoS yourself. Additionally, when you acquire NTP sync, set the
    parameter to the TAI64N() of the current time. To be extra safe,
    repeat this every week or month or so.<br>
    <br>
    Can anybody think of problems with this solution?<br>
    <br>
    <pre class="moz-signature" cols="72">-- 
-- Matthias Urlichs</pre>
  </body>
</html>

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

^ permalink raw reply	[flat|nested] 39+ messages in thread

* Re: Need for HW-clock independent timestamps
  2018-05-13  6:11     ` Matthias Urlichs
@ 2018-05-13 12:37       ` Toke Høiland-Jørgensen
  2018-05-16  7:01         ` Axel Neumann
  0 siblings, 1 reply; 39+ messages in thread
From: Toke Høiland-Jørgensen @ 2018-05-13 12:37 UTC (permalink / raw)
  To: Matthias Urlichs, wireguard

Matthias Urlichs <matthias@urlichs.de> writes:

> Can anybody think of problems with this solution?

Well, the possibility of DOS if you set the counter too high, and the
possibility of replay attacks if you fail to save the last state when
you shut down comes to mind :)

(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).

-Toke

^ permalink raw reply	[flat|nested] 39+ messages in thread

* Re: Need for HW-clock independent timestamps
  2018-05-11 22:45 ` Kalin KOZHUHAROV
  2018-05-12  0:05   ` Glen Bojsza
  2018-05-12 19:29   ` Axel Neumann
@ 2018-05-13 14:21   ` Wang Jian
  2 siblings, 0 replies; 39+ messages in thread
From: Wang Jian @ 2018-05-13 14:21 UTC (permalink / raw)
  To: neumann; +Cc: WireGuard mailing list

[-- Attachment #1: Type: text/plain, Size: 577 bytes --]

2018-05-12 6:45 GMT+08:00 Kalin KOZHUHAROV <me.kalin@gmail.com>:
> I only see 2 ways:
> * hardware: add a cheap RTC (best), or storage (USB, SD)
> * policy: add exception for ntpdate on base UDP (not WG) (or have
> dedicated server/s for that, which you control).

As Kalin's suggestion, I think policy routing, or plain static route, is
the easier
solution.

You can point ntpdate or ntpd to a fixed ntp server, and add a rule or more
specific staticr oute for this fixed server.

Or, if you have a running computer in your local net, use that computer as
one of ntp servers.

[-- Attachment #2: Type: text/html, Size: 748 bytes --]

<div dir="ltr"><div>2018-05-12 6:45 GMT+08:00 Kalin KOZHUHAROV &lt;<a href="mailto:me.kalin@gmail.com">me.kalin@gmail.com</a>&gt;:<br>&gt; I only see 2 ways:<br>&gt; * hardware: add a cheap RTC (best), or storage (USB, SD)<br>&gt; * policy: add exception for ntpdate on base UDP (not WG) (or have<br>&gt; dedicated server/s for that, which you control).<br><br>As Kalin&#39;s suggestion, I think policy routing, or plain static route, is the easier<br></div>solution.<br><div><br>You can point ntpdate or ntpd to a fixed ntp server, and add a rule or more<br>specific staticr oute for this fixed server.<br><br></div><div>Or, if you have a running computer in your local net, use that computer as<br></div><div>one of ntp servers.<br></div></div>

^ permalink raw reply	[flat|nested] 39+ messages in thread

* Re: Need for HW-clock independent timestamps
  2018-05-12 19:41     ` Aaron Jones
@ 2018-05-15 20:21       ` Devan Carpenter
  2018-05-15 20:49         ` Kalin KOZHUHAROV
  0 siblings, 1 reply; 39+ messages in thread
From: Devan Carpenter @ 2018-05-15 20:21 UTC (permalink / raw)
  To: Aaron Jones; +Cc: WireGuard mailing list

[-- Attachment #1: Type: text/plain, Size: 990 bytes --]

Aaron Jones transcribed 3.1K bytes:
> On 12/05/18 19:29, Axel Neumann wrote:
> > You want WG to secure your network. So the suggestion can not be to open
> > your network for a pretty insecure deamon in order to get WG working.
> > This would essentially allow attackers to a fake the ntp server and then
> > block WG forever.
> 
> Someone in a position to fake NTP (which needs bidirectional
> communication) is already in a position to block WG forever (by simply
> refusing to forward its packets).
> 
> Additionally, there are a few very well-designed and secure NTP daemons
> out there (such as OpenNTPd).
> 

Using NTP is not a viable solution for a distributed mesh network. What
if the Internet is only accesible via WG, or what if the network is not
connected to the Internet at all? It's not a trivial problem, but I
think it would be benefecial to WireGuard as a project to not depend on
centralized time authority *if there is an option not to*.

-Devan


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

^ permalink raw reply	[flat|nested] 39+ messages in thread

* Re: Need for HW-clock independent timestamps
  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
  0 siblings, 2 replies; 39+ messages in thread
From: Kalin KOZHUHAROV @ 2018-05-15 20:49 UTC (permalink / raw)
  To: Devan Carpenter; +Cc: WireGuard mailing list

On Tue, May 15, 2018 at 10:21 PM, Devan Carpenter <mail@dvn.me> wrote:
> Aaron Jones transcribed 3.1K bytes:
>> On 12/05/18 19:29, Axel Neumann wrote:
>> > You want WG to secure your network. So the suggestion can not be to open
>> > your network for a pretty insecure deamon in order to get WG working.
>> > This would essentially allow attackers to a fake the ntp server and then
>> > block WG forever.
>>
>> Someone in a position to fake NTP (which needs bidirectional
>> communication) is already in a position to block WG forever (by simply
>> refusing to forward its packets).
>>
>> Additionally, there are a few very well-designed and secure NTP daemons
>> out there (such as OpenNTPd).
>>
>
> Using NTP is not a viable solution for a distributed mesh network. What
> if the Internet is only accesible via WG, or what if the network is not
> connected to the Internet at all?
>
Why do you need the Internet at all?
You can do as simple as plug a $20 GPS receiver (serial/USB) in any
node and get precise time that is shared with others in the network.
Heck, even go analog and use the Colorado WWV radio signal.
Or go fancy and buy a dedicated Cesium-backed "private" NTP server.

> It's not a trivial problem, but I think it would be benefecial to WireGuard as a project to not depend on
> centralized time authority *if there is an option not to*.
>
I wouldn't call universal time a "centralized authority", it is more
of a well-agreed-upon concept.
With a clear view of the sky and some math, you can use the stars (Sun
incl.) even and nobody can ban you from knowing the time.
It is not like say centralized DNS.

So, yes you need a method for obtaining the time at somewhat precise
scale[1], but "NTP-to-I'net" is just one somewhat convenient method.

[1]  Can anyone point me to the piece in code that shows that
precision? In other words, how far apart can 2 peers' clocks be and
still connect.
I spend some time grepping, but couldn't find it... I guess it is
connected to 'REJECT_AFTER_TIME = 180 * HZ;' ?

Cheers,
Kalin.

^ permalink raw reply	[flat|nested] 39+ messages in thread

* Need for HW-clock independent timestamps
  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
  0 siblings, 1 reply; 39+ messages in thread
From: Axel Neumann @ 2018-05-16  7:01 UTC (permalink / raw)
  To: Toke Høiland-Jørgensen, Matthias Urlichs, wireguard

[-- Attachment #1: Type: text/plain, Size: 2631 bytes --]

On 13.05.2018 14:37, Toke Høiland-Jørgensen wrote:> Matthias Urlichs
<matthias@urlichs.de> 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.

If the 
TAI64/96 bit timestamp field (64-bit seconds count + 32-bit nanoseconds count) 
in WG handshake_init messages is used as a counter, then it seems sufficient to just use the 32-bit nano-cnt part for sequential increments after each handshake. Only the sec-cnt part needs to be saved with a +1 value (implicitly assuming nano-cnt saved as zero): during wg modprobe and also whenever the in-memory nano-cnt value got 80% exhausted. Reserving room for 800 000 000 handshakes (in non-reboot cases) before a new fs-write operation is needed. Given that just the handshake-required ECDH-Curve25519 takes more than a ms (eg 769 handshake/s measured on my intel notebook) calculation, that would happen at most once every 10 days. But realistically rather in terms of month or years. 
So in practice, a sec-cnt+1 value, now representing not secs but handshake counts x 1000000000) would only be saved during each system boot or wg init.


> 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.


>
> (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.

/Axel

>
> -Toke
> _______________________________________________
> WireGuard mailing list
> WireGuard@lists.zx2c4.com
> https://lists.zx2c4.com/mailman/listinfo/wireguard
>


-- 
Diese Nachricht wurde von meinem Android-Gerät mit K-9 Mail gesendet.

[-- Attachment #2: Type: text/html, Size: 2950 bytes --]

On 13.05.2018 14:37, Toke Høiland-Jørgensen wrote:&gt; Matthias Urlichs<br>
&lt;matthias@urlichs.de&gt; writes:<br>
&gt;<br>
&gt;&gt; Can anybody think of problems with this solution?<br>
&gt;<br>
&gt; Well, the possibility of DOS if you set the counter too high,<br>
<br>
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<br>
counter? IMO this can be easily prevented.<br>
<br>
If the <br>
TAI64/96 bit timestamp field (64-bit seconds count + 32-bit nanoseconds count) <br>
in WG handshake_init messages is used as a counter, then it seems sufficient to just use the 32-bit nano-cnt part for sequential increments after each handshake. Only the sec-cnt part needs to be saved with a +1 value (implicitly assuming nano-cnt saved as zero): during wg modprobe and also whenever the in-memory nano-cnt value got 80% exhausted. Reserving room for 800 000 000 handshakes (in non-reboot cases) before a new fs-write operation is needed. Given that just the handshake-required ECDH-Curve25519 takes more than a ms (eg 769 handshake/s measured on my intel notebook) calculation, that would happen at most once every 10 days. But realistically rather in terms of month or years. <br>
So in practice, a sec-cnt+1 value, now representing not secs but handshake counts x 1000000000) would only be saved during each system boot or wg init.<br>
<br>
<br>
&gt; and the<br>
&gt; possibility of replay attacks if you fail to save the last state when<br>
&gt; you shut down comes to mind :)<br>
<br>
Where is that possibility? If you fail then you would send<br>
handshake_initiation messages with an already outdated timestamp field.  Exactly what now happens by default with non-HWC equipped devices after each reboot.<br>
<br>
<br>
&gt;<br>
&gt; (Not saying it&#39;s not possible to create a workable solution, just that<br>
&gt; it&#39;s not trivial and requires careful thought to not break the security<br>
&gt; assumptions of the protocol).<br>
<br>
I agree,<br>
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<br>
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.<br>
<br>
/Axel<br>
<br>
&gt;<br>
&gt; -Toke<br>
&gt; _______________________________________________<br>
&gt; WireGuard mailing list<br>
&gt; WireGuard@lists.zx2c4.com<br>
&gt; <a href="https://lists.zx2c4.com/mailman/listinfo/wireguard">https://lists.zx2c4.com/mailman/listinfo/wireguard</a><br>
&gt;<br>
<br>
<br>
-- <br>
Diese Nachricht wurde von meinem Android-Gerät mit K-9 Mail gesendet.

^ permalink raw reply	[flat|nested] 39+ messages in thread

* Re: Need for HW-clock independent timestamps
  2018-05-15 20:49         ` Kalin KOZHUHAROV
@ 2018-05-16  7:10           ` Matthias Urlichs
  2018-05-16 19:32           ` Axel Neumann
  1 sibling, 0 replies; 39+ messages in thread
From: Matthias Urlichs @ 2018-05-16  7:10 UTC (permalink / raw)
  To: wireguard

On 15.05.2018 22:49, Kalin KOZHUHAROV wrote:
> [1]  Can anyone point me to the piece in code that shows that
> precision? In other words, how far apart can 2 peers' clocks be and
> still connect.

Infinite.

Seriously. The timestamp field is essentially a counter. It just counts
up in rather large time-based increments and happens to be seeded with
the current time, in the current implementation that is. If you forego
all of that, seed it with one, and make sure that there'll never be a
decrement (for instance by saving the current value + a trillion after
every reboot – you don't reboot a router often enough to endanger your
flash that way) you're all set.

-- 
-- Matthias Urlichs

^ permalink raw reply	[flat|nested] 39+ messages in thread

* Re: Need for HW-clock independent timestamps
  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
  0 siblings, 2 replies; 39+ messages in thread
From: Toke Høiland-Jørgensen @ 2018-05-16  9:38 UTC (permalink / raw)
  To: Axel Neumann, Matthias Urlichs, wireguard

Axel Neumann <neumann@cgws.de> writes:

> On 13.05.2018 14:37, Toke H=C3=B8iland-J=C3=B8rgensen wrote:> Matthias Ur=
lichs
> <matthias@urlichs.de> 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".

-Toke

^ permalink raw reply	[flat|nested] 39+ messages in thread

* Re: Need for HW-clock independent timestamps
  2018-05-16  9:38           ` Toke Høiland-Jørgensen
@ 2018-05-16 11:08             ` Matthias Urlichs
  2018-05-16 11:12             ` Axel Neumann
  1 sibling, 0 replies; 39+ messages in thread
From: Matthias Urlichs @ 2018-05-16 11:08 UTC (permalink / raw)
  To: Toke Høiland-Jørgensen, Axel Neumann, wireguard

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

^ permalink raw reply	[flat|nested] 39+ messages in thread

* Re: Need for HW-clock independent timestamps
  2018-05-16  9:38           ` Toke Høiland-Jørgensen
  2018-05-16 11:08             ` Matthias Urlichs
@ 2018-05-16 11:12             ` Axel Neumann
  1 sibling, 0 replies; 39+ messages in thread
From: Axel Neumann @ 2018-05-16 11:12 UTC (permalink / raw)
  To: Toke Høiland-Jørgensen, Matthias Urlichs, wireguard



Am 16=2E Mai 2018 11:38:23 MESZ schrieb "Toke H=C3=B8iland-J=C3=B8rgensen"=
 <toke@toke=2Edk>:
>Axel Neumann <neumann@cgws=2Ede> writes:
>
>> On 13=2E05=2E2018 14:37, Toke H=C3=B8iland-J=C3=B8rgensen wrote:> Matth=
ias Urlichs
>> <matthias@urlichs=2Ede> 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=2E So do you mean DOS in case your hit a wrap around o=
f
>> the counter? IMO this can be easily prevented=2E
>
>No I meant DOS if you fail to save state properly=2E I=2Ee=2E, I send seq=
no
>100000, lose my state, reboot, and re-initialise to seqno 100=2E I have
>now essentially locked myself out of the network until my seqno goes
>above 100000 again=2E Since I have no way of reliably detecting this
>condition, there is no straight-forward manual recovery possible=2E

Ok, then measures to mitigate this likelyhood are needed=2E But as said, i=
t boils down to incrementing and saving  a number during each system boot=
=2E Don't you think thid can be done in a reliable way=2E

>
>>> 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=2E Exactly what now happens by default with non-HWC equipped
>> devices after each reboot=2E
>
>You'd need to not only save your own seqno, but also the last seen
>seqno
>from every peer=2E Otherwise you're vulnerable to a replay attack after
>rebooting=2E And if you lose that state you are, well, vulnerable to a
>replay attack after rebooting :)

With my understanding, the same issue exists right now=2E The peers only v=
erify if a less or equal timestamp has been seen before from this peer=2E P=
eer timestamps are not recovered over reboots and also NOT related to its o=
wn clock or timestamps=2E As said in the other thread=2E Time discrepancy c=
an be infinite as long as it increases monotonically per peer=2E

/axel


>
>>> (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)=2E
>>
>> 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=2E
>> Like super-simple WG and firewall setup=2E 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=2E That does not sound like the WG philosophy to me=2E
>
>Oh, I totally agree that it would be good if a solution could be found
>to this=2E I'm just objecting to the assertion that "it's easy, just
>replace the timestamp with an increasing seqno"=2E
>
>-Toke

--=20
Diese Nachricht wurde von meinem Android-Ger=C3=A4t mit K-9 Mail gesendet=
=2E

^ permalink raw reply	[flat|nested] 39+ messages in thread

* Re: Need for HW-clock independent timestamps
  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-16 20:35             ` Kalin KOZHUHAROV
  1 sibling, 2 replies; 39+ messages in thread
From: Axel Neumann @ 2018-05-16 19:32 UTC (permalink / raw)
  To: wireguard, Kalin KOZHUHAROV, Devan Carpenter; +Cc: WireGuard mailing list

[-- Attachment #1: Type: text/plain, Size: 1172 bytes --]



Am 15. Mai 2018 22:49:15 MESZ schrieb Kalin KOZHUHAROV <me.kalin@gmail.com>:
>On Tue, May 15, 2018 at 10:21 PM, Devan Carpenter 

>> Using NTP is not a viable solution for a distributed mesh network.
>What
>> if the Internet is only accesible via WG, or what if the network is
>not
>> connected to the Internet at all?
>>
>Why do you need the Internet at all?
>You can do as simple as plug a $20 GPS receiver (serial/USB) in any
>node and get precise time that is shared with others in the network.

$20 would increase the HW cost of many typical community-networks (CN) deployments significantly. Plus requiering more knowledge, maintenence, and power supply for sometimes solar-powered setups. Think of a recent typical CN node like this [1], so no usb. The admins are not hackers. Also there are tens of thousands of existing and productively operating (partially 5-10-years-old) nodes that nobody wants to upgrade HW wise. 
It is really NOT as simple as it sounds to plug a  $20 GPS !!!

[1] https://www.tp-link.com/en/products/details/cat-37_CPE510.html


/axel



-- 
Diese Nachricht wurde von meinem Android-Gerät mit K-9 Mail gesendet.

[-- Attachment #2: Type: text/html, Size: 1401 bytes --]

<br>
<br>
Am 15. Mai 2018 22:49:15 MESZ schrieb Kalin KOZHUHAROV &lt;me.kalin@gmail.com&gt;:<br>
&gt;On Tue, May 15, 2018 at 10:21 PM, Devan Carpenter <br>
<br>
&gt;&gt; Using NTP is not a viable solution for a distributed mesh network.<br>
&gt;What<br>
&gt;&gt; if the Internet is only accesible via WG, or what if the network is<br>
&gt;not<br>
&gt;&gt; connected to the Internet at all?<br>
&gt;&gt;<br>
&gt;Why do you need the Internet at all?<br>
&gt;You can do as simple as plug a $20 GPS receiver (serial/USB) in any<br>
&gt;node and get precise time that is shared with others in the network.<br>
<br>
$20 would increase the HW cost of many typical community-networks (CN) deployments significantly. Plus requiering more knowledge, maintenence, and power supply for sometimes solar-powered setups. Think of a recent typical CN node like this [1], so no usb. The admins are not hackers. Also there are tens of thousands of existing and productively operating (partially 5-10-years-old) nodes that nobody wants to upgrade HW wise. <br>
It is really NOT as simple as it sounds to plug a  $20 GPS !!!<br>
<br>
[1] <a href="https://www.tp-link.com/en/products/details/cat-37_CPE510.html">https://www.tp-link.com/en/products/details/cat-37_CPE510.html</a><br>
<br>
<br>
/axel<br>
<br>
<br>
<br>
-- <br>
Diese Nachricht wurde von meinem Android-Gerät mit K-9 Mail gesendet.

^ permalink raw reply	[flat|nested] 39+ messages in thread

* Re: Need for HW-clock independent timestamps
  2018-05-16 19:32           ` Axel Neumann
@ 2018-05-16 20:32             ` Steve Gilberd
  2018-05-17  3:40               ` Paul
  2018-05-16 20:35             ` Kalin KOZHUHAROV
  1 sibling, 1 reply; 39+ messages in thread
From: Steve Gilberd @ 2018-05-16 20:32 UTC (permalink / raw)
  To: Axel Neumann; +Cc: wireguard

[-- Attachment #1: Type: text/plain, Size: 1139 bytes --]

> $20 would increase the HW cost of many typical community-networks (CN)
deployments significantly.

This seems unlikely. In most cases, $20 is notably less than the cost of a
single node.

> Plus requiering more knowledge, maintenence, and power supply for
sometimes solar-powered setups... no USB.

If that's a concern, then put the GPS on nodes where those constraints
aren't a problem. You only need GPS on a few nodes (or one node if you
don't care about redundancy). Most nodes will get by just fine with just
plain NTP, and can happily fetch their time from the GPS nodes, or from
other non-GPS nodes with a correct time sync.

> It is really NOT as simple as it sounds to plug a $20 GPS !!!

It's not particularly complicated either. The actual setup of the devices
isn't particularly difficult, and you're already touching these nodes to
set up wireguard on them, so "I have to touch the config" isn't a barrier
in this case.

Cheers,
Steve
-- 

Cheers,

*Steve Gilberd*
Erayd LTD *·* Consultant
*Phone: +64 4 974-4229 **·** Mob: +64 27 565-3237*
*PO Box 10019, The Terrace, Wellington 6143, NZ*

[-- Attachment #2: Type: text/html, Size: 1850 bytes --]

&gt; $20 would increase the HW cost of many typical community-networks (CN) deployments significantly.<div><br></div><div>This seems unlikely. In most cases, $20 is notably less than the cost of a single node.<br><div dir="auto"><br></div><div dir="auto">&gt; Plus requiering more knowledge, maintenence, and power supply for sometimes solar-powered setups... no USB.</div><div dir="auto"><br></div><div dir="auto">If that&#39;s a concern, then put the GPS on nodes where those constraints aren&#39;t a problem. You only need GPS on a few nodes (or one node if you don&#39;t care about redundancy). Most nodes will get by just fine with just plain NTP, and can happily fetch their time from the GPS nodes, or from other non-GPS nodes with a correct time sync.</div><div dir="auto"><br></div><div dir="auto">&gt; It is really NOT as simple as it sounds to plug a $20 GPS !!!</div><div dir="auto"><br></div><div dir="auto">It&#39;s not particularly complicated either. The actual setup of the devices isn&#39;t particularly difficult, and you&#39;re already touching these nodes to set up wireguard on them, so &quot;I have to touch the config&quot; isn&#39;t a barrier in this case.</div><div dir="auto"><br></div><div dir="auto">Cheers,</div><div dir="auto">Steve</div></div>-- <br><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature"><p dir="ltr">Cheers,</p>
<p dir="ltr"><b>Steve Gilberd</b><br>
<span style="color:#666666">Erayd LTD </span><span style="color:#666666"><b>·</b></span><span style="color:#666666"> Consultant</span><br>
<span style="color:#666666"><i>Phone: +64 4 974-4229 </i></span><span style="color:#666666"><i><b>·</b></i></span><span style="color:#666666"><i> Mob: +64 27 565-3237</i></span><br>
<span style="color:#666666"><i>PO Box 10019, The Terrace, Wellington 6143, NZ</i></span></p>
</div>

^ permalink raw reply	[flat|nested] 39+ messages in thread

* Re: Need for HW-clock independent timestamps
  2018-05-16 19:32           ` Axel Neumann
  2018-05-16 20:32             ` Steve Gilberd
@ 2018-05-16 20:35             ` Kalin KOZHUHAROV
  1 sibling, 0 replies; 39+ messages in thread
From: Kalin KOZHUHAROV @ 2018-05-16 20:35 UTC (permalink / raw)
  To: Axel Neumann; +Cc: WireGuard mailing list

Hello Axel,

I may have not been clear in my last response, it was to be taken in
the context of the whole thread...

On Wed, May 16, 2018 at 9:32 PM, Axel Neumann <neumann@cgws.de> wrote:
>
>
> Am 15. Mai 2018 22:49:15 MESZ schrieb Kalin KOZHUHAROV <me.kalin@gmail.com>:
>>On Tue, May 15, 2018 at 10:21 PM, Devan Carpenter
>
>>> Using NTP is not a viable solution for a distributed mesh network.
>>What
>>> if the Internet is only accesible via WG, or what if the network is
>>not
>>> connected to the Internet at all?
>>>
>>Why do you need the Internet at all?
>>You can do as simple as plug a $20 GPS receiver (serial/USB) in any
>>node and get precise time that is shared with others in the network.
>
I meant to have one (or few) nodes that do provide time over UDP from
a GPS or other time-source, i.e. not connected to the Internet.
Not every node needs that.

Alternatively, as a pure software solution, every node of the network
may be required to run ntp on udp, or even other time protocol (say
RFC 867, RFC 868).
So any new node, before connecting to the WG endpoint with WG tunnel,
sets its time from it.
Nodes that do have access to the Net (exit nodes in a way), can run
ntpd internally and also don't need GPS or other time sources, if the
purpose of the network is "connect to the Net".

Cheers,
Kalin.

^ permalink raw reply	[flat|nested] 39+ messages in thread

* Re: Need for HW-clock independent timestamps
  2018-05-16 20:32             ` Steve Gilberd
@ 2018-05-17  3:40               ` Paul
  2018-05-17  5:03                 ` Roman Mamedov
  0 siblings, 1 reply; 39+ messages in thread
From: Paul @ 2018-05-17  3:40 UTC (permalink / raw)
  To: Steve Gilberd; +Cc: wireguard

Hi all,

If I'm not mistaken replay attacks are checked here [1] and only 
compare integers with no reference to local time of the receiving node.

The sending nodes timestamp is generated via tai64n_now [2][3]. From my 
understanding this function could simply be changed to a auto increased 
counter, periodically saved on disc and increased on boot, following 
the approach described by Axel Neumann[4]. Mixing real timestamps and 
counter should be compatible to one another. Only drawback is see is 
that the overview function is likely mixed up [5].

All could be done by a patch specifically for HW-clock less devices or 
added to OpenWrt buildroot only[6].

Any reasons why such a patch could be bad?

[1]: 
https://github.com/WireGuard/WireGuard/blob/ddb82700a810c3f929e5a2fff00254b29eadc689/src/noise.c#L454
[2]: 
https://github.com/WireGuard/WireGuard/blob/ddb82700a810c3f929e5a2fff00254b29eadc689/src/noise.c#L353
[3]: 
https://github.com/WireGuard/WireGuard/blob/ddb82700a810c3f929e5a2fff00254b29eadc689/src/noise.c#L396
[4]: https://github.com/bmx-routing/bmx7/blob/semtor/bmx.c#L1397
[5]: 
https://github.com/WireGuard/WireGuard/blob/a7f2ceacb9ee09ab37302cddc0ce15a96fd95e70/src/tools/show.c#L25
[6]: 
https://github.com/openwrt/openwrt/tree/master/package/network/services/wireguard/patches

Just a few thoughts regarding GPS:

On Thu, May 17, 2018 at 5:32 AM, Steve Gilberd <steve@erayd.net> wrote:
> > $20 would increase the HW cost of many typical community-networks 
> (CN) deployments significantly.
> 
> This seems unlikely. In most cases, $20 is notably less than the cost 
> of a single node.

I'd doubt that. People massively use TP-Link 841 (~20$, 100%) or 
Uqiquity Nanobeams (~60$, 34%) as node hardware.

> > Plus requiering more knowledge, maintenence, and power supply for 
> sometimes solar-powered setups... no USB.
> 
> If that's a concern, then put the GPS on nodes where those 
> constraints aren't a problem. You only need GPS on a few nodes (or 
> one node if you don't care about redundancy). Most nodes will get by 
> just fine with just plain NTP, and can happily fetch their time from 
> the GPS nodes, or from other non-GPS nodes with a correct time sync.

This was already answered and found as unusable as it introduces 
additional configuration of all nodes, firewall rules, etc?

> 
> > It is really NOT as simple as it sounds to plug a $20 GPS !!!
> 
> It's not particularly complicated either. The actual setup of the 
> devices isn't particularly difficult, and you're already touching 
> these nodes to set up wireguard on them, so "I have to touch the 
> config" isn't a barrier in this case.

Opening and closing (in a waterproof manner) the previously mentioned 
Nanobeam is not particularly trivial. Also it introduces a whole stack 
of device specific knowledge. As stated before, this changes the 
configuration from "enter wireguard credentials" to "{open, buy 
additional, glue} hardware, setup {wireguard, gps, more?}.

For me it looks like a problem solvable in software (as done for the 
BMX routing protocol). Why even bother to get hardware involved?

Sunshine,
Paul

^ permalink raw reply	[flat|nested] 39+ messages in thread

* Re: Need for HW-clock independent timestamps
  2018-05-17  3:40               ` Paul
@ 2018-05-17  5:03                 ` Roman Mamedov
  2018-05-17  5:53                   ` Matthias Urlichs
  0 siblings, 1 reply; 39+ messages in thread
From: Roman Mamedov @ 2018-05-17  5:03 UTC (permalink / raw)
  To: Paul; +Cc: wireguard

On Thu, 17 May 2018 12:40:55 +0900
Paul <paul@makrotopia.org> wrote:

> For me it looks like a problem solvable in software (as done for the 
> BMX routing protocol). Why even bother to get hardware involved?

Personally I am puzzled this is even an issue in WG. Not a single other VPN
protocol mandates every node to keep a monotonically increasing counter,
including even over reboots.

This has never been an issue in Tinc and OpenVPN at least, and if I'm not
mistaken neither in IPsec. And now suddenly we have people saying everyone now
has to buy and solder in some satellite based hardware just to use a VPN.

Given this didn't even arise in other VPN solutions, surely there must be other
way to solve the "replay attack" issue, without requiring an RTC (or a
persistent counter)? Perhaps nobody has just thought long enough about finding
one, and given the project in the early stages, just using the RTC (which
"everyone has") was chosen as a quick placeholder for now?

-- 
With respect,
Roman

^ permalink raw reply	[flat|nested] 39+ messages in thread

* Re: Need for HW-clock independent timestamps
  2018-05-17  5:03                 ` Roman Mamedov
@ 2018-05-17  5:53                   ` Matthias Urlichs
  2018-05-17  7:07                     ` Axel Neumann
  0 siblings, 1 reply; 39+ messages in thread
From: Matthias Urlichs @ 2018-05-17  5:53 UTC (permalink / raw)
  To: wireguard

On 17.05.2018 07:03, Roman Mamedov wrote:
> Personally I am puzzled this is even an issue in WG. Not a single other VPN
> protocol mandates every node to keep a monotonically increasing counter,
> including even over reboots.

Wireguard's connection setup is a whole lot simpler than most other
protocols. It basically doesn't require a "real" handshake, just a
request/reply pair. Thus it's vulnerable against disruption by replay
attacks – a replayed rekey packet would disrupt conversation until the
real sender times out, a minute later.

-- 
-- Matthias Urlichs

^ permalink raw reply	[flat|nested] 39+ messages in thread

* Re: Need for HW-clock independent timestamps
  2018-05-17  5:53                   ` Matthias Urlichs
@ 2018-05-17  7:07                     ` Axel Neumann
  2018-05-17  8:28                       ` Matthias Urlichs
  0 siblings, 1 reply; 39+ messages in thread
From: Axel Neumann @ 2018-05-17  7:07 UTC (permalink / raw)
  To: wireguard, Matthias Urlichs



Am 17=2E Mai 2018 07:53:17 MESZ schrieb Matthias Urlichs <matthias@urlichs=
=2Ede>:
>On 17=2E05=2E2018 07:03, Roman Mamedov wrote:
>> Personally I am puzzled this is even an issue in WG=2E Not a single
>other VPN
>> protocol mandates every node to keep a monotonically increasing
>counter,
>> including even over reboots=2E
>
>Wireguard's connection setup is a whole lot simpler than most other

But only if you ignore the implications coming with NTP transmissions=2E
its like Outsourcing some state transfer to another service and then claim=
 that remaining procedures are most simple=2E=20
/axel

>protocols=2E It basically doesn't require a "real" handshake, just a
>request/reply pair=2E Thus it's vulnerable against disruption by replay
>attacks =E2=80=93 a replayed rekey packet would disrupt conversation unti=
l the
>real sender times out, a minute later=2E
>
>--=20
>-- Matthias Urlichs
>
>_______________________________________________
>WireGuard mailing list
>WireGuard@lists=2Ezx2c4=2Ecom
>https://lists=2Ezx2c4=2Ecom/mailman/listinfo/wireguard

--=20
Diese Nachricht wurde von meinem Android-Ger=C3=A4t mit K-9 Mail gesendet=
=2E

^ permalink raw reply	[flat|nested] 39+ messages in thread

* Re: Need for HW-clock independent timestamps
  2018-05-17  7:07                     ` Axel Neumann
@ 2018-05-17  8:28                       ` Matthias Urlichs
  0 siblings, 0 replies; 39+ messages in thread
From: Matthias Urlichs @ 2018-05-17  8:28 UTC (permalink / raw)
  To: Axel Neumann, wireguard

[-- Attachment #1: Type: text/plain, Size: 402 bytes --]

On 17.05.2018 09:07, Axel Neumann wrote:
>> Wireguard's connection setup is a whole lot simpler than most other
> But only if you ignore the implications coming with NTP transmissions.

The implication is to require a monotonically increasing 96-bit value.
Using NTP is one way to do that. There are obviously others which do not
depend on external protocols and/or services.

-- 
-- Matthias Urlichs


[-- Attachment #2: Type: text/html, Size: 913 bytes --]

<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=utf-8">
  </head>
  <body text="#000000" bgcolor="#FFFFFF">
    <div class="moz-cite-prefix">On 17.05.2018 09:07, Axel Neumann
      wrote:<br>
    </div>
    <blockquote type="cite"
      cite="mid:AA544EA9-A23B-4F49-A468-617F5DF2B035@cgws.de">
      <blockquote type="cite" style="color: #000000;">
        <pre wrap="">Wireguard's connection setup is a whole lot simpler than most other
</pre>
      </blockquote>
      <pre wrap="">But only if you ignore the implications coming with NTP transmissions.</pre>
    </blockquote>
    <p>The implication is to require a monotonically increasing 96-bit
      value. Using NTP is one way to do that. There are obviously others
      which do not depend on external protocols and/or services.</p>
    <pre class="moz-signature" cols="72">-- 
-- Matthias Urlichs</pre>
  </body>
</html>

^ permalink raw reply	[flat|nested] 39+ messages in thread

* Re: WG: Need for HW-clock independent timestamps
  2018-05-11 22:07 WG: Need for HW-clock independent timestamps Axel Neumann
  2018-05-11 22:45 ` Kalin KOZHUHAROV
@ 2018-05-21 10:07 ` " Axel Neumann
  2018-05-21 11:22   ` Reto Brunner
  1 sibling, 1 reply; 39+ 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] 39+ messages in thread

* Re: WG: Need for HW-clock independent timestamps
  2018-05-21 10:07 ` WG: " Axel Neumann
@ 2018-05-21 11:22   ` Reto Brunner
  2018-05-21 11:52     ` Axel Neumann
  0 siblings, 1 reply; 39+ 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] 39+ 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; 39+ 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] 39+ 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; 39+ 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] 39+ 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; 39+ 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] 39+ 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; 39+ 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] 39+ 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; 39+ 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] 39+ 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; 39+ 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] 39+ 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; 39+ 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] 39+ 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; 39+ 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] 39+ 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; 39+ 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] 39+ 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; 39+ 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] 39+ 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; 39+ 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] 39+ messages in thread

* 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; 39+ 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] 39+ messages in thread

end of thread, back to index

Thread overview: 39+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
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
     [not found] <1522499692.6109802.1526903933505.ref@mail.yahoo.com>
2018-05-21 11:58 ` reiner otto

WireGuard Archive on lore.kernel.org

Archives are clonable:
	git clone --mirror https://lore.kernel.org/wireguard/0 wireguard/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 wireguard wireguard/ https://lore.kernel.org/wireguard \
		wireguard@lists.zx2c4.com zx2c4-wireguard@archiver.kernel.org
	public-inbox-index wireguard


Newsgroup available over NNTP:
	nntp://nntp.lore.kernel.org/com.zx2c4.lists.wireguard


AGPL code for this site: git clone https://public-inbox.org/ public-inbox