Proof of IPv4 address

[bajtos]

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.

[bajtos]

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]

We should consider supporting IPv6 addresses too.

Cross-posting from filecoin-station/spark-api#104 (comment)

We rely on Cloudflare to provide IPv4 access only. This is problematic for two reasons:

1. Cloudflare is pushing for IPv6 adoption. It is not possible to disable IPv6 via the web dashboard, I had to invoke their REST API. I am not sure how long this hack will last.
2. 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 filecoin-station/spark-api#110 (comment)

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:

• Understanding and configuring Cloudflare’s IPv6 support

If this approach does not work, then I'll try the next quick workaround that should be good enough for short term:

• Enable Pseudo IPv4
• https://developers.cloudflare.com/fundamentals/reference/http-request-headers/

[willscott]

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]

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]

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.