- db-wg - mailman.ripe.net

Re: [db-wg] DB signatures
by denis walker 13 Oct '17

13 Oct '17

Hi Aliaksei The files are regenerated daily. There are some checks done on the files as part of the generation process, like zero size check or size difference more than some percentage from yesterday. Perhaps the RIPE NCC can comment on the possibility of signing or checksum files? cheersdenisco-chair DB WG From: Aliaksei Sheshka via db-wg <db-wg(a)ripe.net> To: db-wg(a)ripe.net Sent: Friday, 13 October 2017, 19:45 Subject: [db-wg] DB signatures Hello! I would like to know if there is a plan to sign / checksum files located at ftp://ftp.ripe.net/ripe/dbase/split/ ? Currently there is no mechanism to know if files aren't tampered or corrupted. My second question is how often those files are updated? Thanks!

2 1

DB signatures
by Aliaksei Sheshka 13 Oct '17

13 Oct '17

Hello! I would like to know if there is a plan to sign / checksum files located at ftp://ftp.ripe.net/ripe/dbase/split/ ? Currently there is no mechanism to know if files aren't tampered or corrupted. My second question is how often those files are updated? Thanks!

1 0

Fw: [db-wg] Foreign ROUTE objects in RIPE Database - final decision?
by denis walker 13 Oct '17

13 Oct '17

