- ncc-services-wg - mailman.ripe.net

RIPE NCC Services WG at RIPE 89
by Rob Evans 03 Sep '24

03 Sep '24

Dear all, We are about eight weeks away from RIPE 89 in Prague. If you have any topics you'd like to present at the NCC Services Working Group on Wednesday afternoon, please let the WG chairs know via <ncc-services-wg-chairs(a)ripe.net <mailto:ncc-services-wg-chairs@ripe.net>>. A reminder that Bijal’s term is up at RIPE 89 and we are looking for a new co-chair. If you are interested, please feel free to speak to any of us, and have a look at the following resources ahead of opening the call for volunteers: RIPE NCC Academy: RIPE Working Group Chair Training https://academy.ripe.net/enrol/index.php?id=16#section-1 A Guide for New RIPE Working Group Chairs https://www.ripe.net/publications/docs/ripe-765/ RIPE Working Group Chair Job Description and Procedures https://www.ripe.net/publications/docs/ripe-692/ Mailing List Guidelines for RIPE Working Group Chairs https://www.ripe.net/publications/docs/ripe-764/ Cheers, Rob On behalf of your friendly WG co-chairs — Bijal, Janos, Rob

1 0

Re: [db-wg] Changes to the RIPE Database Acceptable Use Policy and Daily Limit Accounting
by Daniel Suchy 07 Aug '24

07 Aug '24

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(a)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-data… >> >> 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 >

2 1

Re: [db-wg] Changes to the RIPE Database Acceptable Use Policy and Daily Limit Accounting
by Daniel Suchy 07 Aug '24

07 Aug '24

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(a)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-data… >> >> 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 >

6 9

Minutes from the NCC Services WG meeting at RIPE 89
by Rob Evans 12 Jul '24

12 Jul '24

Hi, With thanks to Antony Gollan from the RIPE NCC, the draft minutes from our meeting at RIPE 88 are here: https://www.ripe.net/community/wg/active-wg/services/minutes/ripe-ncc-servi… Please let us know of any errors or omissions, and we will get them rectified before we approve the minutes formally at RIPE 89. I’d like to remind the working group that we will have a selection process for a new co-chair at RIPE 89, and encourage potential candidates to speak to one of the current co-chairs if you want to know what the role entails. Cheers, Rob

1 0

Mailing Lists Migration from Mailman 2 to Mailman 3
by Timour Bakeev 02 Jul '24

02 Jul '24

Dear colleagues, In response to the community concerns regarding using the outdated Mailman 2 software for the RIPE mailing lists, RIPE NCC is starting the migration process to the Mailman 3 software suite. This upgrade will enhance the user interface and message archives for these lists. We expect to complete this work by 14 July 2024. Previously, we successfully updated our internal mailing lists to Mailman 3 and the ASO and NRO mailing lists, containerising them in the process. This latest migration extends those improvements to these external mailing lists as well. What will change? Mailman 2 and Mailman 3 are entirely different products, which brings some changes in the observed behaviour. - The location of the email archives. The new address of the archive will be: https://mailman.ripe.net/archives/list/{list-name}@ripe.net/ - The subscription address will be changed to {list-name}-join(a)ripe.net - To maintain historical links to the archives, we’re planning to turn this into a static website at: https://lists.ripe.net/ The mail delivery process for the existing subscribers will not change, so they will continue to receive emails from the lists as usual, with a potential one-time delay of up to four hours during the actual transition. The interaction with the server is also going to remain the same. Thank you for your understanding and cooperation. Kind regards, Timour Bakeev Senior System Engineer RIPE NCC

1 0

Changes to the Navigation on www.ripe.net
by Ulka Athale 01 Jul '24

01 Jul '24

Dear colleagues, Following the redesign of ripe.net, we are also working on improving the ease of access to our content. We have made some changes to the navigation menus of the website. The main changes are: - "Events" has been added as a section to the top-level navigation of the menu - "Participate" has been renamed "Membership" - The Policy Development and Internet Governance pages can now be found under "Community" You can read about these changes and other improvements planned for the website in more detail on RIPE Labs: https://labs.ripe.net/author/ulka_athale_1/a-click-away-improving-navigatio… All existing links and URLs should continue to work. If you do see any broken links, please let us know. We also welcome your input about content that you would like to access more easily or other improvements via the forum: https://forum.ripe.net/t/improving-the-navigation-on-ripe-net/1026 Kind regards, Ulka Athale -- Ulka Athale Senior Communications Officer RIPE NCC www.ripe.net

