On Thu, 12 Jul 2018 at 12:50, Aftab Siddiqui <aftab.siddiqui@gmail.com> wrote:

Thanks for the detailed response and it means if the source is not RIPE then it shouldn’t be considered as authentic data because the resource belongs to RIPE NCC.

That I am not certain about. Normally I would expect to at least find an INETNUM object in the RIPE NCC database. I can only say try contacting fx. support _at_ ripe.net for further details about why the RIPE NCC database does not hold any inetnum record for the prefix. When the (commercial) RADB database hold the routes for it.

As posted earlier the resource in question is 188.64.224.0/21 which doesn’t result anything from default source i.e RIPE.

I believe RIPE NCC Support Staff (support _at_ ripe.net) is better suited to answer this question. On Thu, 12 Jul 2018 at 12:50, Aftab Siddiqui <aftab.siddiqui@gmail.com> wrote:

Hi Christoffer, Thanks for the detailed response and it means if the source is not RIPE then it shouldn’t be considered as authentic data because the resource belongs to RIPE NCC.

As posted earlier the resource in question is 188.64.224.0/21 which doesn’t result anything from default source i.e RIPE. On Thu, 12 Jul 2018 at 6:20 pm, Christoffer Hansen <netravnen@gmail.com> wrote:

...

On Thu, 12 Jul 2018 at 11:24, Aftab Siddiqui via db-wg <db-wg@ripe.net> wrote:

...

I would like to understand the difference between these 2 results for the same prefix.

Source: GRS https://apps.db.ripe.net/db-web-ui/#/query?bflag=true&source=GRS&searchtext=188.64.224.0%2F21#resultsSection

~ > whois --host whois.ripe.net -rB --resource 188.64.224.0/21 | grep -ve '^[[:space:]]*$' | grep -ve '^[% ]' | grep -v 'remarks:' route: 188.64.224.0/21 descr: Twitter Route origin: AS13414 notify: noc@twitter.com mnt-by: MAINT-AS13414 source: RADB-GRS

Note the "--resource" parameter being present. Which will include results from other(!) databases apart from the RIPE NCC database. In this case the RADB-GRS database. The 'source:' also denote this fact.

Nb: You can see http://www.irr.net/docs/list.html#RIPE which other RIR databases the RIPE NCC mirrors.

...

Source: RIPE https://apps.db.ripe.net/db-web-ui/#/query?bflag&searchtext=188.64.224.0%2F21&source=RIPE#resultsSection

~ > whois -h whois.ripe.net -rB 188.64.224.0/21 | grep -ve '^[[:space:]]*$' | grep -ve '^[% ]' | grep -v 'remarks:' inetnum: 188.0.0.0 - 188.255.255.255 netname: EU-ZZ-188 descr: To determine the registration information for a more descr: specific range, please try a more specific query. descr: If you see this object as a result of a single IP query, descr: it means the IP address is currently in the free pool of descr: address space managed by the RIPE NCC. country: EU # Country is in fact world wide admin-c: IANA1-RIPE tech-c: IANA1-RIPE status: ALLOCATED UNSPECIFIED mnt-by: RIPE-NCC-HM-MNT created: 2002-04-08T12:41:20Z last-modified: 2015-09-23T13:18:27Z source: RIPE

By default only results from the RIPE NCC database is included.

Yup sending an email to support (RIPE) for clarification. But Twitter NOC is adamant that they are not doing the wrong thing (advertising unallocated address space) because it shows in RADB-GRS via RIPE Whois On Thu, 12 Jul 2018 at 7:39 pm, Christoffer Hansen <netravnen@gmail.com> wrote:

On Thu, 12 Jul 2018 at 13:28, Christoffer Hansen <netravnen@gmail.com> wrote:

...

On Thu, 12 Jul 2018 at 12:50, Aftab Siddiqui <aftab.siddiqui@gmail.com>

wrote:

...

...

Thanks for the detailed response and it means if the source is not RIPE then it shouldn’t be considered as authentic data because the resource belongs to RIPE NCC.

That I am not certain about. Normally I would expect to at least find an INETNUM object in the RIPE NCC database.

If I go by the list published the RIPE NCC themself. https://ftp.ripe.net/pub/stats/ripencc/delegated-ripencc-latest The 188.64.224.0/21 prefix is not allocated at all.

Why Twitter is announcing it. < scratching head for answers >

https://stat.ripe.net/188.64.224.0-188.64.231.255?sourceapp=ripedb#tabId=dat...

Christoffer

