Open bajtos opened 1 year ago
bajtos
commented
1 year ago Ideas from @willscott:
for proof of IP address:
- https://eprint.iacr.org/2021/697 is one approach that can maybe be adapted something around https://oauth.net/2/dpop/ maybe? (or some other variant of oauth?)
- if there’s an open port, use letsencrypt / acme / tls cert issuance in the certificate transparency logs. harder for clients though.
we may need to make a simple protocol for this - i suspect it won’t be too hard
bajtos
commented
11 months ago We should consider supporting IPv6 addresses too.
Cross-posting from https://github.com/filecoin-station/spark-api/pull/104#issuecomment-1776765809
We rely on Cloudflare to provide IPv4 access only. This is problematic for two reasons:
There may be legitimate users that run Stations on IPv6-only networks. We should figure out how to support them.
FWIW, quoting from https://developer.apple.com/support/ipv6/
As of June 1, 2016, all apps submitted to the App Store must support IPv6-only networks.
Cross-posting from https://github.com/filecoin-station/spark-api/pull/110#issuecomment-1776622210
CloudFlare's dashboard does not allow you to disable IPv6 support via web UI and the docs say this feature is available to customers on the Enterprise plan only. Yet the REST API allows me to disable IPv6, as explained here: https://www.mediarealm.com.au/articles/cloudflare-disable-ipv6/
Related docs:
If this approach does not work, then I'll try the next quick workaround that should be good enough for short term:
willscott
commented
11 months ago worth noting that ipv6 addresses don't have a quantifiable cost associated with them in the same way that v4 addresses do. as such, not using v4 as a 'scare resource' means the system will need to have a different answer for how sibyl attacks are mitigated.
bajtos
commented
11 months ago worth noting that ipv6 addresses don't have a quantifiable cost associated with them in the same way that v4 addresses do.
Agreed 👍🏻
as such, not using v4 as a 'scare resource' means the system will need to have a different answer for how sibyl attacks are mitigated.
In our design, we are not using the IPv4/IPv6 address, but a subnet it belongs to.
For IPv4, we use the first three bytes as the subnet.
Is it possible to define an algorithm that will map IPv6 addresses to reasonable groups?
Quoting from Wikipedia:
The address space is assigned to the RIRs in blocks of /23 up to /12.[16] (...) The RIRs assign smaller blocks to local Internet registries that distribute them to users. These are typically in sizes from /19 to /32. (...) The addresses are then typically distributed in /48 to /56 sized blocks to the end users.
Let's say for home users, we take the first 48 bits of their address as the subnet (the scarce resource). Would that work?
IPv6 addresses are assigned to organizations in much larger blocks as compared to IPv4 address assignments — the recommended allocation is a /48 block
If we treat the first 48 bits of the IPv6 address as the subnet (the scarce resource), then we will treat all computers in an organisation like the above as a single node operator 🤔
OK, this approach clearly needs more research on the feasibility.
Looking for a different mitigation strategy agains sibyl attacks is definitely an alternative to consider too.
willscott
commented
11 months ago it doesn't really work - an initial free allocation that an un-resourced adversary could get for ~$1000 is a /19 as you mention.
as such, if you use a 48 bit subnet as a prefix, then that means it's easy to pretend to be 2^(48-19) ~~ 500 million distinct subnets. that multiplier isn't great.
ETA: 2024-06-30
We want to use IPv4 addresses of SPARK nodes as the scarce resource that makes it expensive for a single party to run many nodes. ATM, we rely on the trusted spark-api service to record the node's IPv4 address. In the longer term, we want to move to a trust-less model and thus require proof of the node's IPv4 address.