Is there a way to determine the smallest IPv6 prefix one customer can control?

forest

It's easy to find out what prefix a provider has access to (e.g. a /32), but is there any way to determine the prefix that their customers have access to? I can't just assume that two IPs within a /64 belong to the same person, since they might belong to totally different people who are only given an /80 (or even a /128).

There's an anti-DDoS firewall available for Tor, but it uses hardcoded categorizations, for example assuming that any /64 within 2a01:4f8::/32 is controlled by one customer, whereas any /80 within 2607:f1c0::/32 is controlled by one customer. I'm re-implementing this using nftables and would rather not just use hardcoded tables.

For example, let's say I see address 2a0e:bfc0:0:1c::426a and address 2a0e:bfc0:0:1c::36aa. Is there any way to tell (or at least guess) if they belong to the same customer and thus must, for the purpose of DDoS mitigation, be treated as if they were the same IP? Are there any up-to-date lists maintained by 3rd parties?

rpqu

No. It's possible to do statistical analysis, however the easiest way is to social engineer and ask every ISP in existence of their IPv6 allocation to their customer

totally_not_banned

It's probably not feasible to maintain such a list on a general level. There's a lot of IPv6 out there and they can be suballocated at any given level. Even if you know that provider X provides /Y with every server that server might very well host N VPS each getting /Z.

From what i've seen the usual way people deal with this is to just act like everyone follows the /64 recommendation and accept that this might fuck users who weren't lucky enough to actually get a full /64.

aphex

@forest said: whereas any /80 within 2607:f1c0::/32 is controlled by one customer

This also varies however because depending on product the same host ex Cloud https://docs.ionos.com/cloud/network-services/vdc-networking/ip-address/ipv6 /56 or /64, while VPS line is /80

MannDude

@aphex said:

@forest said: whereas any /80 within 2607:f1c0::/32 is controlled by one customer

This also varies however because depending on product the same host ex Cloud https://docs.ionos.com/cloud/network-services/vdc-networking/ip-address/ipv6 /56 or /64, while VPS line is /80

Jeeze, that sounds like a nightmare from an administrative side.

forest

The conundrum I have is that I don't want to block legitimate connections that happen to be within the same subnet. If I treat an entire /64 as a single IP, then all it takes is a few legitimate relays with an /80 in that range, and it would be falsely classified as a DDoS attack. But if I only filter based on the /128, then the system is made completely ineffectual as one person with a /64 could rotate their suffix each time a block is encountered.

This is what I have so far, but it's only for IPv4:

flush ruleset

table inet filter {
        set tor_ddos {
                type ipv4_addr
                flags timeout
                timeout 24h
        }

        set tor_connlimit {
                type ipv4_addr
        }

        define tor_trusted = {
                # snowflake servers
                141.212.118.18,
                193.187.88.42,
                193.187.88.43,
                193.187.88.44,
                193.187.88.45,
                193.187.88.46,
                # directory authorities
                45.66.35.11,
                66.111.2.131,
                128.31.0.39,
                131.188.40.189,
                171.25.193.9,
                193.23.244.244,
                199.58.81.140,
                204.13.164.118,
                216.218.219.41,
                217.196.147.77
        }

        chain tor_input {
                ip saddr $tor_trusted accept
                ip saddr @tor_ddos counter drop
                add @tor_connlimit { ip saddr ct count over 8 } counter drop
                meter tor-ddos-fast { ip saddr timeout 2m limit rate over 8/minute burst 8 packets } add @tor_ddos { ip saddr } counter drop
                meter tor-ddos-slow { ip saddr timeout 1h limit rate over 32/hour burst 32 packets } add @tor_ddos { ip saddr } counter drop
                accept
        }

        chain input {
                type filter hook input priority filter; policy drop;

                iif lo accept
                ct state vmap { established : accept, related : accept, invalid : drop }
                ct state new jump {
                                tcp dport 9001 tcp flags syn jump tor_input
                                tcp dport 22 accept
                }

                icmp type echo-request limit rate 25/second accept
        }

        chain output {
                type filter hook output priority filter; policy accept;
        }

        chain forward {
                type filter hook forward priority filter; policy drop;
        }
}

