March 2021 - db-wg - mailman.ripe.net

Cleanup of route(6) objects in the RIPE NONAUTH database using unregistered space
by Edward Shryane 20 Apr '21

20 Apr '21

Dear colleagues, In response to the recent discussion on "196.52.0.0/14 revoked, cleanup efforts needed", I'd like to propose a regular automated cleanup of route(6) objects in the RIPE-NONAUTH database using unregistered space. Regards Ed Shryane RIPE NCC Problem Definition ------------------ When an RIR deregisters IPv4/IPv6 address space, any route(6) objects in the RIPE-NONAUTH database using that address space are not cleaned up (deleted). Solution Definition ------------------- Once a day, compare route(6) IPv4/IPv6 prefixes in the RIPE-NONAUTH database against the combined delegated stats from all RIRs. Only route(6) prefixes that are "allocated" or "assigned" in any RIRs delegated stats should remain in the RIPE NONAUTH database. If a prefix is "available" or "reserved" then it is considered to be unregistered, and any associated route(6) objects will be eligible for deletion. If a prefix is partially "available" or "reserved" then it is also considered to be unregistered. If a prefix is not listed in any RIRs delegated stats, that prefix is skipped. The origin AS status is not considered, only the IPv4/IPv6 prefix. If a newly unregistered prefix is discovered, first allow a grace period of 1 week. This allows time for mistakes in the delegated stats to be corrected. After 1 week, contact the route(6) maintainer(s) to notify them that the route(6) object will be deleted. After a further 2 weeks, delete the route(6) object. A maintainer can request the RIPE NCC to exclude a route(6) prefix from deletion (for example, the deregistration of the prefix is being disputed). For any excluded prefixes, any associated route(6) objects will not be deleted. Impact Analysis ------------------ There are approximately 738 routes (out of 56,230) in the RIPE-NONAUTH database using a prefix with status "available" or "reserved" in an RIRs delegated stats, which will be eligible for deletion. There are approximately 94 route6's (out of 1,564) in the RIPE-NONAUTH database using a prefix with status "available" or "reserved", so also eligible for deletion. There are approximately 64 routes and 37 route6's with a prefix not listed in any RIR's delegated stats. These will not be affected. When this cleanup is implemented, the backlog of route(6) objects eligible for deletion will be processed at the same time, leading to a large amount of emails to affected maintainers. Once this backlog is processed, the number of route(6) objects affected is expected to be low.

2 1

Re: [db-wg] Cleanup of route(6) objects in the RIPE NONAUTH database using unregistered space
by Edward Shryane 31 Mar '21

31 Mar '21

Hi Cynthia, Thanks for your support, my proposal is to automatically delete route(6) objects using de-registered prefixes from the NONAUTH database. For example, this would apply to the routes using the revoked 196.52.0.0/14 prefix which was discussed in January. If there is no objection from the DB-WG, I'd like to turn this proposal into a Numbered Work Item. Regards Ed Shryane RIPE NCC > On 31 Mar 2021, at 07:36, Cynthia Revström <me(a)cynthia.re> wrote: > > Hi Ed, > > I am not sure if this was something to discuss or just something you wanted to mention. > > Anyways as I saw this while looking through older emails, this sounds like a good idea to me. > > -Cynthia > > On Thu, Mar 11, 2021, 15:07 Edward Shryane via db-wg <db-wg(a)ripe.net <mailto:db-wg@ripe.net>> wrote: > Dear colleagues, > > In response to the recent discussion on "196.52.0.0/14 <http://196.52.0.0/14> revoked, cleanup efforts needed", I'd like to propose a regular automated cleanup of route(6) objects in the RIPE-NONAUTH database using unregistered space. > > Regards > Ed Shryane > RIPE NCC > > > > Problem Definition > ------------------ > When an RIR deregisters IPv4/IPv6 address space, any route(6) objects in the RIPE-NONAUTH database using that address space are not cleaned up (deleted). > > > Solution Definition > ------------------- > Once a day, compare route(6) IPv4/IPv6 prefixes in the RIPE-NONAUTH database against the combined delegated stats from all RIRs. > > Only route(6) prefixes that are "allocated" or "assigned" in any RIRs delegated stats should remain in the RIPE NONAUTH database. If a prefix is "available" or "reserved" then it is considered to be unregistered, and any associated route(6) objects will be eligible for deletion. > > If a prefix is partially "available" or "reserved" then it is also considered to be unregistered. > > If a prefix is not listed in any RIRs delegated stats, that prefix is skipped. > > The origin AS status is not considered, only the IPv4/IPv6 prefix. > > If a newly unregistered prefix is discovered, first allow a grace period of 1 week. This allows time for mistakes in the delegated stats to be corrected. > > After 1 week, contact the route(6) maintainer(s) to notify them that the route(6) object will be deleted. > > After a further 2 weeks, delete the route(6) object. > > A maintainer can request the RIPE NCC to exclude a route(6) prefix from deletion (for example, the deregistration of the prefix is being disputed). For any excluded prefixes, any associated route(6) objects will not be deleted. > > > Impact Analysis > ------------------ > There are approximately 738 routes (out of 56,230) in the RIPE-NONAUTH database using a prefix with status "available" or "reserved" in an RIRs delegated stats, which will be eligible for deletion. > > There are approximately 94 route6's (out of 1,564) in the RIPE-NONAUTH database using a prefix with status "available" or "reserved", so also eligible for deletion. > > There are approximately 64 routes and 37 route6's with a prefix not listed in any RIR's delegated stats. These will not be affected. > > When this cleanup is implemented, the backlog of route(6) objects eligible for deletion will be processed at the same time, leading to a large amount of emails to affected maintainers. Once this backlog is processed, the number of route(6) objects affected is expected to be low. > > >

