- db-wg - mailman.ripe.net

re:[db-wg] violation of DB T&C by DB-WG co-chair, is it acceptable?
by Anne-vivien Paris 14 Sep '17

14 Sep '17

Hi Elvis, Regarding your claim that our company misuses operation emails, we would like to address the issue in the following as it deeply affects our company's image as well as customer's credibility for us: 1. Although David sent the email, he is not the one who decides the recipient list. This is decided by the marketing team. 2. As a company which fully upholds fairness and respects customers ‘privacy, Larus NEVER uses any operation emails or technical emails for commercial use. The emails we used for commercial purpose are only those that are open to public. Please let us know if there is any misunderstanding. 3. We also respect our customer's privacy by implementing a un-subscription policy. Customers can unsubscribe anytime at their liberty. Larus never sends spam emails to our customers nor misuse any operation emails. Every employee of Larus follows strictly this policy. We do not tolerate any improper behaviour within the company as well as any false claims. Please do not hesitate to contact us in private if you find an operation email is used for commercial purpose.

3 2

re:[db-wg] violation of DB T&C by DB-WG co-chair, is it acceptable?
by Anne-vivien Paris 13 Sep '17

13 Sep '17

Hi Elvis, Regarding your claim that our company misuses operation emails, we would like to address the issue in the following as it deeply affects our company's image as well as customer's credibility for us: 1. Although David sent the email, he is not the one who decides the recipient list. This is decided by the marketing team. 2. As a company which fully upholds fairness and respects customers ‘privacy, Larus NEVER uses any operation emails or technical emails for commercial use. The emails we used for commercial purpose are only those that are open to public. Please let us know if there is any misunderstanding. 3. We also respect our customer's privacy by implementing a un-subscription policy. Customers can unsubscribe anytime at their liberty. Larus never sends spam emails to our customers nor misuse any operation emails. Every employee of Larus follows strictly this policy. We do not tolerate any improper behaviour within the company as well as any false claims. Please do not hesitate to contact us in private if you find an operation email is used for commercial purpose.

1 0

Draft Agenda RIPE75 - Database Working Group
by William Sylvester 11 Sep '17

11 Sep '17

Dear all, Below is the draft outline for the Database Working Group agenda for RIPE75. If you have any questions or comments please let the chairs know. Best regards, William, David, Denis DB-WG Chairs A. Introduction - 5 min * Welcome * Scribe * Jabber * Agenda B. Operational Update RIPE Database - 40 mins Tim Bruijnzeels, RIPE NCC C. Update on DB-WG mailing list challenges - 5 mins D. NWI - Open Proposals - 10 mins E. Identifier Technology Health Indicators (ITHI) - 20 mins Alain Durand, ICANN Z) AOB (open discussion)

1 0

Re: [db-wg] RIPE Policy Proposal 2017-02 Validates Database Attributes
by Horváth Ágoston János 11 Sep '17

11 Sep '17