Each IP is limited to no more than 8 simultaneous connections (anything beyond 8 is dropped), and any IP that tries to connect more than 8 times in a 2 minute period or 32 times in a one hour period is added to a blacklist for 24 hours. Certain trusted IPs are exempt from the filter. But even the original anti-DDoS script for iptables would seem to be vulnerable to a VPS with a /64 that isn't hardcoded to be treated as a single IP.

forest

@totally_not_banned said: From what i've seen the usual way people deal with this is to just act like everyone follows the /64 recommendation and accept that this might fuck users who weren't lucky enough to actually get a full /64.

Are individual people's residential IPs often shoved in the same /64?

rpqu

@yoursunny

totally_not_banned

@forest said:

@totally_not_banned said: From what i've seen the usual way people deal with this is to just act like everyone follows the /64 recommendation and accept that this might fuck users who weren't lucky enough to actually get a full /64.

Are individual people's residential IPs often shoved in the same /64?

That's a good question... I my impression is that residential lines (at least of the big mainstream ISPs) would mostly be at least /64. I figure exceptions are bound to exist somewhere/somehow but if those were overly common people probably wouldn't fall back to acting like they didn't.

aphex

Most residneital ISP give /56 or /64 with the PD from what I'd seen split around down middle in competent major provider. A lot are /56.
Most mobile give /64 per data session without PD and randomly allocated from that /64

Alyx

@forest said:

@totally_not_banned said: From what i've seen the usual way people deal with this is to just act like everyone follows the /64 recommendation and accept that this might fuck users who weren't lucky enough to actually get a full /64.

Are individual people's residential IPs often shoved in the same /64?

Not really something that should happen.

As someone already mentioned, normal residential connections should get a /56, and each network behind the customers router gets a /64 out of this.

However, the IPv6 world is full of admins who do everything they can so they don't need to learn anything new. So you see some pretty stupid setups in the wild.

aphex

@Alyx said: However, the IPv6 world is full of admins who do everything they can so they don't need to learn anything new. So you see some pretty stupid setups in the wild.

I think most of the incompetent ones don't bother with IPv6 in first place

zed

@aphex said:

@Alyx said: However, the IPv6 world is full of admins who do everything they can so they don't need to learn anything new. So you see some pretty stupid setups in the wild.

I think most of the incompetent ones don't bother with IPv6 in first place

honest i'd rather they skip v6 than make up their own rules.

Mainfrezzer

@aphex said:
Most residneital ISP give /56 or /64 with the PD from what I'd seen split around down middle in competent major provider. A lot are /56.
Most mobile give /64 per data session without PD and randomly allocated from that /64

one of my resi isps gives me a /59 while the other does indeed hand out a /56

Motion3549

My isp give me /48

OpaqueRegistrant

If this is for rate limiting, it's normal to set up rate limits at the common levels, which are /64 /56 and /48, but don't make each level 256 times the rate limit of the level below.

forest

@OpaqueRegistrant said:
If this is for rate limiting, it's normal to set up rate limits at the common levels, which are /64 /56 and /48, but don't make each level 256 times the rate limit of the level below.

The problem with doing that for Tor is the potential of allowing an attacker to influence whether or not a legitimate connection is blocked. If an attacker with an /80 in the same /64 as a legitimate user with a /128 attempts a hundred simultaneous connections to cause the entire /64 to get blacklisted, then that legitimate user with the /128 gets kicked off too. That can be used for a variety of attacks (e.g. guard discovery attacks or path-bias attacks). I'd rather not protect my relay against DDoS at the expense of making it an unwitting pawn against its users.