1 0

Re: [db-wg] db-wg Digest, Vol 113, Issue 1
by Tyrasuki 25 Mar '21

25 Mar '21

I approve implementation of this, and already use geofeeds in "remark" attributes. I've not seen much movement about this in a while so i think it might be a good idea to bring up again. Has there been any further discussion anywhere about this? \- Jori (Tyrasuki) \-------- Original Message -------- On Jan 4, 2021, 4:18 AM, < db-wg-request(a)ripe.net> wrote: > > > > Hi Job and db-wg, > > > > > I just want to start out by saying that I think this is a very worthwhile endeavour IMO, and thank you Job for reminding me of this thread. :) > > > > > I have also written some opinions about your questions and ideas below, and I would like to hear some input from people on the WG as this is sort of my initial thoughts but have not been thoroughly considered. > > > > > > Why not use the RPKI to distribute geofeed information? > > > > > I think using RPKI for this will make it needlessly complicated for people to use. I think we want to make this as simple as possible for someone to find. > > > > > To me it seems like it might be a good idea to add it as an attribute in the RIPE DB and then additionally having some like the HTTP API for finding abuse contacts but for geofeed ( https://github.com/RIPE-NCC/whois/wiki/WHOIS-REST-API-abuse-contact ). > > > > > > What downsides/risks/challenges down the road might exist? > > > > > As I noted in the comment above, I think the main challenge will be to make it simple and basic enough to implement for people wanting to publish geofeed URLs and people wanting to fetch geofeed URLs. > > I think having a basic HTTP JSON API to get this URL would really help with implementation as it would be really easy for data consumers to query for the URL and not have to parse WHOIS data or read RDAP RFCs or whatever. > > > > > Additionally, WHOIS is not encrypted/authenticated (which HTTPS/TLS is) and as such while the risk for malicious activity here might be low, I think having it authenticated would help (as in making sure you get the URL that the resource holder provided, not that the data in there is necessarily correct). > > > > > I think that if this is implemented, only HTTPS urls should be allowed, as in no plain text HTTP. (I don't have very strong feelings but it seems reasonable to me) > > > > > And on the note of the main challenge, I also think a part of making it simple to implement is to try to have the same API for this between all of the RIRs, because I don't think this will really succeed if only RIPE NCC has it. > > I think that if the RIPE NCC implements this, the next step will be to try to coordinate this with other RIRs so it can be a workable system for all RIRs. > > > > > > Will this be the final and full solution to GeoIP challenges? > > > > > I would say that this is probably not something that can easily be figured out other than by implementing it and waiting for a few years. > > > > > > Have any of the GeoIP aggregators/vendors responded to the 'geofeed:' initiative? What do the likes of amazon/google/maxmind think of the format? > > > > > I am also very curious about this, in particular to what the people wanting to use this data think of it (aka google, amazon, etc). > > I don't think maxmind is likely to approve of it as it basically destroys their product if successful. > > > > > Additionally I think this would be quite useful if it succeeded as if I recall correctly, the BBC uses the delegated list files on [ftp.ripe.net][] for GeoIP. > > This sort of became problematic when the whole delegated list file country code has to correspond to legal address thing happened, as this broke for some cases. > > > > > \- Cynthia > > > > > > > > On Sun, Jan 3, 2021 at 7:30 PM Job Snijders via db-wg <[db-wg(a)ripe.net][db-wg_ripe.net]> wrote: > > > > Dear DB-WG chairs, > > > > Today an acquaintance (who works at an ISP) reached out to me describing > > some annoying Geo IP location issues they were facing. > > > > I thought to myself "didn't we have a solution to such issues?" and was > > reminded of this thread. > > > > Chairs, how do we proceed to work towards the deployment of this new > > RPSL 'geofeed:' attribute? What is the next step? > > > > strawman problem statement for NWI process: > > > > "Associating an approximate physical location with an IP address > > has proven to be a challenge to solve within the current constraints > > of the RIPE database. Over the years the community has choosen > > to consider addresses in the RIPE database to relate to entities in > > the assignment process itself, not the subsequent actual use of IP > > addresses after assignment. > > > > The working group is asked to consider whether the RIPE database can > > be used as a springboard for parties wishing to correlate > > geographical information with IP addresses by allowing structured > > references in the RIPE database towards information outside the RIPE > > database which potentially helps answer Geo IP Location queries." > > > > Outstanding questions to the group & authors of the geofeed draft: > > > > \- What would the RDAP integration look like? (as per George: ideally > > WHOIS and RDAP stay aligned) > > \- Why not use the RPKI to distribute geofeed information? > > \- What downsides/risks/challenges down the road might exist? Will > > this be the final and full solution to GeoIP challenges? > > \- Have any of the GeoIP aggregators/vendors responded to the > > 'geofeed:' initiative? What do the likes of amazon/google/maxmind > > think of the format? > > > > Kind regards, > > > > Job > > > > [ftp.ripe.net]: http://ftp.ripe.net [db-wg_ripe.net]: mailto:db-wg@ripe.net