Hi all, Agreed that a yearly email ping-pong is not really a good verification of abuse contact address. It's trivial to let RIPE NCC mails through and throw away the rest. But, one might ask, what's the point of a database if the data is not reliable? What's the point of all that contact info if we can't trust it? Why would we want to store (and serve) data that is not correct? Data validation is standard industry practice, pretty much everywhere. You can't even buy a bar of chocolate without validating your email address. One might ask, why would RIPE NCC not follow even the most basic industry practices while validating data of this importance? Cheers, Agoston On Thu, Sep 7, 2017 at 6:54 PM, Sascha Luck [ml] via db-wg <db-wg(a)ripe.net> wrote: > > > ---------- Forwarded message ---------- > From: "Sascha Luck [ml]" <dbwg(a)c4inet.net> > To: db-wg(a)ripe.net > Cc: anti-abuse-wg(a)ripe.net > Bcc: > Date: Thu, 7 Sep 2017 17:54:04 +0100 > Subject: Re: [db-wg] RIPE Policy Proposal 2017-02 Validates Database Attributes > All, > > I will discuss this here as I do not accept the Anti-Abuse WG as > a forum for this proposal. For one thing, this proposal affects > every ripedb user - in fact, as this entails changes to how the > NCC provides services, the services-wg would be an even better > venue. For another, given the "population" and culture of > "debate" on the AAWG, any "consensus" reached there would be so > worthless as to be farcical. (If anyone wants amplification on > this, https://www.ripe.net/ripe/mail/archives/anti-abuse-wg/ > provides ample evidence. > > To the meat of the proposal: > > Firstly, this proposal conflicts somewhat with NWI-7 in this very > WG. (Another reason why it should have gone here in the first > place) With the upcoming possibility of delegating abuse-c: to > (customers') resource objects, who bears any consequences of > these customers not replying to this proposed email? >> >> Rationale >> a. Arguments supporting the proposal > > >> Accurate and validated information in the RIPE Database is >> essential to establish a trusted and transparent environment in >> which all network operators can operate safely. > > > abuse-c: is a contact object, just as admin-c: or tech-c: and > (correct me if I'm wrong) audited at the same time as the rest of > the contact information. What makes it so unique that this > verification is not enough? > >> Accurate and >> validated information helps Internet troubleshooting at all >> levels, but it also helps to attribute malicious online >> activities that undermine this trusted environment. > > > See above. > >> The lack of reliable accurate and validated information in the >> database negatively impacts legitimate uses of the RIPE Database, >> including: > > > An *email adress* that doesn't reply once a year does NOT equate > to a "lack of reliable accurate and validated information". I > find this statement somewhat insulting to the NCC team who do > make the effort to keep the ripedb data accurate and do audit > resource holders. > There is an issue with the reliability of out-of-region and > legacy resource data but as the NCC has no "enforcement" powers > over these resource holders, in these cases this proposal > snatches at thin air. >> >> Assuring the security and reliability of the network by >> identifying points of contact for IP addresses for network >> operators, ISPs, and certified computer incident response teams; > > > "org:", "admin-c:", "tech-c:", "mnt-by:" and, yes, "abuse-c:" exist. > >> Ensuring that IP address holders are accountable, so individuals, >> consumers and the public are empowered to resolve abusive >> practices that impact safety and security; >> Assisting businesses, consumer groups, healthcare organisations >> and other organisations that are combating fraud (some of which >> have mandates to electronically save records) to comply with >> relevant legal and public safety safeguards; > > > The contact object that does (or *should*) stand for the person(s) who > can speak for a LIR, legally, is "admin-c:". "abuse-c:" is some role > account in a NOC or even a ticket system unlikely to have any > decision-making power. An attempt to make these roles (perhaps > even personally) responsible for the behaviour of a LIR and its > customers is counter-productive. I for one would flatly refuse to > do any abuse report handling under these circumstances. > >> Complying with national, civil and criminal due process laws in >> support of investigations and providing justice for victims. > > > Would the proposers please amplify exactly which law or due > process is violated by the NCC not sending an email once a year > to an abuse-c:? Myself, and I'm sure the NCC legal team, would be > interested to know. > > On a technical note, email is neither a secure nor a reliable > transport for such verification. In the day of blocklists and > large email providers imposing arbitrary restrictions on email > senders it is not guaranteed that a verification email reaches > the intended address or that a reply reaches the sender. The NCC > ARC procedure, however employs both email and personal contact > via telephone to verify the accuracy of the ripedb information. > > In toto, this proposal would impose unneccessary work on LIRs and > the NCC, using unsuitable means to rectify a non-existing issue, and I therefore oppose it. > >

1 0

Re: [db-wg] RIPE Policy Proposal 2017-02 Validates Database Attributes
by Sascha Luck [ml] 10 Sep '17

10 Sep '17

All, I will discuss this here as I do not accept the Anti-Abuse WG as a forum for this proposal. For one thing, this proposal affects every ripedb user - in fact, as this entails changes to how the NCC provides services, the services-wg would be an even better venue. For another, given the "population" and culture of "debate" on the AAWG, any "consensus" reached there would be so worthless as to be farcical. (If anyone wants amplification on this, https://www.ripe.net/ripe/mail/archives/anti-abuse-wg/ provides ample evidence. To the meat of the proposal: Firstly, this proposal conflicts somewhat with NWI-7 in this very WG. (Another reason why it should have gone here in the first place) With the upcoming possibility of delegating abuse-c: to (customers') resource objects, who bears any consequences of these customers not replying to this proposed email? >Rationale >a. Arguments supporting the proposal >Accurate and validated information in the RIPE Database is >essential to establish a trusted and transparent environment in >which all network operators can operate safely. abuse-c: is a contact object, just as admin-c: or tech-c: and (correct me if I'm wrong) audited at the same time as the rest of the contact information. What makes it so unique that this verification is not enough? >Accurate and >validated information helps Internet troubleshooting at all >levels, >but it also helps to attribute malicious online >activities that undermine this trusted environment. See above. >The lack of reliable accurate and validated information in the >database negatively impacts legitimate uses of the RIPE Database, >including: An *email adress* that doesn't reply once a year does NOT equate to a "lack of reliable accurate and validated information". I find this statement somewhat insulting to the NCC team who do make the effort to keep the ripedb data accurate and do audit resource holders. There is an issue with the reliability of out-of-region and legacy resource data but as the NCC has no "enforcement" powers over these resource holders, in these cases this proposal snatches at thin air. >Assuring the security and reliability of the network by >identifying points of contact for IP addresses for network >operators, ISPs, and certified computer incident response teams; "org:", "admin-c:", "tech-c:", "mnt-by:" and, yes, "abuse-c:" exist. >Ensuring that IP address holders are accountable, so individuals, >consumers and the public are empowered to resolve abusive >practices that impact safety and security; >Assisting businesses, consumer groups, healthcare organisations >and other organisations that are combating fraud (some of which >have mandates to electronically save records) to comply with >relevant legal and public safety safeguards; The contact object that does (or *should*) stand for the person(s) who can speak for a LIR, legally, is "admin-c:". "abuse-c:" is some role account in a NOC or even a ticket system unlikely to have any decision-making power. An attempt to make these roles (perhaps even personally) responsible for the behaviour of a LIR and its customers is counter-productive. I for one would flatly refuse to do any abuse report handling under these circumstances. >Complying with national, civil and criminal due process laws in >support of investigations and providing justice for victims. Would the proposers please amplify exactly which law or due process is violated by the NCC not sending an email once a year to an abuse-c:? Myself, and I'm sure the NCC legal team, would be interested to know. On a technical note, email is neither a secure nor a reliable transport for such verification. In the day of blocklists and large email providers imposing arbitrary restrictions on email senders it is not guaranteed that a verification email reaches the intended address or that a reply reaches the sender. The NCC ARC procedure, however employs both email and personal contact via telephone to verify the accuracy of the ripedb information. In toto, this proposal would impose unneccessary work on LIRs and the NCC, using unsuitable means to rectify a non-existing issue, and I therefore oppose it.

4 3

Re: [db-wg] RIPE Policy Proposal 2017-02 Validates Database Attributes
by William Sylvester 08 Sep '17

08 Sep '17

DB WG Members, We understand there are many opinions on this proposal. We encourage everyone to discuss this request on the anti-abuse mailing list. We have been coordinated with the AA-WG chairs on this and would appreciate expressing your support or objections in the AA-WG as that is the forum this proposal was raised. If you have any questions or concerns please contact the db-wg chairs. Thanks, William, Denis, and David Database WG Chairs On Sep 7, 2017, at 1:05 PM, Marco Schmidt via db-wg <db-wg(a)ripe.net<mailto:db-wg@ripe.net>> wrote: <mime-attachment>

1 0

RIPE Policy Proposal 2017-02 Validates Database Attributes
by Marco Schmidt 08 Sep '17

08 Sep '17

Dear colleagues, We just published RIPE Policy proposal, 2017-02, "Regular abuse-c Validation", to the Anti-Abuse Working Group mailing list. The goal of this proposal is to give the RIPE NCC a mandate to regularly validate "abuse-c:" information, and to follow up in cases where contact information is found to be invalid. As this proposal relates to contact information put into the RIPE Database, we would like to notify the Database Working Group specifically. You can find the full proposal at: https://www.ripe.net/participate/policies/proposals/2017-02 We encourage you to review this proposal and send your comments to <anti-abuse-wg(a)ripe.net> before 6 October 2017. Regards, Marco Schmidt Policy Development Officer RIPE NCC Sent via RIPE Forum -- https://www.ripe.net/participate/mail/forum

2 2

Re: Last Call for Agenda Items DB-WG Meeting - RIPE75 - Dubai, UAE
by William Sylvester 01 Sep '17

01 Sep '17

Dear DB-WG Members, This is the last call for agenda items for the DB-WG Meeting at RIPE75 at the Conrad Dubai in Dubai, UAE. Due to restrictions by UAE law we will not be able to add last minute presentations. Please submit your proposals to the working group chairs as soon as possible not later than September 6, 2017. Please submit agenda items or propose additional topics to be discussed both on the mailing list or direct to the WG Chairs at db-wg-chairs(a)ripe.net<mailto:db-wg-chairs@ripe.net> The DB-WG Meeting is scheduled for Wednesday, October 25th, starting at 14:00 local time, after lunch and before the coffee break. The length of our timeslot is 90 minutes. For the overall RIPE 74 meeting plan please refer to its most up-to-date version at https://ripe75.ripe.net/programme/meeting-plan/ Note: due to UAE law, confirmed speakers will need to submit a copy of their passport and contact information in advance of the meeting. More details are available here: https://ripe75.ripe.net/attend/dctm-requirements We are looking forward to another successful meeting in Dubai. Kind regards, William, Denis, & David DB WG Chairs

1 0

Whois Master Database Patch
by Edward Shryane 31 Aug '17

31 Aug '17

Dear working group, Tomorrow afternoon, Friday 1 September, we will apply a patch to the Whois Master database server. This will cause a short downtime for Whois updates. Queries will not be affected. Regards, Ed Shryane RIPE NCC

1 0

Re: [db-wg] NWI-7: abuse-c implementation plan
by Tim Bruijnzeels 30 Aug '17

30 Aug '17

Dear working group, We have a proposed timeline for the implementation. Let me quote the proposal sent out on 28 June here, and comment in-line: > 1) Allow “abuse-c:” on INET(6)NUM and AUT-NUM objects > > We will deploy a new version of whois where the “abuse-c:” attribute will be allowed to exist on INET(6)NUM and AUT-NUM objects. The syntax will be the same as for the ORGANISATION object: > abuse-c: [optional] [single] [inverse key] > > The Abuse Finder logic will be updated to use the first "abuse-c:" found in this order of priority: > -the local "abuse-c:" in the resource object > -the "abuse-c:" in an ORGANISATION object referenced by the "org:" attribute in the resource object > -search up the resource object hierarchy (less specific objects) > --the "abuse-c:" in the less specific resource object > --the "abuse-c:" in an ORGANISATION object referenced by the "org:" attribute in the less specific resource object > > The search will stop when the top level resource object is reached. > > In addition to this we plan to introduce a business rule that will disallow “abuse-mailbox:” to be modified, or (re-)added to any object, other than ROLE objects. This will enable us to do a phased clean-up of this data without invalidating objects. We plan to have a whois release 1.90 for this (and the updated use of the ‘pn’ keyword mentioned under item #5 below) in the Release Candidate environment no later than Monday 2 October. We plan to deploy this version to production on Monday 16 October. > 2) Clean up of “abuse-mailbox:” on ORGANISATION objects > > Three cases exist: > > A) “abuse-mailbox:” is present and it is the same as the “abuse-mailbox:” in the also present “abuse-c:” reference (8919 cases) > > In this case we propose to simply delete the “abuse-mailbox:” attribute and inform the holder. We will work on a clear text for this email, but the main message would be: > "We removed “abuse-mailbox:” from your ORGANISATION object because this attribute is deprecated as the final step in the deployment of the "abuse-c:" attribute. However, we see that you were already using the preferred way to document abuse contact details for your organisation and you are referencing an “abuse-c:” ROLE object with the same email address in its its “abuse-mailbox:” attribute. No action is required.” > > > B) “abuse-mailbox:” is present and it is different from the “abuse-mailbox:” in the also present “abuse-c:” reference (1848 cases) > > Note that some of these cases have been caused by the fact that since the introduction of “abuse-c:” LIRs can no longer modify the value of the “abuse-mailbox:” attribute. The intent was that “abuse-mailbox:” would have been cleaned up earlier, but unfortunately that dit not happen. That being said “abuse-c:” has been kept up to date by the LIR, and out of the two is also the one that is being shown on the Abuse Finder. > > Therefore we propose to delete the “abuse-mailbox:” attribute in these cases, and send a different notification to the holder with the following main message: > > "We removed “abuse-mailbox:” with value $email from your ORGANISATION object because this attribute is deprecated as the final step in the deployment of the "abuse-c:" attribute. However, we see that you were already using the preferred way to document abuse contact details for your organisation and you are referencing an “abuse-c:” ROLE object with that uses $email_2 in its “abuse-mailbox:” attribute. If the latter is correct no action is required. However if you want to modify the email address in your “abuse-c:” ROLE object, you can do so here (link to webupdates).” > > > C) “abuse-mailbox:” is present, and there is no “abuse-c:” reference (28312 cases) > > We *could* create “abuse-c:” ROLE objects for these cases, using the same maintainers as the ORGANISATION object. However, the “abuse-mailbox:” attribute has not been shown in the Abuse Finder, and this change could lead to wrong or out-of-date addresses suddenly receiving abuse reports. Therefore we suggest that we delete the attribute instead, and send the following main message to the holder of the ORGANISATION object: > > "We removed “abuse-mailbox:” with value $email from your ORGANISATION object because this attribute is deprecated as the final step in the deployment of the "abuse-c:" attribute. However, if you wish to add an email address for abuse reports you can do so by editing your object here (link to web updates for the ORGANISATION object)." > > We plan to perform these clean-ups on Monday 30 October. > 3) Clean up of “abuse-mailbox:” on PERSON (89k cases), MNTNER (2500 cases) and IRT (238 cases) > > In these cases we propose to send a warning email to the holders of these objects with the following main message: > > “The “abuse-mailbox:” is deprecated on these object and will be removed in 4 weeks, if you want to set up abuse contact information on your resource objects you can do so by having a default “abuse-c:” on your ORGANISATION referenced by your resource objects, or possibly overriding that default with a specific “abuse-c:” reference on applicable resource objects." > > And then 4 weeks later we will preform the clean-up and refer back to this communication. On further reflection we would prefer to alter the plan, and just a single clean-up of these objects on Monday 30 October as well. This way the clean-up process will be consistent across all object types. Furthermore, there is no action to be taken on these objects and “abuse-mailbox:” on these objects is ignored in the Abuse Finder. In short there does not seem to be a strong motivation for bothering the holders of these objects twice. > 4) Clean up whois code > > Now that “abuse-mailbox:” only appears where it should, we will be able to update the whois code itself so that “abuse-mailbox:” is no longer syntactically allowed on objects other than ROLE objects. This will allow us to remove the business rule added in phase 1 and simplify the whois code and maintenance. We will also update the RIPE Database Documentation to reflect this. We plan to do this as part of a future whois 1.91 release, as yet unplanned. This clean-up will not change any publicly visible functionality. > > > 5) Inverse queries > > As requested we can change the behaviour of the “pn” short cut to also search for “abuse-c:” in inverse queries. I.e. one can use: > whois -r -i pn uk41-ripe > > Instead of: > whois -r -i abuse-c,admin-c,tech-c,zone-c,author uk41-ripe As mentioned above, we plan to include this in the whois 1.90 release. Kind regards Tim Bruijnzeels Assistant Manager Software Engineering RIPE NCC Database Group > On 4 Aug 2017, at 14:39, William Sylvester via db-wg <db-wg(a)ripe.net> wrote: > > > From: William Sylvester <william.sylvester(a)addrex.net> > Subject: NWI-7: abuse-c implementation plan > Date: 3 August 2017 at 21:12:06 GMT+2 > To: "db-wg(a)ripe.net" <db-wg(a)ripe.net> > > > Working group members, > > Based on the responses we have received for NWI-7 : Abuse-c implementation, there is a clear consensus for the proposed implementation that has been presented by Tim from RIPE NCC as written for improving "abuse-c:". > > At this time, the DB-WG co-chairs would like to ask the RIPE NCC to proceed with this implementation. > > Kind Regards, > > DB-WG Chairs > > > > >

1 0

Re: [db-wg] out of region routing in the RIPE Database
by Clement Cavadore 14 Aug '17

14 Aug '17

On Tue, 2017-07-18 at 15:26 +0200, Nick Hilliard via db-wg wrote: > > I am not in favour of having the RIPE database as an open-access > database on the basis that this mixes up two sets of data, > authoritative > and non-authoritative, and it it is impossible for someone casually > querying the database to determine which is which. > > Some people are inserting random route: objects into the database, and > those route: objects are being picked up by provisioning systems and > ending up configured on routers and IXP route servers. This enables > prefix hijacking, which is a pressing operational issue. I agree with Nick's position. It legitimates what seems to be rogue announcements, like for example 196.16.0.0/14, as mentionned recently on the NANOG mailing list (*). We should, IMHO not be able to insert out of region route(6) object without having a prior authentication mechanism, or making it be specially flagged, so the auto ACL system from upstreams wouldnt match it. (*) https://mailman.nanog.org/pipermail/nanog/2017-August/091954.html -- Clément Cavadore

1 0

Re: [db-wg] out of region routing in the RIPE Database
by Daniel Shaw 11 Aug '17

11 Aug '17

On 11/08/2017, 05:14, Randy Bush via db-wg typed: > >> >> databases. It's that they never have, and it's just the "way things >> have been done". It's always ended up that they *can* support multiple >> databases if asked to. > > when negotiating with a prospective peer, i would rather not add "you > will have to change operational practice and code for this to work." That is a good point. I would also rather not, generally. And that is the basis of my original fears around this something like a year ago. What I found in practise (so far) has been that when stated not as "you will *have* to change operations", but as "would it be possible for you to change operations for me?", the answer has usually been "Ok". I have to be honest, that was a surprise. - Daniel

1 0

Re: [db-wg] out of region routing in the RIPE Database
by Randy Bush 11 Aug '17

11 Aug '17

> That has proven to never really be an issue. When a network upstream > of another network says they don't support additional databases for > IRR, so far that has always proven to actually mean they've never > needed to think about supporting multiple databases, and never had the > demand to do the work to change that. > > In other words, it's not that they *can't* support other > databases. It's that they never have, and it's just the "way things > have been done". It's always ended up that they *can* support multiple > databases if asked to. when negotiating with a prospective peer, i would rather not add "you will have to change operational practice and code for this to work." randy

1 0

Re: [db-wg] out of region routing in the RIPE Database
by Daniel Shaw 10 Aug '17

10 Aug '17

Hi there, On 09/08/2017, 19:34, Stefan Ideler via db-wg typed: > > > As a result our route objects regardless of origin are noted in the RIPE database. Our upstreams use it to generate their prefix filters (and not all of them support multiple databases) I won't comment here on your specific use case or the overall reasoning or motivation for wanting to use the RIPE DB exclusively, even for resources that may come from various other regions. I have an opinion, but it's just that. An opinion. What I'd like to comment on is the excerpt above. Specifically about upstream providers not supporting multiple databases. That has proven to never really be an issue. When a network upstream of another network says they don't support additional databases for IRR, so far that has always proven to actually mean they've never needed to think about supporting multiple databases, and never had the demand to do the work to change that. In other words, it's not that they *can't* support other databases. It's that they never have, and it's just the "way things have been done". It's always ended up that they *can* support multiple databases if asked to. I speak from experience here. If you go back into the archives of this list, when this issue was first brought to the list, I responded with this exact fear: But what about the upstream support? Since then I've had the opportunity to speak to folks from some of the larger networks that are often someone's upstream on behalf of AFRINIC members from time to time, and also in my own capacity in the context of an RIR meeting event network. We've also encouraged member operators to just ask their upstreams to change. And this has proved to never have remained an issue to the best of my knowledge. Summary: While you may (or may not) have other good reasons for the RIPE DB to be open (or not), upstream support of alternates is not likely one of the reasons. Best regards, Daniel

1 0

Re: [db-wg] out of region routing in the RIPE Database
by Nick Hilliard 09 Aug '17

09 Aug '17

Stefan Ideler via db-wg wrote: > Being a member of multiple RIR's, the Ripe db is user friendly and a > scriptable database. I don't want to divide my as-sets and prefix > filter generation over 3 or more different database systems, with > the additional maintenance and in some cases even less verification. > Atleast my RIPE originating objects are secure and they make up the > majority of my prefixes. > > As a result our route objects regardless of origin are noted in the > RIPE database. Our upstreams use it to generate their prefix filters > (and not all of them support multiple databases) and as a result we > require all our downstream customers to have their AS/route objects > within the RIPE database as well. Several years ago, we planned this sort of approach via IXP Manager, but when we wrote the code to do it, we realised that this was a very limited and limiting mechanism for handling prefix list generation. It caused a lot of extra work for us in terms of support requirements and explaining to people that they had to do this. Several member organisations refused to comply and said they had no intention of changing their policies. The result of this was that we ended up not carrying traffic that we could alternatively have carried, and we annoyed our members. Not the best idea, in retrospect. We ended up having to be a lot more flexible on the issue. The best way we found to handle it was to allow any customer to be associated with any arbitrary IRR policy. E.g. one customer could use source: RIPE, ARIN and RADB, and another could use LACNIC, ALTDB and LEVEL3. It's actually pretty straightforward to implement this, and gives the advantage that you're no longer creating extra work for customers by forcing them to register their route: objects in IRRDBs where they wouldn't otherwise do so. The code for this is freely available on github.com/inex/IXP-Manager. I'm mentioning this because there is a serious security problem associated with permitting out-of-region objects in the RIPE database: this causes repeated, serious security problems with routing leakage on the Internet. This feature is being persistently abused by scammers and other criminals and is devaluing the integrity of the data in the RIPE IRRDB. Unless this problem is fixed, it's going to continue to be a problem indefinitely. We cannot fix it unless people fix their code. Nick

1 0

Re: out of region routing in the RIPE Database
by Stefan Ideler 09 Aug '17

09 Aug '17

Hi, > I would like to have the IRR kept open, we have space from various > regions and need to be able to make use of a single well known IRR in > order to register our policies and be able to mix our ASNs with our > space. >This might indeed be the way forward for "I have a customer in my RIPE >AS which has APNIC space and wants to document that in a way that that >provisioning tools can pick this with sufficient trust on data quality". I agree with the above. Being a member of multiple RIR's, the Ripe db is user friendly and a scriptable database. I don't want to divide my as-sets and prefix filter generation over 3 or more different database systems, with the additional maintenance and in some cases even less verification. Atleast my RIPE originating objects are secure and they make up the majority of my prefixes. As a result our route objects regardless of origin are noted in the RIPE database. Our upstreams use it to generate their prefix filters (and not all of them support multiple databases) and as a result we require all our downstream customers to have their AS/route objects within the RIPE database as well. As such I oppose removing the functionality to register "foreign route objects" and instead support that a proper verification solution between the different RIR's should be implemented (some examples described in this thread). Regards, Stefan Sent via RIPE Forum -- https://www.ripe.net/participate/mail/forum

1 0

Re: [db-wg] NWI-7: abuse-c implementation plan
by Tim Bruijnzeels 07 Aug '17

07 Aug '17

Dear working group, We will come back with a more detailed implementation time line later this week. Informally speaking we expect that we can do the technical work to prepare the phase-1 whois release in the coming weeks. We will probably have to plan the clean-up after the holidays. But, we will get back to you once we have a more definite plan. Kind regards, Tim Bruijnzeels Assistant Manager Software Engineering RIPE NCC Database Group > On 4 Aug 2017, at 14:39, William Sylvester via db-wg <db-wg(a)ripe.net> wrote: > > > From: William Sylvester <william.sylvester(a)addrex.net> > Subject: NWI-7: abuse-c implementation plan > Date: 3 August 2017 at 21:12:06 GMT+2 > To: "db-wg(a)ripe.net" <db-wg(a)ripe.net> > > > Working group members, > > Based on the responses we have received for NWI-7 : Abuse-c implementation, there is a clear consensus for the proposed implementation that has been presented by Tim from RIPE NCC as written for improving "abuse-c:". > > At this time, the DB-WG co-chairs would like to ask the RIPE NCC to proceed with this implementation. > > Kind Regards, > > DB-WG Chairs > > > > >

1 0

Re: [db-wg] out of region routing in the RIPE Database
by Lu Heng 04 Aug '17

04 Aug '17

Hi, I would like to have the IRR kept open, we have space from various regions and need to be able to make use of a single well known IRR in order to register our policies and be able to mix our ASNs with our space. It is very convenient to be able to use the RIPE IRR for that. I do see that authentication/verification against other RIR's Database is not done at the moment and can be abused and will support any simple mechanism put in place in order to fix that issue. But closing the IRR down for out of region resources far outweighs the negative side effects seen by typos and abuses that comes through from time to time. On 20 July 2017 at 15:41, Gert Doering via db-wg <db-wg(a)ripe.net> wrote: > > > ---------- Forwarded message ---------- > From: Gert Doering <gert(a)space.net> > To: Sander Steffann <sander(a)steffann.nl> > Cc: George Michaelson <ggm(a)algebras.org>, denis walker < > ripedenis(a)yahoo.co.uk>, Database WG <db-wg(a)ripe.net> > Bcc: > Date: Thu, 20 Jul 2017 09:41:09 +0200 > Subject: Re: [db-wg] out of region routing in the RIPE Database > Hi, > > On Tue, Jul 18, 2017 at 04:10:52PM +0200, Sander Steffann via db-wg wrote: > > > its a broken process. it inherently permits things to be said, which > > > should not have been said. > > > > Time to set up a joint IRR database where only authoritative data from > participating RIRs is stored? > > This might indeed be the way forward for "I have a customer in my RIPE > AS which has APNIC space and wants to document that in a way that that > provisioning tools can pick this with sufficient trust on data quality". > > (And no, RADB is not) > > Gert Doering > -- NetMaster > -- > have you enabled IPv6 on something today...? > > SpaceNet AG Vorstand: Sebastian v. Bomhard > Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann > D-80807 Muenchen HRB: 136055 (AG Muenchen) > Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 > > -- -- Kind regards. Lu

2 1

NWI-7: abuse-c implementation plan
by William Sylvester 03 Aug '17

03 Aug '17

Working group members, Based on the responses we have received for NWI-7 : Abuse-c implementation, there is a clear consensus for the proposed implementation that has been presented by Tim from RIPE NCC as written for improving "abuse-c:". At this time, the DB-WG co-chairs would like to ask the RIPE NCC to proceed with this implementation. Kind Regards, DB-WG Chairs

1 0

Re: [db-wg] out of region routing in the RIPE Database
by Sebastian Wiesinger 27 Jul '17

27 Jul '17

* Gert Doering via db-wg <db-wg(a)ripe.net> [2017-07-20 09:42]: > > > its a broken process. it inherently permits things to be said, which > > > should not have been said. > > > > Time to set up a joint IRR database where only authoritative data from participating RIRs is stored? > > This might indeed be the way forward for "I have a customer in my RIPE > AS which has APNIC space and wants to document that in a way that that > provisioning tools can pick this with sufficient trust on data quality". Yes please! Regards Sebastian -- GPG Key: 0x93A0B9CE (F4F6 B1A3 866B 26E9 450A 9D82 58A2 D94A 93A0 B9CE) 'Are you Death?' ... IT'S THE SCYTHE, ISN'T IT? PEOPLE ALWAYS NOTICE THE SCYTHE. -- Terry Pratchett, The Fifth Elephant

1 0

Call for Agenda Items DB-WG Meeting - RIPE75 - Dubai, UAE
by William Sylvester 25 Jul '17

25 Jul '17

Dear DB-WG Members, This is the call for agenda items for the DB-WG Meeting at RIPE75 at the Conrad Dubai in Dubai, UAE. Please submit agenda items or propose additional topics to be discussed both on the mailing list or direct to the WG Chairs at db-wg-chairs(a)ripe.net<mailto:db-wg-chairs@ripe.net> The DB-WG Meeting is scheduled for Wednesday, October 25th, starting at 14:00 local time, after lunch and before the coffee break. The length of our timeslot is 90 minutes. For the overall RIPE 74 meeting plan please refer to its most up-to-date version at https://ripe75.ripe.net/programme/meeting-plan/ Note: due to UAE law, confirmed speakers will need to submit a copy of their passport and contact information in advance of the meeting. More details are available here: https://ripe75.ripe.net/attend/dctm-requirements We are looking forward to another successful meeting in Dubai. Kind regards, William, Denis, & David DB WG Chairs

1 0

Re: [db-wg] out of region routing in the RIPE Database
by Gert Doering 20 Jul '17

20 Jul '17

Hi, On Tue, Jul 18, 2017 at 04:10:52PM +0200, Sander Steffann via db-wg wrote: > > its a broken process. it inherently permits things to be said, which > > should not have been said. > > Time to set up a joint IRR database where only authoritative data from participating RIRs is stored? This might indeed be the way forward for "I have a customer in my RIPE AS which has APNIC space and wants to document that in a way that that provisioning tools can pick this with sufficient trust on data quality". (And no, RADB is not) Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279

1 0

Re: [db-wg] out of region routing in the RIPE Database
by Nick Hilliard 19 Jul '17

19 Jul '17

denis walker via db-wg wrote: > Just for the record I have followed all previous discussions on this > issue over many years within the RIPE community. There have been many > (opposing) views expressed. I don't recall any consensus within the RIPE > community to expel all, or even just Afrinic, (foreign) ROUTE objects > from the RIPE Database. If I did miss that, maybe someone can point me > to the message on this or the ROUTING WG mailing lists where that > consensus was drawn. NWI3 was proposed last year. Several people supported the idea and no-one was against it, at least at the time it was suggested. Previously two people thought this was a bad idea (one of these people was you) and stated so on the mailing list. https://www.ripe.net/ripe/mail/archives/db-wg/2016-May/005241.html No formal declaration of consensus was drawn by the wg chairs, but in the circumstances it looked like there was overall support for the idea. As a result of what appeared to be a community mandate, the RIPE NCC started a project which was reported on at the Copenhagen and Madrid meetings: https://ripe72.ripe.net/archives/video/217/ https://ripe73.ripe.net/archives/video/1510/ As Piotr noted in Madrid, there is not yet consensus on how this project should move forward. Right now, I believe that this may be the sticking point. > Does Afrinic have a mandate, with a clear consensus, from the Afrinic > community for the migration of all Afrinic ROUTE objects from the RIPE > Database to the Afrinic Database? Has either community agreed anything > on the (re)creation of Afrinic ROUTE objects in the RIPE Database? The Afrinic people would be best placed to provide feedback on how this proposal has been received by the Afrinic community. Maybe Daniel could comment? Nick

1 0

Re: [db-wg] out of region routing in the RIPE Database
by Tim Bruijnzeels 18 Jul '17

18 Jul '17

> On 18 Jul 2017, at 17:03, Sander Steffann via db-wg <db-wg(a)ripe.net> wrote: > > > From: Sander Steffann <sander(a)steffann.nl> > Subject: Re: [db-wg] out of region routing in the RIPE Database > Date: 18 July 2017 at 16:10:09 GMT+2 > To: George Michaelson <ggm(a)algebras.org> > Cc: Nick Hilliard <nick(a)foobar.org>, Database WG <db-wg(a)ripe.net>, denis walker <ripedenis(a)yahoo.co.uk> > > > Hi George, > >> I think the previously stated position from APNIC region is clear: we >> have problems with the logistics which permit resources from our >> region to be included in IRR statements in the RIPE DB, when no formal >> check is made of permission or integrity, and we do not see any clear >> path to a deployable mechanism to provide authorization checks over >> resources from out of region. >> >> its a broken process. it inherently permits things to be said, which >> should not have been said. > > Time to set up a joint IRR database where only authoritative data from participating RIRs is stored? Thanks sander, we will certainly look into the options and report back to the wg group. Tim

2 1

out of region routing in the RIPE Database
by denis walker 18 Jul '17

18 Jul '17

Hi Daniel and others Just for the record I have followed all previous discussions on this issue over many years within the RIPE community. There have been many (opposing) views expressed. I don't recall any consensus within the RIPE community to expel all, or even just Afrinic, (foreign) ROUTE objects from the RIPE Database. If I did miss that, maybe someone can point me to the message on this or the ROUTING WG mailing lists where that consensus was drawn. Does Afrinic have a mandate, with a clear consensus, from the Afrinic community for the migration of all Afrinic ROUTE objects from the RIPE Database to the Afrinic Database? Has either community agreed anything on the (re)creation of Afrinic ROUTE objects in the RIPE Database? I have no personal interest in this either way. I just want to be clear what the current position is so we can move forward. cheersdenisco-chair DB-WG From: Daniel Shaw via db-wg <db-wg(a)ripe.net> To: Database WG <db-wg(a)ripe.net> Sent: Tuesday, 18 July 2017, 16:39 Subject: Re: [db-wg] out of region routing in the RIPE Database On 18/07/2017, 15:26, Nick Hilliard via db-wg typed: > > > There are two main ways to fix this problem: > > 1. change all non-RIPE address space to have a different source: tag > > 2. remove all non-RIPE address space completely > > There is some previous discussion about this issue on db-wg, and IIRC, > the WG suggestion was to go for option #2. > > On that basis, again IIRC, there was a suggestion to handle this in a > phased way, starting off with the lowest hanging fruit first. As > Afrinic objects formed the largest share of all out-of-region objects in > the ripedb, they were targeted first. Hello WG, That matches my recollection too. And so I'll re-iterate that, as previously mentioned on this list, this neatly matches up with some parallel goals within AFRINIC. Which is that regardless, we see an advantage in having our membership manage their IRR along with RDNS and RPKI and other registry interactions in one place under one authentication. Simpler. And we also see an advantage in general growth in usage of the AFRINIC IRR by our membership, as it's a service we already provide and will maintain and scale as needed in any case. And so, we do already provide tooling to our membership to assist them moving objects into the AFRINIC DB easily. We do liaise with upstream operators of our members when they have in the past implied a requirement for RIPE DB IRR objects. And our hostmasters also do run bootcamp tutorials at nog and other events to encourage migration of objects. In summary there is ongoing work that matches with migrating non-RIPE, AFRINIC route(6) objects underway. I will add that this is a long and slow process however. The work is done as convenient. And for now, only applies where both the IPv{4,6} an AS resources are within the AFRINIC region. The movement is slow. But in the direction of moving AFRINIC resources away from RIPE DB. Regards, Daniel

1 0