Re: Need for HW-clock independent timestamps
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 ___ WireGuard mailing list WireGuard@lists.zx2c4.com https://lists.zx2c4.com/mailman/listinfo/wireguard
Re: Need for HW-clock independent timestamps
Am 17. Mai 2018 07:53:17 MESZ schrieb Matthias Urlichs : >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 But only if you ignore the implications coming with NTP transmissions. its like Outsourcing some state transfer to another service and then claim that remaining procedures are most simple. /axel >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 > >___ >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. ___ WireGuard mailing list WireGuard@lists.zx2c4.com https://lists.zx2c4.com/mailman/listinfo/wireguard
Re: Need for HW-clock independent timestamps
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 ___ WireGuard mailing list WireGuard@lists.zx2c4.com https://lists.zx2c4.com/mailman/listinfo/wireguard
Re: Need for HW-clock independent timestamps
On Thu, 17 May 2018 12:40:55 +0900 Paul 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 ___ WireGuard mailing list WireGuard@lists.zx2c4.com https://lists.zx2c4.com/mailman/listinfo/wireguard
Re: Need for HW-clock independent timestamps
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 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
___
WireGuard mailing list
WireGuard@lists.zx2c4.com
https://lists.zx2c4.com/mailman/listinfo/wireguard
Re: Need for HW-clock independent timestamps
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 wrote: > > > Am 15. Mai 2018 22:49:15 MESZ schrieb Kalin KOZHUHAROV : >>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. ___ WireGuard mailing list WireGuard@lists.zx2c4.com https://lists.zx2c4.com/mailman/listinfo/wireguard
Re: Need for HW-clock independent timestamps
> $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* ___ WireGuard mailing list WireGuard@lists.zx2c4.com https://lists.zx2c4.com/mailman/listinfo/wireguard
Re: Need for HW-clock independent timestamps
Am 15. Mai 2018 22:49:15 MESZ schrieb Kalin KOZHUHAROV : >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.___ WireGuard mailing list WireGuard@lists.zx2c4.com https://lists.zx2c4.com/mailman/listinfo/wireguard
Re: Need for HW-clock independent timestamps
Am 16. Mai 2018 11:38:23 MESZ schrieb "Toke Høiland-Jørgensen" : >Axel Neumann writes: > >> On 13.05.2018 14:37, Toke Høiland-Jørgensen wrote:> Matthias Urlichs >> 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 >10, 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 10 again. Since I have no way of reliably detecting this >condition, there is no straight-forward manual recovery possible. Ok, then measures to mitigate this likelyhood are needed. But as said, it boils down to incrementing and saving a number during each system boot. Don't you think thid can be done in a reliable way. > >>> 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 :) With my understanding, the same issue exists right now. The peers only verify if a less or equal timestamp has been seen before from this peer. Peer timestamps are not recovered over reboots and also NOT related to its own clock or timestamps. As said in the other thread. Time discrepancy can be infinite as long as it increases monotonically per peer. /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). >> >> 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 -- Diese Nachricht wurde von meinem Android-Gerät mit K-9 Mail gesendet. ___ WireGuard mailing list WireGuard@lists.zx2c4.com https://lists.zx2c4.com/mailman/listinfo/wireguard
Re: Need for HW-clock independent timestamps
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 > 10, 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 ___ WireGuard mailing list WireGuard@lists.zx2c4.com https://lists.zx2c4.com/mailman/listinfo/wireguard
Re: Need for HW-clock independent timestamps
Axel Neumann writes: > On 13.05.2018 14:37, Toke Høiland-Jørgensen wrote:> Matthias Urlichs > 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 10, 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 10 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 ___ WireGuard mailing list WireGuard@lists.zx2c4.com https://lists.zx2c4.com/mailman/listinfo/wireguard
Re: Need for HW-clock independent timestamps
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 ___ WireGuard mailing list WireGuard@lists.zx2c4.com https://lists.zx2c4.com/mailman/listinfo/wireguard
Re: Need for HW-clock independent timestamps
On Tue, May 15, 2018 at 10:21 PM, Devan Carpenter 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. ___ WireGuard mailing list WireGuard@lists.zx2c4.com https://lists.zx2c4.com/mailman/listinfo/wireguard
Re: Need for HW-clock independent timestamps
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 signature.asc Description: PGP signature ___ WireGuard mailing list WireGuard@lists.zx2c4.com https://lists.zx2c4.com/mailman/listinfo/wireguard
Re: Need for HW-clock independent timestamps
2018-05-12 6:45 GMT+08:00 Kalin KOZHUHAROV : > 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. ___ WireGuard mailing list WireGuard@lists.zx2c4.com https://lists.zx2c4.com/mailman/listinfo/wireguard
Re: Need for HW-clock independent timestamps
Matthias Urlichs 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 ___ WireGuard mailing list WireGuard@lists.zx2c4.com https://lists.zx2c4.com/mailman/listinfo/wireguard
Re: Need for HW-clock independent timestamps
reiner otto writes: > Having implemented this solution already, I consider it some type of > hack, as the standard time sync unfortunately happens very late in the > start of the services, after rc.local called. And the sync might take > quite some time. > > Which means, I had to "hack" the time sync immediately after WAN up, > and to be done in a single shot, before starting WG. Yeah, messing init script order is going to be hackish. You'd want to add a hotplug script to react to when the NTP daemon syncs and apply config after that. See the dnsmasq hotplug script for an example: https://git.openwrt.org/?p=openwrt/openwrt.git;a=blob;f=package/network/services/dnsmasq/files/dnsmasqsec.hotplug;h=781d5337348bb8e927bd15f1caac94a5e7a9ba63;hb=HEAD For WG it should be necessary to wait to configure the wg interfaces; they just won't validate correctly until time is fixed. So you could configure the interfaces in /etc/config/network and just have the hotplug script add the default route (or whatever your needs are). > However, as a real RTC is rather cheap, it might be a good idea, in > case of commercial apps, to ask the supplier of the device to be used > for the inclusion of a RTC. The more requests, the better the chances > to find more devices with RTC included. Sure, for people who are building their own hardware. Most people aren't, though... -Toke ___ WireGuard mailing list WireGuard@lists.zx2c4.com https://lists.zx2c4.com/mailman/listinfo/wireguard
Re: Need for HW-clock independent timestamps
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 signature.asc Description: OpenPGP digital signature ___ WireGuard mailing list WireGuard@lists.zx2c4.com https://lists.zx2c4.com/mailman/listinfo/wireguard
Re: Need for HW-clock independent timestamps
Having implemented this solution already, I consider it some type of hack, as the standard time sync unfortunately happens very late in the start of the services, after rc.local called. And the sync might take quite some time. Which means, I had to "hack" the time sync immediately after WAN up, and to be done in a single shot, before starting WG. It might be a reasonable workaround, as a standard new option in openwrt, to allow immediate time sync after WAN up, instead of the graceful sync much later. However, as a real RTC is rather cheap, it might be a good idea, in case of commercial apps, to ask the supplier of the device to be used for the inclusion of a RTC. The more requests, the better the chances to find more devices with RTC included. Toke Høiland-Jørgensen schrieb am So, 13.5.2018: 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. ___ WireGuard mailing list WireGuard@lists.zx2c4.com https://lists.zx2c4.com/mailman/listinfo/wireguard
Re: Need for HW-clock independent timestamps
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 timestamp from peers and to reply to TS requests so long as they are signed with a valid key. Implementing the WG side of a TS exchange would probably be fairly trivial, but I don’t know what is involved to take the received timestamp and use that to set the system clock. That part might present a whole can of worms that Jason may not want to deal with. -Reuben ___ WireGuard mailing list WireGuard@lists.zx2c4.com https://lists.zx2c4.com/mailman/listinfo/wireguard
Re: Need for HW-clock independent timestamps
Axel Neumann 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 ___ WireGuard mailing list WireGuard@lists.zx2c4.com https://lists.zx2c4.com/mailman/listinfo/wireguard
Re: Need for HW-clock independent timestamps
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 signature.asc Description: OpenPGP digital signature ___ WireGuard mailing list WireGuard@lists.zx2c4.com https://lists.zx2c4.com/mailman/listinfo/wireguard
Re: Need for HW-clock independent timestamps
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 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+10 and then only be re-saved (again as new > current_sqn+10) when the last used current_sqn equals the last saved > save_sqn. This way, jumps of at most 10 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 10 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 ___ WireGuard mailing list WireGuard@lists.zx2c4.com https://lists.zx2c4.com/mailman/listinfo/wireguard
Re: Need for HW-clock independent timestamps
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 wrote: > On Sat, May 12, 2018 at 12:07 AM, Axel Neumann 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 > ___ WireGuard mailing list WireGuard@lists.zx2c4.com https://lists.zx2c4.com/mailman/listinfo/wireguard
Re: Need for HW-clock independent timestamps
On Sat, May 12, 2018 at 12:07 AM, Axel Neumann 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