RIPE’s stat page https://stat.ripe.net/AS8945#tabId=routing shows that 188.64.224.0/24 was announced by AS8945 from late 2009 to the end of Sep 2015. From early Dec 2015 - now, various more specifics in 188.64.224.0/21 have been consistently announced by AS13414. No other consistent originators of parts of 188.64.224.0/21 are shown. AS8945 is still evidently an actively maintained AS in the RIPE database, last updated in Jan 2018. It just doesn’t announce any routes (zero) and has not announced anything for a long time. It is still keeping its membership active - the organization was updated this week. The AS is still on the list of members for Equinix Paris. The RIPE database lists the AS as “Heron SAS”, which I can’t find as a commercial concern. The maintainer email is @scanandtarget.com (a charming name, yes?). The historical RIPE stat files Geoff pointed to show the /21 as allocated in Jul 2009, and that same line shows up in the stat files since then. Until yesterday. Until the stat file for 20180711, when it switches from “allocated” to “reserved”. (Coincidence?) According to the NRO explanation of the stat file format, “reserved” could mean many things, one of the most likely being returns that are not yet available for reassignment. I can’t guess what that means about who returned the space. Or about twitter continued use going forward. —Sandy

On Jul 12, 2018, at 7:59 AM, Christoffer Hansen via db-wg <db-wg@ripe.net> wrote:

On Thu, 12 Jul 2018 at 13:45, Aftab Siddiqui <aftab.siddiqui@gmail.com> wrote:

...

Yup sending an email to support (RIPE) for clarification.

I would be happy if you could share a summarized edit of the response you get back.

...

But Twitter NOC is adamant that they are not doing the wrong thing (advertising unallocated address space) because it shows in RADB-GRS via RIPE Whois

The routing policy (NOT assignment!) shows up in RIPE Whois. Because RIPE mirrors objects in RADB. Where Twitter themself have registeret only route policy objects for both 188.64.224.0/21 and smaller /23 and /24 prefixes inside the main /21 prefix.

~ > whois -h whois.radb.net 188.64.224.0/21 route: 188.64.224.0/21 descr: Twitter Route origin: AS13414 admin-c: NETWO3685-ARIN tech-c: NETWO3685-ARIN notify: noc@twitter.com mnt-by: MAINT-AS13414 changed: frehoie@twitter.com 20160112 #15:43:10Z source: RADB

http://www.radb.net/ "Merit RADb is a public registry of network routing information that assists with the transfer of data over the Internet. For over 20 years, Merit RADb has been serving the Internet community. Thousands of organizations that operate networks have registered their routing policies in Merit RADb to facilitate the operation of the Internet, including Internet service providers, universities, and businesses. The information in Merit RADb enables organizations to troubleshoot routing problems, automatically configure backbone routers, generate access lists, and perform network planning. Any organization with an autonomous system number (ASN) may register in Merit RADb for an annual fee of $495 (U.S. Dollars). Non-profit organizations may register annually for $395."

And seeing as RADB is a commercial entity advertising themself with the line "organizations that operate networks have registered their routing policies in Merit RADb". I read it as RADB is only a DB for advertising routing policies. NOT for holding INETNUM assignments.

Which concludes I am in agreement with you.

I am not sure Twitter is doing the right thing of advertising unallocated space.

Hi Geoff,

Of course Twitter is doing nothing uniquely unusual in this respect, as these are just 7 examples from a pool of some 300 announcements of unallocated address space (a list of such bogons can be found at http://www.cidr-report.org/as2.0/#Bogons)

:)

- Why is Twitter announcing these prefixes?

I have no idea. Something has gone wrong here and the address has come back to the RIR and Twitter apper to be unaware of this.

No, Twitter is absolutely aware of this issue, I alerted their NOC when I got the result this morning from CIDR report (yes, I scrop your data daily) but unfortunately there response was "This prefix is valid and owned by us in RIPE region. Please do your homework before making incorrect accusations." But atleast I tried.

- How and why is this prefix in RADB, given that it is unallocated space?

Good question - I wonder what periodic checks the RADB undertakes on the data held in its registry?

No idea, it should be triggered right away when the RIR, who is the authentic source of these resources marked them "Unalloacted". But in a perfect world.

- Why do upstream AS’s accept these advertised prefixes?

Maybe they chose to believe that RADB performs robust periodic integrity checks? Or <insert reason here>?

Yes, mostly follow RADB.

Geoff

Dear all, We would like to inform you that the RIPE NCC has de-registered 188.64.224.0/21 on 10 July 2018 according to our published procedures. We are in contact with the relevant party. Best Regards, Henriette van Ingen Customer Services RIPE NCC