Second attempt to get through the mailing system.... ----- Forwarded Message ----- From: denis walker <ripedenis(a)yahoo.co.uk> To: Sascha Luck [ml] <dbwg(a)c4inet.net> Cc: Database WG <db-wg(a)ripe.net> Sent: Wednesday, 11 October 2017, 19:40 Subject: Re: [db-wg] Foreign ROUTE objects in RIPE Database - final decision? Hi Sascha, all I see this as a real possibility for the longer term. But realistically it is not going to help with the situation in the near future. I see some think that RADB is already a 'central DB' whereas others in this thread have said they would not use RADB (don't know it that is for technical, political or reliability issues). Just to throw a wild idea into the pot on this. If we were to look into the possibility of a centralised database, at least for the three RIRs who use a common database root RIPE, APNIC, Afrinic, then to me it makes sense to have a common, public database for operational data not only for routing information but also for number resource information. Then such a common database could do proper authentication. Almost certainly the personal data referenced by the operational data would need to remain in separate regional databases for privacy and data protection reasons. From the point of view of managing globally unique resources it makes perfect sense. But I suspect there would be lots of opposition to such a suggestion for political and self preservation reasons from many directions. Bearing in mind that any such suggestion would takes years from an idea to reality, I don't think we should get too bogged down in discussing this as part of this thread. However, several people have mentioned the idea of proper management of global resources. So perhaps if someone feels the desire to raise the issue in Dubai and formally call for the start of a serious investigation process that could lead to a common operational database, then the ball will at least start rolling.... cheersdenisco-chair DB WG From: Sascha Luck [ml] via db-wg <db-wg(a)ripe.net> To: denis walker <ripedenis(a)yahoo.co.uk> Cc: Database WG <db-wg(a)ripe.net> Sent: Wednesday, 11 October 2017, 16:21 Subject: Re: [db-wg] Foreign ROUTE objects in RIPE Database - final decision? On Mon, Oct 09, 2017 at 02:49:39PM +0100, denis walker via db-wg wrote: > Question - Should the RIPE Database allow creation of ROUTE objects for non RIPE resources? Is an option D: create a central IRRDB with authentication hooks into all RIRs completely out of the question? It certainly sounds like the technologically most elegant answer. Modulo legacy resources, no unauthenticated irrdb objects should then have to exist. The trust root could be shared between the RIRs as is seemingly done with RPKI these days... cheers, Sascha Luck

1 0

Re: [db-wg] RIPE Access Account: Cannot change registered e-mail address back to previously one
by Tim Bruijnzeels 12 Oct '17

12 Oct '17

Dear Christoffer, Unfortunately this is not as easy to implement as one might think. However, we will look into this again and see if we can find a solution for this issue. Kind regards Tim Bruijnzeels Assistant Manager Software Engineering RIPE NCC > On 10 Oct 2017, at 21:16, Christoffer Hansen via db-wg <db-wg(a)ripe.net> wrote: > > > From: Christoffer Hansen via db-wg <db-wg(a)ripe.net> > Subject: [db-wg] RIPE Access Account: Cannot change registered e-mail address back to previously one > To: RIPE Database Working Group <db-wg(a)ripe.net> > Reply-To: Christoffer Hansen <netravnen(a)gmail.com> > > > > From: Christoffer Hansen <netravnen(a)gmail.com> > Subject: RIPE Access Account: Cannot change registered e-mail address back to previously one > Date: 10 October 2017 at 19:52:50 GMT+2 > To: RIPE Database Working Group <db-wg(a)ripe.net> > > > RIPE Database Working Group <db-wg(a)ripe.net> > > > Am I the only one who have previously wondered about the following issue... (?) > > 1. Register a RIPE Access Account with [account_1(a)example.com] > 2. is changed to [account_2(a)example.com] > 3. later tries to change registered RIPE Access Account e-mail back to [account_1(a)example.com]. > > I'am not allowed to do this. > > RIPE NCC's website simply does *not* allow me to do this. > > Refer to the following pictures for clarification. > > > Changing the e-mail address back to [account_1(a)example.com] > <2017-10-10 19_00_24-RIPE NCC Access — RIPE Network Coordination Centre.png> > × > > > > Creating a new RIPE Access Account for [account_1(a)example.com] > <2017-10-10 19_03_18-RIPE NCC Access — RIPE Network Coordination Centre.png> > × > > > > Trying the forgotten password function for [account_1(a)example.com] > <2017-10-10 19_04_28-RIPE NCC Access — RIPE Network Coordination Centre.png> > × > > > > > Regards, > Christoffer Hansen. > gpg: c8b3 82a8 a1cd cdb7 71fe b24c c654 948f da86 becd > > > >

2 4

Re: [db-wg] Foreign ROUTE objects in RIPE Database - final decision?
by George Michaelson 11 Oct '17

11 Oct '17

I think its time to stop disrespecting external source of authority on this. You argued for a position based on the desire of RIPE entities needing to import foreign objects into their RPSL But you did not address the far larger body of people who are exposed to risks from the public maintainer and foreign object model, which we know is causing problems. I have presented three times on this at RIPE meetings in Dublin, Bucharest and Amsterdam pointing out that APNIC helpdesk and hostmaster are mediating calls from members who are concerned at how their ASN wound up in the RIPE RPSL. I also spoke recently at the APNIC services meeting to this, calling for a bit more dialogue on what we want to do. Lets build an ecology which can handle disparate sources, and stop demanding a bogus security model. The open maintainer is yesterdays man. a) Move the non-local stuff to another source and be explicit its an import to allow people to discriminate. We should do this irrespective of any other work: its not in RIPE data management, its not part of RIPE authoritative statements. A declaration of intent through an open maintainer is functionally indistinguishable from a lie. b) We can think about ROA. There is no permission from the origin-as to be referred to in a ROA, and we know that people regard the ROA as semantically in the same space as the route: object which demands the aut-num import. So we have a clear signal that routing praxis is now not that concerned with ASN authority to be cited in origin-AS. If you remove the dependency on aut-num maintainer, you will removed the dependency on foreign object import. The validity of authority over the aut-num can be understood from its appropriate RIR or NIR declaration, as an imported source. -George On Wed, Oct 11, 2017 at 8:06 AM, Job Snijders via db-wg <db-wg(a)ripe.net> wrote: > > > ---------- Forwarded message ---------- > From: Job Snijders <job(a)instituut.net> > To: "Carlos M. Martinez" <carlosm3011(a)gmail.com>, "Sascha Luck [ml]" <dbwg(a)c4inet.net> > Cc: Database WG <db-wg(a)ripe.net>, denis walker <ripedenis(a)yahoo.co.uk> > Bcc: > Date: Wed, 11 Oct 2017 15:06:04 +0000 > Subject: Re: [db-wg] Foreign ROUTE objects in RIPE Database - final decision? > > On Wed, 11 Oct 2017 at 16:52, Sascha Luck [ml] via db-wg <db-wg(a)ripe.net> wrote: >> >> On Wed, Oct 11, 2017 at 11:30:06AM -0300, Carlos M. Martinez wrote: >> >IMHO, any idea that starts with “Let´s create a central X” is doomed from the start. >> > >> >We must think along other lines. >> >> Maybe "central" was the wrong word to use. Think a DB that every >> RIR provides a copy of and authenticates the bits that "belong" >> to it. This would even be necessary to avoid compromise. >> One could pick the copy to use for filter generation or even >> query them all and implement a majority decision if there are >> discrepancies. >> Of course it would require all RIRs to use the same RPSL format >> but that appears more of a political than a technical problem. > > > > We already have that “central IRR” in the form of the likes of the RADB Whois server. RIPE’s data is the odd one out here. > > RIPE is the _only_ IRR source where we cannot differentiate between authenticated data and non-authenticated data. > > For all other sources we know that either the route objects have been authenticated against the inetnum’s specified maintainer (APNIC, AFRINIC, JPIRR) or is entirely without such verification (ARIN, NTTCOM, ALTDB, RADB itself, etc). > > The value of the data in the RIPE DB would significantly increase if this difference is shown. > > Kind regards, > > Job > >

1 0

Re: [db-wg] Foreign ROUTE objects in RIPE Database - final decision?
by Job Snijders 11 Oct '17

11 Oct '17

