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
-----
To unsubscribe from this mailing list or change your subscription options,
please visit: https://mailman.ripe.net/mailman3/lists/db-wg.ripe.net/
As we have migrated to Mailman 3, you will need to create an account with the email matching your subscription before you can change your settings.
More details at: https://www.ripe.net/membership/mail/mailman-3-migration/