1 0

RIPE NCC Quarterly Planning Q3 2024
by Adonis Stergiopoulos 27 Jun '24

27 Jun '24

Dear colleagues, We have now published the Q3 2024 quarterly plans for our development teams: https://www.ripe.net/support/documentation/quarterly-planning These plans include the work items that will be carried out over the next quarter and give you the chance to provide your feedback and suggestions that the RIPE NCC should be working on going forward. The plans cover the following areas: - RIPE Database - Business Applications, including the LIR Portal, Registry Services and other applications. - DNS and K-root - RIPE Atlas - RIPEstat - Resource Public Key Infrastructure (RPKI) - Routing Information Service (RIS) - Information Security, Risk, and Compliance - Training and Certification Please share your suggestions on this list or the RIPE NCC Forum: https://forum.ripe.net/ Kind regards, Adonis Stergiopoulos Senior Marketing & Communications Officer RIPE NCC

1 0

Two-Factor Authentication for RIPE NCC Access Using Passkeys
by Felipe Silveira 31 May '24

31 May '24

Dear colleagues, Two-factor authentication (2FA) was made mandatory for all RIPE NCC Access accounts in March earlier this year, and we received many requests to use security keys as an authentication method. You can now use passkeys as a two-factor authentication method for RIPE NCC Access accounts, in addition to authenticator apps. Passkeys can be stored on an hardware security key (FIDO2 compatible) or in a password manager, potentially synced across devices. They are supported on mobile devices (iOS, Android) and by most browsers on computers. If you have any feedback, please contact us at ncc(a)ripe.net Kind regards, Felipe Victolla Silveira Chief Technology Officer RIPE NCC

2 1

Exit Strategy for Cloud Services
by Felipe Silveira 31 May '24

31 May '24

Dear colleagues, First of all, I would like to thank you all for the engaged discussions and feedback received during RIPE 88 last week. Following up on some of the questions raised during my presentation last week, I would like to clarify a couple of points, mostly around RIPE NCC’s exit strategy for our cloud providers. First point raised was concerning the exit cost for AWS S3 should we decide to move to a different provider, potentially at very short notice. As part of the AWS S3 pricing model, a certain amount is charged for egress costs. Due to the large amount of data we have stored in AWS (in the order of petabytes of uncompressed data), this could potentially lead to a large bill. However, following the direction set by the European Data Act, AWS decided to waive all egress fees for customers migrating their data to a competitor (or to on-premise): https://aws.amazon.com/blogs/aws/free-data-transfer-out-to-internet-when-mo… However, even in a partial exit scenario, where we decide to stay with AWS but move only one service out, and thus egress costs waiving would not apply, the S3 exit cost for the Atlas historical data would be in the order of a few thousand euros. The other point raised was about our exit strategy in general, not only referring to egress costs. Our strategy is to use industry standards (e.g. Kubernetes) as a way to mitigate switching costs, as many providers offer alternative solutions. That is true for both AWS S3 and Kubernetes, having similar solutions offered by other companies. We also pay very close attention to our backup strategy (e.g. having the data stored elsewhere) and diversifying our suppliers. If you have any questions, please do not hesitate to contact me. Kind regards, Felipe Victolla Silveira Chief Technology Officer RIPE NCC

1 0

RIPE Labs: Reflections on Six Months as Chief Registry Officer
by James Kennedy 17 May '24

17 May '24

Dear colleagues, I have published a new RIPE Labs article reflecting on my first six months as Chief Registry Officer: https://labs.ripe.net/author/james-kennedy/reflections-on-six-months-as-chi… In the article, I explore the changing environment and how some of the associated pressures are affecting our Registry Department. I also look at the impact of the increased volume of End User ASN requests and provide some numbers on our overall workload. Any feedback or questions are welcome. However, please note that ASN related discussions are probably best held on the Address Policy WG mailing list, where I have also shared this article. Kind regards, James Kennedy Chief Registry Officer RIPE NCC

1 0