Hello Daniel,
On 6 Aug 2024, at 10:01, Daniel Suchy <[email protected]> wrote:
Hello,
On 8/5/24 3:32 PM, Edward Shryane wrote:
The current system is a compromise between allowing queries containing personal
data, and complying with the Acceptable Use Policy:
https://www.ripe.net/manage-ips-and-asns/db/support/documentation/ripe-database-acceptable-use-policy/
The current system is a design bug, not a compromise.
It was a deliberate choice to account by /64 prefix size for IPv6 (the smallest
subnet size) and /32 for IPv4 (the smallest prefix size). While it’s true that
an IPv6 end user site could contain multiple users, this is the same for IPv4
where you could have a single public NAT address with many users behind it.
However, within an IPv6 /64 end user site, the user is free to configure their
global address. If we account for greater than a /64 then it becomes trivial
for a user to change their host address and avoid the limit accounting.
Changing the accounting to limit both by /128 and /64 prefixes complicates the
implementation and operation of the system and the user must still comply with
the AUP daily limit of 1,000 objects (it’s just harder to identify them).
To avoid getting blocked, a user (one or many) must reduce the queries for
objects containing personal information, no matter how the accounting is done.
Acceptable Use Policy clearly defines limits per IP address (without
distinguishing whether IPv4 or IPv6).
Using a /64 as the smallest subnet size is a reasonable compromise for the
implementation, given the huge address space and how trivial it is to change
host address, to avoid the accounting. Furthermore, if we account for every
single /128 address, this would allow malicious actors to DDoS the accounting
by simply sending each query from a new, different IPv6 address.
Your implementation at this time blocks whole /64 subnet in case of IPv6, not
only single address violating AUP.
See above. A single user can be assigned a whole /64 subnet.
The limit is 1,000 objects that could contain personal data, which is not normally
reached by most users (< 0.02%), and it is clear what can be done if this is
exceeded.
The limit value isn't problem as well as limiting the number of queries per IP
address. But the developers probably wanted to make their life easier and
implemented the AUP incorrectly.
Blocking entire subnets as an initial reaction simply isn't the spirit of AUP. IPv6
address has 128 bits, not only 64 you're using - whatever the "reason" is.
We do not want to make it easier to avoid the AUP limit.
Rather than re-write the accounting code, can the community review why objects containing
personal data is returned by default? Can we make "-r" the default?
If code contains bug (and that's now quite clear), it needs to be fixed
regardless of the data returned with the default settings.
Again, there was a deliberate decision to account by /64 and it’s not an
implementation bug.
I personally don't consider as a bad idea not to display personal data at all (have "-r"
as default), it's important that the abuse contact is always displayed (and it is, even with
"-r"). But that's different topic.
- Daniel
Changing the accounting implementation does not fix the root cause in terms of
why users are getting blocked. By default, RIPE Database queries are returning
referenced personal data that the user did not ask for. Rather than change the
accounting, we can change the default query behaviour. Users should be
accountable for the personal data that they requested.
In conclusion, there are good reasons for the current implementation, but if
there is consensus for reviewing how AUP accounting is done, then we will
prioritise it.
Regards
Ed Shryane
RIPE NCC
