Hi Daniel, I am replying here as Ed has just left for a well-deserved holiday break.
I think the others have summarised our position well, so I’ll try to avoid re-stating too much of what has already been already said. Much of your objection argues we should take a “letter of the law” approach to the AUP rather than basing our implementation on the spirit of what it’s trying to achieve. You are entirely correct that the document refers to IP addresses and a /64 is not an IP address. However, it seems the community is broadly okay with our implementation (which can always be discussed and revised later if needed). We will review the AUP to see if it needs clarifying. I take your point that we don’t want to make IPv6 a second-class experience and agree with this principle, though we need to be pragmatic. As already noted, blocking at the /128 level makes this limit trivial to circumvent and introduces other complications. A phased approach starting with /128 before moving to /64 is better, but here we must point out that this will involve considerable work for little real benefit, especially when this affects so few people and we have other priorities. And even then this doesn’t address the more common problem of people hitting this limit accidentally. This is why we are suggesting the WG consider whether personal data should be returned by default. This likely would have avoided the issue that affected you and it seems more impactful than reworking our accounting software. If there is interest in this approach, we would like to ask the DB WG to come up with a problem statement so we can look at addressing it. Kind regards, Felipe Victolla Silveira Chief Technology Officer RIPE NCC On Tue, 6 Aug 2024 at 16:23, Daniel Suchy via db-wg <[email protected]> wrote: > Hello, > this discussion is annoying and in the circle. You're still trying to > give the term "IP address" a different meaning than it has. IP address > is IP addres. Period. It's not a subnet of any size, as you're trying to > say. > > AUP clearly talks about IP address, not about end-user site etc. You put > that in there arbitrarily. You are trying to give a strange > interpretation of a standard technical term, which, however, has a > clearly defined meaning. > > To defend yourself, you're thinking of hypothetical scenarios. But these > can similarly occur with both IPv4 and IPv6. But as as a result, using > IPv6 is a disadvantage now, you artificially penalize IPv6 more than > IPv4. I can have IPv4 LAN with /24 and I'll no face any issue, but I'll > have on LAN even with /64 IPv6. It's just stupid what you're doing. In > fact, what the NCC tells us here is to turn off IPv6 and we'll be fine. > > > And as it was already mentioned by Denis at db-wg, there're much more > ways to scrap personal data if someone really wants to do that. But your > pseudo-protection code is only throwing the baby out with the bath > water. And create unnecessary problems for users on IPv6, thanks to > developers incompetence (or laziness?). > > I understand, some employees and RIPE NCC doesn't understand IPv6 basics > and make no difference between IP address and IP subnet (site). But > there's a difference. Again. IPv6 address has 128 bits, not 64 bits, > which NCC staff uses for AUP accounting. > > > > I raise question to services WG: > > How it's possible that an employees of RIPE NCC interprets standard > terminology in such strange way and bends the written rules in the > direction they are not written? > > Who approved the blocking of the entire subnet, when even AUP exactly > says that IP addresses should be blocked in case of violation? Who is > responsible for this creativity? > > > I would like to hear the answers, because it seems that there is anarchy > in NCC and the developers implements what they want, not what they > should (with respect to published rules/documents). > > > > - Daniel > > > > On 8/6/24 3:45 PM, Edward Shryane wrote: > > 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 > > > ----- > 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/
----- 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/