2 1

Time for new Announcements?
by Fergal Cunningham 25 Mar '21

25 Mar '21

Hi Marcel, all, Another forum you might want to explore is your local network operators group (NOG). There are 25-30 in our service region and lots more globally, and these are generally good places to connect with operators close to you on all manner of things. I would say they carry out a similar role to RIPE but on the national or even city level. And the discussions can be more specific than on the RIPE lists and might even be in your native language. They do a lot of good work. We have a pretty comprehensive list on RIPE Labs - https://labs.ripe.net/nogs - with links to the NOGs' webpages. All the best, Fergal Cunningham RIPE NCC

1 0

Time for new Announcements?
by Marcel Zimmer 13 Mar '21

13 Mar '21

Good morning dear community, it is an honor to be part of it :) We have applied for and been assigned our own AS at the beginning of the year (AS212033). Since yesterday the link to the first peering partner Lumen (AS3356) is available and the following networks should be announced: IPv4 193.3.45.0/24 IPv6 2a10:5dc0::/32 the corresponding routing objects sid created - so far so good :) Now yesterday I could observe the following: The first routers processed quite fast the Ipv4 routes and yesterday evening we had the following picture while looking glass of the Ipv4 and ipv6 network. https://www.bilder-upload.eu/bild-4a9957-1615622772.png.html https://www.bilder-upload.eu/bild-296f5c-1615622785.png.html Since then, somehow nothing happens. Do you have a tip for me where I should go troubleshooting? Greetings Marcel Zimmer

4 3

Webupdates UI bug?
by Cynthia Revström 11 Mar '21

11 Mar '21

Hi DB-WG, When creating a new object via webupdates, it selects IRT objects too in addition to the maintainers that are connected to the SSO account. This ofc doesn't work, and you just get an error, but it might be somewhat confusing and should probably be fixed. -Cynthia

2 4

Forcing two-factor authentication for maintainer
by Antti Ristimäki 01 Mar '21

01 Mar '21

Hi list, Is it possible or could it be possible to force two-factor authentication for RIPE Access SSO accounts that are being referenced from a maintainer object? Given that many critical objects are protected by a maintainer, I would find it very convenient to be sure that every single SSO account that can be used to authenticate against the maintainer object, are properly secured. Antti Ristimäki CSC/Funet

2 1