Re: [db-wg] Getting fraudulent entries removed
On 4/5/2018 2:27 PM, Nick Hilliard via db-wg wrote: Randy Bush via db-wg wrote: and we are supposed to use the high quality ripe irr as authoritative data for routing validation? the current plan is to re-mark all out-of-region route / route6 / autnum objects with source: RIPE-NONAUTH and to disable creation of these objects in future. Unless something has been missed, this should be an improvement over the current situation? Nick Is there going to be a cleanup process for existing entries? For example: https://apps.db.ripe.net/db-web-ui/#/query?bflag&inverse=mnt-by&searchtext=ADMASTER-MNT&source=RIPE&types=route route: 104.143.112.0/20 Not currently advertised, belongs to a managed services provider in the US: https://whois.arin.net/rest/net/NET-104-143-112-0-1/pft?s=104.143.112.0 route: 141.193.96.0/19 Not currently advertised. ARIN claims this belongs to RIPE: https://whois.arin.net/rest/net/NET-141-0-0-0-0 RIPE claims this belongs to... someone else? https://apps.db.ripe.net/db-web-ui/#/query?searchtext=141.193.96.0 route: 192.73.128.0/18 Currently advertised by 30237 ARIN says this belongs to the US Air Force https://whois.arin.net/rest/net/NET-192-73-82-0-1 It largely looks like all of these route objects created by ADMASTER-MNT are (or have been) used for hijacking mostly unused ARIN space.
Re: [db-wg] Getting fraudulent entries removed
>> and we are supposed to use the high quality ripe irr as authoritative >> data for routing validation? > > the current plan is to re-mark all out-of-region route / route6 / > autnum objects with source: RIPE-NONAUTH and to disable creation of > these objects in future. Unless something has been missed, this > should be an improvement over the current situation? peval() does not look at source:. and thanks, don't tell a whole lot of folk to change software. and you know that the point of my snark is that there are more authoritative data available. randy
Re: [db-wg] Getting fraudulent entries removed
Randy Bush via db-wg wrote: > and we are supposed to use the high quality ripe irr as authoritative > data for routing validation? the current plan is to re-mark all out-of-region route / route6 / autnum objects with source: RIPE-NONAUTH and to disable creation of these objects in future. Unless something has been missed, this should be an improvement over the current situation? Nick
Re: [db-wg] Getting fraudulent entries removed
> We're back to this again... more of our space is being hijacked using > a RIPE IRR entry: > > route: 108.160.128.0/20 > descr: 2nd route > origin: AS19529 > mnt-by: ADMASTER-MNT > created: 2017-11-15T17:41:46Z > last-modified: 2017-11-15T17:41:46Z > source: RIPE > > Same ASN. > > Can RIPE purge all the IRR entries created by this maintainer? They > don't appear to be legitimate. and we are supposed to use the high quality ripe irr as authoritative data for routing validation?
Re: [db-wg] Getting fraudulent entries removed
We're back to this again... more of our space is being hijacked using a RIPE IRR entry: route: 108.160.128.0/20 descr: 2nd route origin: AS19529 mnt-by: ADMASTER-MNT created: 2017-11-15T17:41:46Z last-modified: 2017-11-15T17:41:46Z source: RIPE Same ASN. Can RIPE purge all the IRR entries created by this maintainer? They don't appear to be legitimate. On 11/9/2017 2:13 PM, Nick Hilliard via db-wg wrote: denis walker via db-wg wrote: Perhaps after the RIPE NCC implements the agreed actions on foreign ROUTE objects, it would be a good idea to do a (one time?) cleanup/review of all foreign ROUTE objects in the RIPE IRR. Find the contact details in the appropriate RIR Database for all non RIPE address space covered by these ROUTE objects. Send them a notification with a link to click if they approve of the ROUTE object. If no response is received within a defined time period, delete the ROUTE object. a cleanup would be a good idea, but this is probably too aggressive an approach. I'd prefer to see multiple contact attempts with the objects eventually modified to make a note that they are flagged for deletion, before they are actually deleted. Some categories of entries can probably be deleted immediately, e.g. route(6) objects which are associated with ASNs which are unregistered or from the private ranges. There are a couple of special case ASNs, e.g. AS112. Nick