On 13 Jul 2018, at 11:54, denis walker via db-wg <db-wg@ripe.net> wrote:

Hi Guys

I am sure everyone will disagree with me, but this shows (to me) why it would be better to have one authoritative, accurate, trusted, distributed IRR managed by the 5 RIRs than many independent/commercial IRRs with non authenticated data.

cheers denis co-chair DB-WG

From: Aftab Siddiqui via db-wg <db-wg@ripe.net> To: Geoff Huston <gih@apnic.net> Cc: RIPE Database Working Group <db-wg@ripe.net> Sent: Thursday, 12 July 2018, 18:40 Subject: Re: [db-wg] Source GRS vs RIPE

Hi Geoff,

Of course Twitter is doing nothing uniquely unusual in this respect, as these are just 7 examples from a pool of some 300 announcements of unallocated address space (a list of such bogons can be found at http://www.cidr-report.org/as2.0/#Bogons <http://www.cidr-report.org/as2.0/#Bogons>)

:)

- Why is Twitter announcing these prefixes?

I have no idea. Something has gone wrong here and the address has come back to the RIR and Twitter apper to be unaware of this.

No, Twitter is absolutely aware of this issue, I alerted their NOC when I got the result this morning from CIDR report (yes, I scrop your data daily) but unfortunately there response was "This prefix is valid and owned by us in RIPE region. Please do your homework before making incorrect accusations." But atleast I tried.

- How and why is this prefix in RADB, given that it is unallocated space?

Good question - I wonder what periodic checks the RADB undertakes on the data held in its registry?

No idea, it should be triggered right away when the RIR, who is the authentic source of these resources marked them "Unalloacted". But in a perfect world.

- Why do upstream AS’s accept these advertised prefixes?

Maybe they chose to believe that RADB performs robust periodic integrity checks? Or <insert reason here>?

Yes, mostly follow RADB.

Geoff

Dear Aftab, RADb is a public registry of network routing information which is run by a different organisation. They are responsible for their own data in the RADb database. Best Regards, Henriette van Ingen RIPE NCC

On 13 Jul 2018, at 16:59, Aftab Siddiqui via db-wg <db-wg@ripe.net> wrote:

Hi Henriette, Thanks for the update. Are you also talking to radb to remove misleading object for the same prefix and it’s deaggregates? On Fri, 13 Jul 2018 at 10:49 pm, Henriette Van Ingen via db-wg <db-wg@ripe.net <mailto:db-wg@ripe.net>> wrote: Dear all,

We would like to inform you that the RIPE NCC has de-registered 188.64.224.0/21 <http://188.64.224.0/21> on 10 July 2018 according to our published procedures. We are in contact with the relevant party.

Best Regards,

Henriette van Ingen Customer Services RIPE NCC

...

On 13 Jul 2018, at 11:54, denis walker via db-wg <db-wg@ripe.net <mailto:db-wg@ripe.net>> wrote:

Hi Guys

I am sure everyone will disagree with me, but this shows (to me) why it would be better to have one authoritative, accurate, trusted, distributed IRR managed by the 5 RIRs than many independent/commercial IRRs with non authenticated data.

cheers denis co-chair DB-WG

From: Aftab Siddiqui via db-wg <db-wg@ripe.net <mailto:db-wg@ripe.net>> To: Geoff Huston <gih@apnic.net <mailto:gih@apnic.net>> Cc: RIPE Database Working Group <db-wg@ripe.net <mailto:db-wg@ripe.net>> Sent: Thursday, 12 July 2018, 18:40 Subject: Re: [db-wg] Source GRS vs RIPE

Hi Geoff,

Of course Twitter is doing nothing uniquely unusual in this respect, as these are just 7 examples from a pool of some 300 announcements of unallocated address space (a list of such bogons can be found at http://www.cidr-report.org/as2.0/#Bogons <http://www.cidr-report.org/as2.0/#Bogons>)

:)

- Why is Twitter announcing these prefixes?

I have no idea. Something has gone wrong here and the address has come back to the RIR and Twitter apper to be unaware of this.

No, Twitter is absolutely aware of this issue, I alerted their NOC when I got the result this morning from CIDR report (yes, I scrop your data daily) but unfortunately there response was "This prefix is valid and owned by us in RIPE region. Please do your homework before making incorrect accusations." But atleast I tried.

- How and why is this prefix in RADB, given that it is unallocated space?

Good question - I wonder what periodic checks the RADB undertakes on the data held in its registry?