On Wed, 11 Oct 2017 at 16:52, Sascha Luck [ml] via db-wg <db-wg(a)ripe.net> wrote: > On Wed, Oct 11, 2017 at 11:30:06AM -0300, Carlos M. Martinez wrote: > >IMHO, any idea that starts with “Let´s create a central X” is doomed from > the start. > > > >We must think along other lines. > > Maybe "central" was the wrong word to use. Think a DB that every > RIR provides a copy of and authenticates the bits that "belong" > to it. This would even be necessary to avoid compromise. > One could pick the copy to use for filter generation or even > query them all and implement a majority decision if there are > discrepancies. > Of course it would require all RIRs to use the same RPSL format > but that appears more of a political than a technical problem. We already have that “central IRR” in the form of the likes of the RADB Whois server. RIPE’s data is the odd one out here. RIPE is the _only_ IRR source where we cannot differentiate between authenticated data and non-authenticated data. For all other sources we know that either the route objects have been authenticated against the inetnum’s specified maintainer (APNIC, AFRINIC, JPIRR) or is entirely without such verification (ARIN, NTTCOM, ALTDB, RADB itself, etc). The value of the data in the RIPE DB would significantly increase if this difference is shown. Kind regards, Job >

1 0

Re: [db-wg] Foreign ROUTE objects in RIPE Database - final decision?
by Carlos M. Martinez 11 Oct '17

11 Oct '17

IMHO, any idea that starts with “Let´s create a central X” is doomed from the start. We must think along other lines. /Carlos On 11 Oct 2017, at 11:21, Sascha Luck [ml] via db-wg wrote: > From: Sascha Luck [ml] <dbwg(a)c4inet.net> > > To: denis walker <ripedenis(a)yahoo.co.uk> > > Cc: Database WG <db-wg(a)ripe.net> > > Subject: Re: [db-wg] Foreign ROUTE objects in RIPE Database - > final decision? > > Date: October 11, 2017 at 11:21 AM > > > > > On Mon, Oct 09, 2017 at 02:49:39PM +0100, denis walker via db-wg > wrote: > > >> Question - Should the RIPE Database allow creation of ROUTE objects >> for non RIPE resources? > > > Is an option D: create a central IRRDB with authentication hooks > into all RIRs completely out of the question? It certainly sounds > like the technologically most elegant answer. Modulo legacy > resources, no unauthenticated irrdb objects should then have to > exist. The trust root could be shared between the RIRs as is > seemingly done with RPKI these days... > > cheers, > Sascha Luck

2 1

Re: [db-wg] Foreign ROUTE objects in RIPE Database - final decision?
by Nick Hilliard 11 Oct '17

11 Oct '17

Sascha Luck [ml] via db-wg wrote: > Not allowing > "foreign" resources in the ripedb denies the reality that there > will always be RIPE-allocated prefixes originated from > non-RIPE-assigned ASNs and vice versa. Not true - you can easily run a whois query on whois.radb.net specifying multiple sources, including RIPE: % bgpq3 -S RIPE,APNIC,LACNIC AS-FOO In fact, there is no way of writing a functioning irrdb querier which can't handle specifying arbitrary irrdb source: options on a per-ASN basis. Nick

2 2

Re: [db-wg] Foreign ROUTE objects in RIPE Database - final decision?
by Sascha Luck [ml] 11 Oct '17

11 Oct '17

On Mon, Oct 09, 2017 at 02:49:39PM +0100, denis walker via db-wg wrote: > Question - Should the RIPE Database allow creation of ROUTE objects for non RIPE resources? Is an option D: create a central IRRDB with authentication hooks into all RIRs completely out of the question? It certainly sounds like the technologically most elegant answer. Modulo legacy resources, no unauthenticated irrdb objects should then have to exist. The trust root could be shared between the RIRs as is seemingly done with RPKI these days... cheers, Sascha Luck

1 0

Re: [db-wg] Foreign ROUTE objects in RIPE Database - final decision?
by Job Snijders 11 Oct '17

11 Oct '17

On Tue, Oct 10, 2017 at 4:17 PM, Nick Hilliard via db-wg <db-wg(a)ripe.net> wrote: > ---------- Forwarded message ---------- > From: Nick Hilliard <nick(a)foobar.org> > To: Randy Bush <randy(a)psg.com> > Cc: Database WG <db-wg(a)ripe.net> > Date: Tue, 10 Oct 2017 15:16:41 +0100 > Subject: Re: [db-wg] Foreign ROUTE objects in RIPE Database - final decision? > Randy Bush via db-wg wrote: >>> > Question - Should the RIPE Database allow creation of ROUTE objects >>> > for non RIPE resources? >> >> yes > > then how can we use the traditional irrdb to distinguish between address > blocks which have been authenticated by the ripe ncc and those which > have not. > > Nick I think this touches upon an incredibly important question: how do we distinguish between garbage and properly authenticated "route:" objects covering RIPE-managed space? It seems it would be low hanging fruit to use the "source:" tag to distinguish between objects that are authenticated and non-authenticated by using "source: RIPE" and "source: RIPE-NONAUTH". The above described small step bridges the needs to many who expressed opposing views in this thread: some want to be able to register anything in the RIPE DB and some want it to be pristine and purge all non-RIPE-managed space from the IRR DB. By decorating the two types of data with the appropriate "source:" attribute I think we are meeting in the middle. By using a different "source:" attribute for RIPE vs non-RIPE space it becomes easier for operators to cherry pick which data they want to use in the creation of their routing security filters. Should the group decide to proceed with option A or C (between which I don't see a difference), at the very least it should be visible to my tooling which objects represent what type of data. Kind regards, Job

2 1