August 2024 - db-wg - mailman.ripe.net

Force-delete of route object not possible as aut-num resource holder
by Wessel Sandkuijl 04 Sep '24

04 Sep '24

Hi all, RIPE NCC has assigned me an ASN a couple of years ago. During some routine checks I noticed a few route objects with my ASN in it which were created long before the ASN got assigned to me. When trying to force-delete these objects I was unable to. After contacting RIPE NCC this is apparently by design, and RIPE NCC was unable to delete them either because the route objects were protected by a valid maintainer. They suggested I contact the original creator of the objects (which I couldn't, the email bounced), or contact the inetnum resource holder and ask them to (force) delete the route objects. I find it odd that as ASN resource holder I am unable to force-delete objects referencing the ASN that is assigned to me. I'm apparently not the only one. From what I've been told requests from ASN resource holders to delete route objects referencing their ASN pop up regularly in RIPE NCC support. I think this is something that can be improved. I suggest implementing the option to force-delete a route(6) object as ASN resource holder. This saves both the resource holder and RIPE NCC valuable time. Regards, Wessel

11 13

Joke as-set?
by Hank Nussbacher 23 Aug '24

23 Aug '24

Do we condone using the DB for this idiocy? I notice this as-set has since been deleted: as-set: AS200080:AS-KAT-IS-GAY descr: KAT IS ALSO VERY SHORT descr: THIS IS A JOKE AS-SET members: AS13335 members: AS16509 members: AS15169 members: AS36384 members: AS1 members: AS2 members: AS3 members: AS4 members: AS5 members: AS6 members: AS7 members: AS8 members: AS9 members: AS10 members: AS11 members: AS12 members: AS13 members: AS14 members: AS15 ... org: ORG-TA1687-RIPE tech-c: DUMY-RIPE admin-c: DUMY-RIPE mnt-by: T17HOST-MNT created: 2024-08-22T20:18:34Z last-modified: 2024-08-22T20:58:03Z source: RIPE Regards, Hank

3 2

Changes to the RIPE Database Acceptable Use Policy and Daily Limit Accounting
by Edward Shryane 07 Aug '24

07 Aug '24

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-de… 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-… 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-data… Regards, Ed Shryane RIPE NCC

8 26

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

07 Aug '24

Hi, On 8/7/24 9:06 AM, Andreas Härpfer wrote: > >> 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? > > Even a cheap VPS typically gets a whole /64 per host (at least in my > experience). So, the possibility to rotate through IPv6 addresses is > actually cheap, easy, and far from hypothetical. > > From that POV it makes perfect sense to me to block whole /64s and > _not_ bother with individual /128s. > But this is still not a solution for situations where the machines used for scraping personal change rapidly. The attacker with knowledge the AUP limits (which are public) will simply change source /64 with sufficient cadence just as it will change the IPv4 source. This is also a real experience with DDoS attacks that targeted the application. Addresses change so quickly and there are so many source networks that such kind of blocking is essentially ineffective. A real attacker who aims to obtain personal data from RIPE will unsurprisingly proceed similarly. - Daniel

1 0

Phone number requirement for person objects
by Cynthia Revström 06 Aug '24

06 Aug '24

Hi, In the DB-WG interim session I mentioned that there's currently a discrepancy between person objects and role objects with regards to contact information. More specifically, person objects currently require a phone number while role objects require an email address. I think we should try to bring person objects more in line with role objects by removing the phone number requirement. Ideally I would want it to be mandatory to have either a phone number or an email address in order to not lose any flexibility but I'm not sure if that is possible. During the session I asked if anyone was opposed to the idea and no one said they were so I would assume that this is relatively uncontroversial but please let me know what you think. -Cynthia

4 6