No idea, it should be triggered right away when the RIR, who is the authentic source of these resources marked them "Unalloacted". But in a perfect world.

- Why do upstream AS’s accept these advertised prefixes?

Maybe they chose to believe that RADB performs robust periodic integrity checks? Or <insert reason here>?

Yes, mostly follow RADB.

Geoff

On 13/07/2018 18:40, Sandra Murphy via db-wg wrote: While we are on the topic, anyone have an idea about Cisco and 66.187.208.0/20? Thanks, Hank

So that’s the change I saw visible in the RIPE stat files at https://ftp.ripe.net/pub/stats/ripencc/.

Twitter has been announcing that space for years. I wonder if they’ll report what led them to start the announcements.

—Sandy

...

On Jul 13, 2018, at 10:48 AM, Henriette Van Ingen via db-wg <db-wg@ripe.net> wrote:

Dear all,

We would like to inform you that the RIPE NCC has de-registered 188.64.224.0/21 on 10 July 2018 according to our published procedures. We are in contact with the relevant party.

Best Regards,

Henriette van Ingen Customer Services RIPE NCC

...

On 13 Jul 2018, at 11:54, denis walker via db-wg <db-wg@ripe.net> wrote:

Hi Guys

I am sure everyone will disagree with me, but this shows (to me) why it would be better to have one authoritative, accurate, trusted, distributed IRR managed by the 5 RIRs than many independent/commercial IRRs with non authenticated data.

cheers denis co-chair DB-WG

From: Aftab Siddiqui via db-wg <db-wg@ripe.net> To: Geoff Huston <gih@apnic.net> Cc: RIPE Database Working Group <db-wg@ripe.net> Sent: Thursday, 12 July 2018, 18:40 Subject: Re: [db-wg] Source GRS vs RIPE

Hi Geoff,

Of course Twitter is doing nothing uniquely unusual in this respect, as these are just 7 examples from a pool of some 300 announcements of unallocated address space (a list of such bogons can be found at http://www.cidr-report.org/as2.0/#Bogons)

:)

- Why is Twitter announcing these prefixes?

I have no idea. Something has gone wrong here and the address has come back to the RIR and Twitter apper to be unaware of this.

No, Twitter is absolutely aware of this issue, I alerted their NOC when I got the result this morning from CIDR report (yes, I scrop your data daily) but unfortunately there response was "This prefix is valid and owned by us in RIPE region. Please do your homework before making incorrect accusations." But atleast I tried.

- How and why is this prefix in RADB, given that it is unallocated space?

Good question - I wonder what periodic checks the RADB undertakes on the data held in its registry?

No idea, it should be triggered right away when the RIR, who is the authentic source of these resources marked them "Unalloacted". But in a perfect world.

- Why do upstream AS’s accept these advertised prefixes?

Maybe they chose to believe that RADB performs robust periodic integrity checks? Or <insert reason here>?

Yes, mostly follow RADB.

Geoff

Hi Hank, Following up with Cisco POC, I got this response. "We are in the process of retrieving this /20 back. An ARIN ticket was opened for this." I checked the ARIN allocation file until 1st March so it's been more than 4 months since ARIN marked this prefix "reserved". ftp://ftp.arin.net/pub/stats/arin/delegated-arin-extended-20180301 On Sun, 15 Jul 2018 at 20:08 Aftab Siddiqui <aftab.siddiqui@gmail.com> wrote:

Hi Hank,

On Sun, 15 Jul 2018 at 04:32 Hank Nussbacher via db-wg <db-wg@ripe.net> wrote:

...

On 13/07/2018 18:40, Sandra Murphy via db-wg wrote:

While we are on the topic, anyone have an idea about Cisco and 66.187.208.0/20?

Same issue, just because there is a bad entry in the RADB many transits are accepting it, well there is Hurricane Electric in the middle as well who doesn't filter anything though.

route: 66.187.208.0/20 <https://apps.db.ripe.net/db-web-ui/#/lookup?source=radb-grs&key=66.187.208.0/20AS109&type=route> descr: CISCO SYSTEMS, INC 170 WEST TASMAN DRIVE SAN JOSE, CA 95134 US RP-ALLN origin: AS109 <https://apps.db.ripe.net/db-web-ui/#/lookup?source=radb-grs&key=AS109&type=aut-num> mnt-by: MAINT-AS109 <https://apps.db.ripe.net/db-web-ui/#/lookup?source=radb-grs&key=MAINT-AS109&type=mntner> source: RADB-GRS