Hi, On 8/6/24 6:48 PM, Rob Evans wrote:
I think this could be phrased a little more constructively. > I believe it is pretty common to rate-limit based on the /32 for IPv4 and the /64 for IPv6, this isn’t something the NCC has invented. Personally I think pragmatism might win out against literal interpretation — especially as this doesn’t appear to be something that many users are noticing.
It's from other perspective also an attack vector. Just come to conference with IPv6-enabled network (like RIPEMTG), send large ammount of queries... and everone present will notice this. It's simply a DoS condition. And it can be abused on such places, where many people meet. In most cases, every connected station will not have its own dedicated /64 subnet. They will share single subnet. If you block on IPv4 single host and on IPv6 whole network (LAN) represented by /64, it's only kind of security through obscurity. And no one sane will actually do this if he takes security seriously. And an approach that only disadvantages IPv6. How many times have we witnessed that the initial recommendation in any problem was to turn off IPv6? We really want it this way? If we embrace blocking /64 like this as a great defense, then we will achieve exactly that. Just because each small incident breaks the entire local network from user perspective. Even if the affected user himself is not the cause.
We could have an endless discussion on why IP addresses are locators rather than identifiers, so poor metrics for preventing abuse, but without enforcing a login to query the database, they’re all we’ve got.
It was mentioned - if someone wants to circumvent the rules, they will find a way. Always. But making life easier at server side with the rule "lets block the entire LAN on IPv6" will do more harm than good. And it's just a false feeling of some security. For example - it's easy to run VPS somewhere for a few bucks... using an API calls, perform few queries... detroy it and so on and on. This is a technique that a real attacker will use in practice. Because of course even real attacker knows that some AUP limits exist and will be really motivated to hide his activity. While case rapid address changes within single /64 on IPv6 are hypothetical and speculative. Because it will be quickly visible. Does anyone really think that the attacker wants to be caught quickly?
The AUP states that an individual IP address cannot request > 1,000 personal data sets in 24 hours. It does not state that every IP address can query up to 1,000 personal data sets. In my opinion, that doesn’t prohibit the database from proactively defending itself by blocking a larger related prefix, especially referring to the footnote in the AUP on the basis of ‘reasonable use.'
In particular *real* case, it happened that accesses from one station actually disabled the service for all users of that LAN over IPv6, just due to unfiltered queries passed to grep. It wouldn't happen with IPv4 (as each user in particular LAN has own public IPv4). Affected users around didn't know what was going on, they weren't doing anything wrong. But the discussion about bad design, not about particular issue (it only poited out the problem). And the goal isn't to help scrappers, but the defense must be solved meaningfully, not "simply". The implementation of IPv6 sometimes brings new issues (in this case confusion of terms address / site). Use of IPv6 is still quite small and so similar problems generally don't manifest much. As mentioned above, that "protection" can be in other hand used as an DoS attack. What is better - a non-functioning service or a false feeling that data were protected? (of course they weren't)
The subsequent discussion appears to have two ways forward: 1. Making ‘-r’ the default so personal data is not returned by default. 2. Tweaking the rate limiting so that the /128 is blocked initially, but blocking the /64 if there are more rapid queries from the same /64.
Both of those seem like items that could become NWIs if the DB-WG agrees to them, noting that Ed has commented that the latter could involve a greater amount of work, so other things might have higher priority.
Well, so first we will implement technical nonsense and then we will deal with the complex bureaucracy to solve the problem as it arose? :-) There may be also third option - just stop to offering only personal data after limit this type of query is hit. It will certainly break not so many things. Queries not containing personal data aren't subject of limits (sure. there're some slight limits always). But I myself prefer the option where as little personal data as possible is implicitly returned. In general, in most cases, it is enough to get abuse contact, which also isn't subject of limits. With the current implementation of the limits, we also block access to abuse contacts. Is that really the goal? Sure, it can also be done in another way, but again - it's unnecessary complication. It's not good again. Again we return to the fact that it is better to use IPv4 in order not to risk similar "problems". We're throwing out the baby with the bathwater. IPv6 is the baby here. And the features of IPv6 are used as an argument for making things obscure and sometimes worse than with IPv4. We're inventing theoretical problems to support such obscurities. Actually, we're only adding additional arguments to IPv6 haters. But... why? But it won't solve the problems we want to solve. Here we primarily deal with the protection of personal data. But the real attack vector eludes us. The real problem will not arise from single /64. On the contrary, I think that database scrapping is simply happening and is unnoticed... despite AUP. Sometimes it's good to think about how the attacker would probably do it. Daniel