Changes to the RIPE Database Acceptable Use Policy and Daily Limit Accounting
Dear colleagues, We would like to share some changes to the RIPE Database Acceptable Use Policy and how we implement the daily limit. The Database team will enable these changes from this Thursday, 16 May 2024 onwards. The RIPE NCC Executive Board approved amendments to the "RIPE Database Acceptable Use Policy" (AUP) in March this year, allowing for an additional method of accounting for RIPE Database queries containing personal data. With this method, the count will be based per user, rather than per IP address, for logged-in users. This allows multiple users to share the same public IP address but be accounted for separately. Previously, an office behind a NAT, for example, would get blocked as all users shared the same query limit. This will no longer be the case, as we will count the number of queries per user based on their RIPE NCC Access (single sign-on) accounts, if they are logged in. For users who are not logged in to RIPE NCC Access accounts, the queries will be counted based on IP addresses. Additionally, we found that the daily limit configured in Whois was inconsistent with the AUP. Along with the other changes described above, we will enforce the daily query limit in Whois in line with the Acceptable Use Policy: * Number of personal data sets returned in queries from an IP address – 1,000 per 24 hours * Number of personal data sets returned in queries from a RIPE NCC Access (SSO) account – 1,000 per 24 hours Users who query for personal data above the daily limit will receive the message below explaining what has happened and what to do next: Access from your host has been temporarily denied. For more information, see: https://apps.db.ripe.net/docs/FAQ/#why-did-i-receive-an-error-201-access-den... The minutes from the March meeting of the RIPE NCC Executive Board are available at: https://www.ripe.net/about-us/executive-board/minutes/2024/174th-executive-b... The resolution amending the RIPE Database Acceptable Use Policy is under section 4.6. The updated RIPE Database Acceptable Use Policy is available on our website: https://www.ripe.net/manage-ips-and-asns/db/support/documentation/ripe-datab... Regards, Ed Shryane RIPE NCC
Hi Ed This sounds like a good move. I have 2 questions about the rules. If I query 1000 personal data sets on an IP address, then I log in to my access account, can I query 1000 more? I know this to some extent bypasses the strict rules. But in that office situation you referred to, suppose someone else has queried 1001 objects and got the IP address temporarily blocked. Now I log in to my access account I would expect to have access to 1000 objects. I'll ask you the other question when I see you in Krakow. If I am right I don't want to give people another way to bypass your new rules. Of course nothing changes if you have a block of IPv6 addresses you can still query 1000 personal objects per IP address. Do you still include (non abuse-c) ROLE objects in the count as well as PERSON objects? cheers denis co-chair DB-WG On Tue, 14 May 2024 at 19:48, Edward Shryane via db-wg <db-wg@ripe.net> wrote:
Dear colleagues,
We would like to share some changes to the RIPE Database Acceptable Use Policy and how we implement the daily limit. The Database team will enable these changes from this Thursday, 16 May 2024 onwards.
The RIPE NCC Executive Board approved amendments to the "RIPE Database Acceptable Use Policy" (AUP) in March this year, allowing for an additional method of accounting for RIPE Database queries containing personal data. With this method, the count will be based per user, rather than per IP address, for logged-in users. This allows multiple users to share the same public IP address but be accounted for separately. Previously, an office behind a NAT, for example, would get blocked as all users shared the same query limit. This will no longer be the case, as we will count the number of queries per user based on their RIPE NCC Access (single sign-on) accounts, if they are logged in. For users who are not logged in to RIPE NCC Access accounts, the queries will be counted based on IP addresses.
Additionally, we found that the daily limit configured in Whois was inconsistent with the AUP. Along with the other changes described above, we will enforce the daily query limit in Whois in line with the Acceptable Use Policy: * Number of personal data sets returned in queries from an IP address – 1,000 per 24 hours * Number of personal data sets returned in queries from a RIPE NCC Access (SSO) account – 1,000 per 24 hours
Users who query for personal data above the daily limit will receive the message below explaining what has happened and what to do next:
Access from your host has been temporarily denied. For more information, see: https://apps.db.ripe.net/docs/FAQ/#why-did-i-receive-an-error-201-access-den...
The minutes from the March meeting of the RIPE NCC Executive Board are available at: https://www.ripe.net/about-us/executive-board/minutes/2024/174th-executive-b...
The resolution amending the RIPE Database Acceptable Use Policy is under section 4.6.
The updated RIPE Database Acceptable Use Policy is available on our website: https://www.ripe.net/manage-ips-and-asns/db/support/documentation/ripe-datab...
Regards, Ed Shryane RIPE NCC
--
To unsubscribe from this mailing list, get a password reminder, or change your subscription options, please visit: https://lists.ripe.net/mailman/listinfo/db-wg
Hi Denis,
On 15 May 2024, at 02:40, denis walker <ripedenis@gmail.com> wrote:
Hi Ed
This sounds like a good move. I have 2 questions about the rules.
If I query 1000 personal data sets on an IP address, then I log in to my access account, can I query 1000 more? I know this to some extent bypasses the strict rules. But in that office situation you referred to, suppose someone else has queried 1001 objects and got the IP address temporarily blocked. Now I log in to my access account I would expect to have access to 1000 objects.
You are correct, a user can still query by SSO account if the IP address is temporarily blocked. However, we make a distinction between temporarily blocked (for the rest of the day) and permanently blocked (after repeatedly being blocked on multiple days). (1) If the IP is permanently blocked, we don't allow any queries, either accounting by IP address or by SSO account. (2) If the IP is temporarily blocked, we do still allow queries by SSO account. (3) If the SSO account is temporarily blocked, we allow queries by IP address (if you log out of SSO). But of course you could also switch IP address and continue to query, it's difficult to prevent this if the queries are anonymous. We account by /32 prefix for an IPv4 address and by /64 prefix for an IPv6 address. We added the ability to account by SSO account to support offices behind a NAT address: previously, if one individual gets blocked, the whole office was blocked.
I'll ask you the other question when I see you in Krakow. If I am right I don't want to give people another way to bypass your new rules. Of course nothing changes if you have a block of IPv6 addresses you can still query 1000 personal objects per IP address. Do you still include (non abuse-c) ROLE objects in the count as well as PERSON objects?
Yes we count non abuse-c ROLE objects and PERSON objects as "personal data sets" according to the Acceptable Use Policy. Thanks for your feedback, I hope this clarifies the rules, and we are open to improving them if necessary. Looking forward to seeing you in Krakow and the DB-WG session. Regards Ed Shryane RIPE NCC
cheers denis co-chair DB-WG
On Tue, 14 May 2024 at 19:48, Edward Shryane via db-wg <db-wg@ripe.net> wrote:
Dear colleagues,
We would like to share some changes to the RIPE Database Acceptable Use Policy and how we implement the daily limit. The Database team will enable these changes from this Thursday, 16 May 2024 onwards.
The RIPE NCC Executive Board approved amendments to the "RIPE Database Acceptable Use Policy" (AUP) in March this year, allowing for an additional method of accounting for RIPE Database queries containing personal data. With this method, the count will be based per user, rather than per IP address, for logged-in users. This allows multiple users to share the same public IP address but be accounted for separately. Previously, an office behind a NAT, for example, would get blocked as all users shared the same query limit. This will no longer be the case, as we will count the number of queries per user based on their RIPE NCC Access (single sign-on) accounts, if they are logged in. For users who are not logged in to RIPE NCC Access accounts, the queries will be counted based on IP addresses.
Additionally, we found that the daily limit configured in Whois was inconsistent with the AUP. Along with the other changes described above, we will enforce the daily query limit in Whois in line with the Acceptable Use Policy: * Number of personal data sets returned in queries from an IP address – 1,000 per 24 hours * Number of personal data sets returned in queries from a RIPE NCC Access (SSO) account – 1,000 per 24 hours
Users who query for personal data above the daily limit will receive the message below explaining what has happened and what to do next:
Access from your host has been temporarily denied. For more information, see: https://apps.db.ripe.net/docs/FAQ/#why-did-i-receive-an-error-201-access-den...
The minutes from the March meeting of the RIPE NCC Executive Board are available at: https://www.ripe.net/about-us/executive-board/minutes/2024/174th-executive-b...
The resolution amending the RIPE Database Acceptable Use Policy is under section 4.6.
The updated RIPE Database Acceptable Use Policy is available on our website: https://www.ripe.net/manage-ips-and-asns/db/support/documentation/ripe-datab...
Regards, Ed Shryane RIPE NCC
--
To unsubscribe from this mailing list, get a password reminder, or change your subscription options, please visit: https://lists.ripe.net/mailman/listinfo/db-wg
Hello, On 5/15/24 1:28 PM, Edward Shryane via db-wg wrote:
But of course you could also switch IP address and continue to query, it's difficult to prevent this if the queries are anonymous. We account by /32 prefix for an IPv4 address and by /64 prefix for an IPv6 address.
I think this is bad approach. Why on IPv4 you block only single host, but on IPv6 whole subnet? The argument that the source address can be changed is equally valid for IPv4 and IPv6. But in the case of IPv6, you're blocking the entire subnet with multiple stations, even if only one address is problematic. That's real issue I faced past days - my own script on my workstation hit due to programming error AUP limits. As I use IPv6, whole /64 subnet was blocked and not even colleagues in same subnet could use whois at that time. This would'nt happen with IPv4. This is even not good for promoting IPv6, treat IPv6 differently than IPv4 and in a way (rules) that are actually worse for IPv6. Please review this and treat both IPv4 and IPv6 in the same manner. - Daniel
hi, On Fri, Aug 02, 2024 at 01:24:39PM +0200, Daniel Suchy via db-wg wrote:
On 5/15/24 1:28 PM, Edward Shryane via db-wg wrote:
But of course you could also switch IP address and continue to query, it's difficult to prevent this if the queries are anonymous. We account by /32 prefix for an IPv4 address and by /64 prefix for an IPv6 address.
I think this is bad approach. Why on IPv4 you block only single host, but on IPv6 whole subnet?
The argument that the source address can be changed is equally valid for IPv4 and IPv6.
Not really. Do the math. In v4, even if you change your IP, the amount of addresses a single bad actor has available is always small - while in v6, inside a single /64 subnet, the number of addresses is obviously vastly beyond what you can store in a blocklist. OTOH it would make sense to follow a staged approach here - for the first hit, block the /128, and if there are more than <threshold> hits in a /64, block the whole /64. This would cover "single host errors" while at the same time protecting the RIPE DB from intentional abuse. Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard, Ingo Lalla, Karin Schuler, Sebastian Cler Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279
Hi, On 8/4/24 12:49 PM, Gert Doering wrote:
Not really. Do the math. In v4, even if you change your IP, the amount of addresses a single bad actor has available is always small - while in v6, inside a single /64 subnet, the number of addresses is obviously vastly beyond what you can store in a blocklist.
I do the math. Bad actors - even in SoHo environment - can easily get /48, that means 65k subnets. And bad actor can be of course whole LIRs holding /29... which can be fragmented and distributed around the globe from routing perspective to make identification difficult. Merges and acquisions are complicating this further, and we get to really big numbers, where /64 is only.... a drop in the sea. But still... this is whole LAN segment and we should keep this in our minds. For some reason, NCC decide to start with /64 here, not with /128... and this simply penalizes IPv6 users compared to those who are IPv4-only. That's like throwig out the baby with the bathwater - you always block whole LAN on IPv6, not only single host (happens on IPv4 initially).
OTOH it would make sense to follow a staged approach here - for the first hit, block the /128, and if there are more than <threshold> hits in a /64, block the whole /64.
Yes, that's exactly what I'm looking for. Staged approach, block /128, then /64... and then granularry larger subnets (up to allocation).
This would cover "single host errors" while at the same time protecting the RIPE DB from intentional abuse.
This will be always hard. Motivated bad actors can use for example some short-living machines, many suppliers provide even API for this and sourrce addresses can change really fast... and that's only the first thing that came to mind. I'm not saying not to fight this. In my case, I also missed any notification about "malicious" activity to registered abuse contact. I think this should be part of process in case at least when subnet (more than single host) is blocked. Automatically generated notification is sufficient here. I think is good to know about such issues from network-operator perspective. Even if it will be an opt-in (but I think good operator takes care about similar events in its network). - Daniel
Hi, On Sun, Aug 04, 2024 at 01:46:07PM +0200, Daniel Suchy wrote:
In my case, I also missed any notification about "malicious" activity to registered abuse contact. I think this should be part of process in case at least when subnet (more than single host) is blocked. Automatically generated notification is sufficient here. I think is good to know about such issues from network-operator perspective. Even if it will be an opt-in (but I think good operator takes care about similar events in its network).
Indeed, that sounds like an idea to spend some thoughts on - if the RIPE DB blocks "something" for AUP violation, send "suitable" notifications. Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard, Ingo Lalla, Karin Schuler, Sebastian Cler Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279
Hi Gert, Daniel,
On 4 Aug 2024, at 15:00, Gert Doering <gert@space.net> wrote:
Hi,
On Sun, Aug 04, 2024 at 01:46:07PM +0200, Daniel Suchy wrote:
In my case, I also missed any notification about "malicious" activity to registered abuse contact. I think this should be part of process in case at least when subnet (more than single host) is blocked. Automatically generated notification is sufficient here. I think is good to know about such issues from network-operator perspective. Even if it will be an opt-in (but I think good operator takes care about similar events in its network).
Indeed, that sounds like an idea to spend some thoughts on - if the RIPE DB blocks "something" for AUP violation, send "suitable" notifications.
Is there any action for the abuse contact to take in this situation? I think it is more about educating the end user about why they have been blocked. We already inform the user in the query response why their request has been blocked, and explain in our documentation: https://apps.db.ripe.net/docs/FAQ/#why-did-i-receive-an-error-201-access-den... Very few end users will repeatedly exceed the query limit (i.e. we temporarily block 100's of IPs daily, but permanently block 10-20 IPs, out of millions of source IPs daily). If users can resolve the situation themselves, is there a need to also notify the abuse contact? Regards Ed Shryane RIPE NCC
Hi, the whole problem arises from the fact that you replace the term IP address with end user site. These are two different terms with different meanings. Yes, notification for each IP(v4,v6) address will generated unwanted noise. You can hit whois AUP limits just by programming error and end user will see this and can take corresponding action. I was talking about "escallations" - situations where someone deliberately tries to break through the AUP limits with the aim of scraping the database. A situation where the blocking of not individual addresses is attempted, but the entire subnet (end user site) is blocked. In this case I think infrastructure administrator should also be aware. In this case, the problem is unlikely to correct itself. - Daniel On 8/5/24 11:53 AM, Edward Shryane wrote:
Hi Gert, Daniel,
On 4 Aug 2024, at 15:00, Gert Doering <gert@space.net> wrote:
Hi,
On Sun, Aug 04, 2024 at 01:46:07PM +0200, Daniel Suchy wrote:
In my case, I also missed any notification about "malicious" activity to registered abuse contact. I think this should be part of process in case at least when subnet (more than single host) is blocked. Automatically generated notification is sufficient here. I think is good to know about such issues from network-operator perspective. Even if it will be an opt-in (but I think good operator takes care about similar events in its network).
Indeed, that sounds like an idea to spend some thoughts on - if the RIPE DB blocks "something" for AUP violation, send "suitable" notifications.
Is there any action for the abuse contact to take in this situation? I think it is more about educating the end user about why they have been blocked.
We already inform the user in the query response why their request has been blocked, and explain in our documentation: https://apps.db.ripe.net/docs/FAQ/#why-did-i-receive-an-error-201-access-den...
Very few end users will repeatedly exceed the query limit (i.e. we temporarily block 100's of IPs daily, but permanently block 10-20 IPs, out of millions of source IPs daily).
If users can resolve the situation themselves, is there a need to also notify the abuse contact?
Regards Ed Shryane RIPE NCC
Hi Daniel, Gert,
On 5 Aug 2024, at 14:51, Daniel Suchy <danny@danysek.cz> wrote:
Hi,
the whole problem arises from the fact that you replace the term IP address with end user site. These are two different terms with different meanings.
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-datab... 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. 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? Regards Ed Shryane RIPE NCC
Hi guys Maybe you are asking the wrong questions. What is the purpose of the AUP and is it effective? All it does is catch those who accidentally exceed the 1000 limit on PERSON objects. Those who want to intentionally data mine the RIPE Database will never get blocked. If you include the '-r' flag in your queries you will never get blocked as no personal objects are returned. That allows you to query the entire database without the personal data objects. This can be spread over a 'period of time' to not stand out as making excessive queries. From that data you can extract a list of all nic handles currently active in the database. There are currently about 2m PERSON objects in the database. With a 1000 limit per IP address, you only need 2000 IP addresses to query the whole set of PERSON objects in one day. As long as each IP address only queries 999 PERSON objects they will never trigger the AUP blocking mechanism. So the /64 will never get blocked. There is an anti-avoidance clause in the AUP. For that to be triggered the RIPE NCC has to notice the coordinated action, consider it and take some action. You can query 2m objects long before that will happen. You can even spread it over several days to avoid any anti-avoidance detection. PERSON objects don't change that quickly. There are millions of queries made every day. Would an extra 2m stand out? Unfortunately this type of rate limiting never has and never will work. As I said in my policy proposal on privacy (2022-01) 90% of the personal data contained in the RIPE Database does not need to be there. The answer to this problem is not having so much personal data in the database. Not trying to limit access to what is there unnecessarily. cheers denis On Mon, 5 Aug 2024 at 15:32, Edward Shryane <eshryane@ripe.net> wrote:
Hi Daniel, Gert,
On 5 Aug 2024, at 14:51, Daniel Suchy <danny@danysek.cz> wrote:
Hi,
the whole problem arises from the fact that you replace the term IP address with end user site. These are two different terms with different meanings.
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-datab...
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.
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?
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/
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-datab...
The current system is a design bug, not a compromise. Acceptable Use Policy clearly defines limits per IP address (without distinguishing whether IPv4 or IPv6). Your implementation at this time blocks whole /64 subnet in case of IPv6, not only single address violating AUP.
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.
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. 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
Hello Daniel,
On 6 Aug 2024, at 10:01, Daniel Suchy <danny@danysek.cz> 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-datab...
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
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 <danny@danysek.cz> 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-datab...
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
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 <db-wg@ripe.net> 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
Hello Daniel,
On 6 Aug 2024, at 10:01, Daniel Suchy <danny@danysek.cz> wrote:
Hello,
On 8/5/24 3:32 PM, Edward Shryane wrote:
The current system is a compromise between allowing queries containing
https://www.ripe.net/manage-ips-and-asns/db/support/documentation/ripe-datab...
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
On 8/6/24 3:45 PM, Edward Shryane wrote: personal data, and complying with the Acceptable Use Policy: 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
Using a /64 as the smallest subnet size is a reasonable compromise for
distinguishing whether IPv4 or IPv6). 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
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
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"
IPv6, not only single address violating AUP. per IP address. But the developers probably wanted to make their life easier and implemented the AUP incorrectly. 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/
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 <danny@danysek.cz> 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-datab...
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
Hi,
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).
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. 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. 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.' 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. Cheers, Rob [Speaking for myself, but paying attention because the NCC Services WG was tagged.]
Rob Evans wrote on 06/08/2024 17:48:
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.
the rationale for /64 is that ipv6 privacy addresses will cause the source IP address to change for each successive query, i.e. on a standard SLAAC network, the limit of 1000 person objects per-IP-address-per-day won't apply by default. Applying the rate limit on the entire /64 for ipv6 closes off this rather embarrassing loophole. Does the EB even need to approve text to clarify this? It's a standard and completely reasonable approach to rate-limiting. Nick
Hi, On Tue, Aug 06, 2024 at 06:15:28PM +0100, Nick Hilliard wrote:
Rob Evans wrote on 06/08/2024 17:48:
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.
the rationale for /64 is that ipv6 privacy addresses will cause the source IP address to change for each successive query, i.e. on a standard SLAAC
Uh, when did *this* happen? I see privacy addresses change "every few hours" and "on reconnect", but not for every single connect (tested from MacOS and Linux, curling http://v6only.v6.de/ip.html 10 times in sequence, no change in IPv6 address displayed). If this happens on mobile phones (which are known to do funny things), the point is a bit moot for the discussion here... Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard, Ingo Lalla, Karin Schuler, Sebastian Cler Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279
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
Hi, On Tue, Aug 06, 2024 at 04:23:32PM +0200, Daniel Suchy via db-wg wrote:
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).
We do not micromanage the NCC. We trust them to come up with reasonable decisions for day-to-day business. Sometimes we disagree on what "reasonable" might have been, but then we talk, in (ahem) reasonable terms, and try to bring across our point in friendly and polite form. Your style of discussion leaves room for improvement. Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard, Ingo Lalla, Karin Schuler, Sebastian Cler Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279
Hi Gert,
We do not micromanage the NCC. We trust them to come up with reasonable decisions for day-to-day business.
As a new RIPE NCC EB member I appreciate your trust :)
Sometimes we disagree on what "reasonable" might have been, but then we talk, in (ahem) reasonable terms, and try to bring across our point in friendly and polite form.
And I appreciate this even more! Yes, talking with each other in a friendly and polite way is definitely the recommended approach. Daniel: please respect that not everything can be hard-coded in rules and policies, and respect the people who make judgement calls in good faith. You may not agree with everything, but there is no need to imply malice or stupidity in your feedback. That is not productive, and not ok. When disagreeing with what you observe, please first ask what the reason was for people to make the choices they did, take that feedback seriously, and work together to improve the situation for all involved. That is the way this bottom-up community is supposed to work. Cheers, Sander Disclaimer: I’m speaking as an individual, not on behalf of the board. The standpoints expressed are my own. They only reflect how I as a person see things.
Hello, On 8/7/24 3:30 PM, Sander Steffann wrote:
Daniel: please respect that not everything can be hard-coded in rules and policies, and respect the people who make judgement calls in good faith. You may not agree with everything, but there is no need to imply malice or stupidity in your feedback. That is not productive, and not ok.
When disagreeing with what you observe, please first ask what the reason was for people to make the choices they did, take that feedback seriously, and work together to improve the situation for all involved. That is the way this bottom-up community is supposed to work.
In this case, there was *no* discussion from the bottom before limits were implemented. Aplication of limits to single /64 subnet instead of IP address was not even notified [1], even if we are talking about a relatively fundamental functional difference here. In the announcement [1], theres also clearly stated, that the queries will be counted based on IP addresses (again). AUP talks about IP addresses. There's no mention about subnets, end sites etc. That mental exercise followed my complaint. And we're failing in basic (technical!) terminology here. I was happy with form which was announced on maling list in May. And I was really surprised few days back, when I noticed something else is really implemented. And I tried to solve it first with NCC directly, but without success. The form of my messages may not be perfect - but the primary failure, in my opinion, happened somewhere else. This is not how things are done in the bottom-up driven community. - Daniel [1] https://mailman.ripe.net/archives/list/db-wg@ripe.net/thread/VNZW422LST24X6I...
Hello Daniel,
On 2 Aug 2024, at 13:24, Daniel Suchy via db-wg <db-wg@ripe.net> wrote:
Hello,
On 5/15/24 1:28 PM, Edward Shryane via db-wg wrote:
But of course you could also switch IP address and continue to query, it's difficult to prevent this if the queries are anonymous. We account by /32 prefix for an IPv4 address and by /64 prefix for an IPv6 address.
I think this is bad approach. Why on IPv4 you block only single host, but on IPv6 whole subnet?
We account by smallest end user site, which can be a single user, i.e. /32 for IPv4 or /64 for IPv6.
The argument that the source address can be changed is equally valid for IPv4 and IPv6.
But in the case of IPv6, you're blocking the entire subnet with multiple stations, even if only one address is problematic.
We account for queries on a /64 because that's the smallest size of an end-user site, which could be a single user: https://www.ripe.net/publications/docs/ripe-690/ A downside of accounting more specific than a /64 is that it's straightforward for a user to change their IPv6 address to work around the accounting.
That's real issue I faced past days - my own script on my workstation hit due to programming error AUP limits. As I use IPv6, whole /64 subnet was blocked and not even colleagues in same subnet could use whois at that time. This would'nt happen with IPv4.
This can also happen for IPv4 as we account by /32 prefix size, e.g. a single user or many (NAT) can be behind a single IPv4 address. If a user is temporarily blocked (for the rest of the current day), we do return an error on every subsequent query: ERROR:201: access denied for <IP address> Queries from your IP address have passed the daily limit of controlled objects. Access from your host has been temporarily denied. For more information, see https://apps.db.ripe.net/docs/FAQ/#why-did-i-receive-an-error-201-access-den... The "more information" link explains how to avoid getting blocked in the future, i.e. use the "-r" flag to not receive associated contact information. A user can also contact RIPE NCC support for assistance. We could also change the default behaviour so that referenced objects are not returned, so a user must make a subsequent query for contact information. This change needs discussion and consensus by the community.
This is even not good for promoting IPv6, treat IPv6 differently than IPv4 and in a way (rules) that are actually worse for IPv6.
Please review this and treat both IPv4 and IPv6 in the same manner.
We account the same by smallest end user site, both for IPv4 and IPv6. Regards Ed Shryane RIPE NCC
- 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/
Hi, On Mon, Aug 05, 2024 at 10:27:54AM +0200, Edward Shryane wrote:
We account the same by smallest end user site, both for IPv4 and IPv6.
"end user site" is not really a good metric here. Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard, Ingo Lalla, Karin Schuler, Sebastian Cler Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279
Hi Gert,
On 5 Aug 2024, at 10:43, Gert Doering <gert@space.net> wrote:
Hi,
On Mon, Aug 05, 2024 at 10:27:54AM +0200, Edward Shryane wrote:
We account the same by smallest end user site, both for IPv4 and IPv6.
"end user site" is not really a good metric here.
I see the use of an IPv6 /64 as a compromise to have a reasonably efficient identification of an end user, and also to limit the load on the backend accounting system. Regards Ed Shryane RIPE NCC
Hello, I think your link to ripe-690 is wrong. This document primarily has a different purpose, different audience - as described in introduction. Also, in AUP [1] you talk about limits related to "IP address", not about limits per "user site". So you even don't follow terminology... those are two totally different things. This applies also to FAQ you linked [2], there's nothing like "your colleagues in your LAN performed too many queries" (which is exactly what happens). It seem you use ripe-690 like "each desktop computer obtains /64", but that's not a common use-case for IPv6 addressing. IP address is exactly defined technical term. It's meaning is the same for both IPv4 and IPv6. There's *no* mention about user site in AUP. I have to ask why NCC implements something other than its own docs says? As mentioned by Gert, "end user site" is bad metric here. As has been said already, there's no problem with blocking subnets as an escalation procedure in case of deliberate address changes with the aim of bypassing the AUP. But the first step should be to block IP address (as described in AUP), not blocking whole user site. - Daniel [1] https://apps.db.ripe.net/docs/RIPE-Database-Acceptable-Use-Policy/#limits [2] https://apps.db.ripe.net/docs/FAQ/#why-did-i-receive-an-error-201-access-den... On 8/5/24 10:27 AM, Edward Shryane wrote:
Hello Daniel,
On 2 Aug 2024, at 13:24, Daniel Suchy via db-wg <db-wg@ripe.net> wrote:
Hello,
On 5/15/24 1:28 PM, Edward Shryane via db-wg wrote:
But of course you could also switch IP address and continue to query, it's difficult to prevent this if the queries are anonymous. We account by /32 prefix for an IPv4 address and by /64 prefix for an IPv6 address.
I think this is bad approach. Why on IPv4 you block only single host, but on IPv6 whole subnet?
We account by smallest end user site, which can be a single user, i.e. /32 for IPv4 or /64 for IPv6.
The argument that the source address can be changed is equally valid for IPv4 and IPv6.
But in the case of IPv6, you're blocking the entire subnet with multiple stations, even if only one address is problematic.
We account for queries on a /64 because that's the smallest size of an end-user site, which could be a single user: https://www.ripe.net/publications/docs/ripe-690/
A downside of accounting more specific than a /64 is that it's straightforward for a user to change their IPv6 address to work around the accounting.
That's real issue I faced past days - my own script on my workstation hit due to programming error AUP limits. As I use IPv6, whole /64 subnet was blocked and not even colleagues in same subnet could use whois at that time. This would'nt happen with IPv4.
This can also happen for IPv4 as we account by /32 prefix size, e.g. a single user or many (NAT) can be behind a single IPv4 address.
If a user is temporarily blocked (for the rest of the current day), we do return an error on every subsequent query:
ERROR:201: access denied for <IP address>
Queries from your IP address have passed the daily limit of controlled objects. Access from your host has been temporarily denied. For more information, see https://apps.db.ripe.net/docs/FAQ/#why-did-i-receive-an-error-201-access-den...
The "more information" link explains how to avoid getting blocked in the future, i.e. use the "-r" flag to not receive associated contact information.
A user can also contact RIPE NCC support for assistance.
We could also change the default behaviour so that referenced objects are not returned, so a user must make a subsequent query for contact information. This change needs discussion and consensus by the community.
This is even not good for promoting IPv6, treat IPv6 differently than IPv4 and in a way (rules) that are actually worse for IPv6.
Please review this and treat both IPv4 and IPv6 in the same manner.
We account the same by smallest end user site, both for IPv4 and IPv6.
Regards Ed Shryane RIPE NCC
- 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/
participants (8)
-
Daniel Suchy -
denis walker -
Edward Shryane -
Felipe Silveira -
Gert Doering -
Nick Hilliard -
Rob Evans -
Sander Steffann