Re: [db-wg] A test on AFRINIC range announcing without RIPE route object
Hi On Sat, Jun 16, 2018 at 00:11 Daniel Suchy via db-wg wrote: > On 06/15/2018 04:52 PM, Lu Heng via db-wg wrote: > > Ripe and Afrinic, are not “someone else”, they are part of an unified RIR > > system that adminiatrating the numbers. > > The system is *not* unified. Each RIR has it's own policies, own rules, > own implementation of the database... Which exactly the cause the problem in the very first place, internet is one, we will need an unified registration system to clean up the current mass of DBs, but again, that’s another discussion. > > > > As Job suggested, let’s wait RIPE their plan and future discuss the > > timeline—If Afrinic haven’t fix things by then. > > I don't support this. With this approach we can also wait forever. If > some delay will be introduced, there must be exact timeline for that. > And probably we don't know, *when* AfriNIC fix it's database. I will try to have Afrinic put out an “exact” timeline, and I agree with you exact timeline is important. > > > As it was mentioned already, discussion already took place. It's AfriNIC > problem now. We cannot solve problems of other RIRs in local (RIPE) > database - just because there's lack of support elsewhere. That's (among > others) also security problem. From long term perspective - > legacy/foreign data from past needs to be removed, it's a garbage here > (in RIPEdb). World around us changes and there're so many people > misusing old features for nasty things novadays. > Again, I don’t disagree with fixing the problem, and I am victim of those abuse as well. Fundamentally, while internet is one, separate registration system cause the root of this very problem, if we have one database, we will not have a problem like this to fix to begin with. I will try my best to have Afrinic, and hopefully Other community member can join as well, to fix the IRR at an known time frame. > - Daniel > > -- -- Kind regards. Lu
Re: [db-wg] A test on AFRINIC range announcing without RIPE route object
On 06/15/2018 04:52 PM, Lu Heng via db-wg wrote: > Ripe and Afrinic, are not “someone else”, they are part of an unified RIR > system that adminiatrating the numbers. The system is *not* unified. Each RIR has it's own policies, own rules, own implementation of the database... > As Job suggested, let’s wait RIPE their plan and future discuss the > timeline—If Afrinic haven’t fix things by then. I don't support this. With this approach we can also wait forever. If some delay will be introduced, there must be exact timeline for that. And probably we don't know, *when* AfriNIC fix it's database. As it was mentioned already, discussion already took place. It's AfriNIC problem now. We cannot solve problems of other RIRs in local (RIPE) database - just because there's lack of support elsewhere. That's (among others) also security problem. From long term perspective - legacy/foreign data from past needs to be removed, it's a garbage here (in RIPEdb). World around us changes and there're so many people misusing old features for nasty things novadays. - Daniel
Re: [db-wg] A test on AFRINIC range announcing without RIPE route object
I don’t see and I don’t think it’s relevant. As Job suggested, let’s wait RIPE their plan and future discuss the timeline—If Afrinic haven’t fix things by then. In the meanwhile, I would hope globene community put joint effect to have Afrinic fix their IRRs. On Fri, Jun 15, 2018 at 23:54 Sandra Murphy via db-wg wrote: > > > On Jun 15, 2018, at 9:12 AM, Sascha Luck [ml] via db-wg > wrote: > > > > There is nothing stupid or unreasonable about asking to delay an > > action that *will* cause operational issues even if their root > > cause lies elsewhere. > > “Our operation relies on insecurity in the IRR database, so we want you to > maintain your insecurity so that we can maintain our operational design” > > Relaboring the point: It is not “*will* cause”. Using some other IRR > database would avoid the operational issue. > > This operational issue could also be avoided if someone with a maintainer > somewhere just proxy-registered a route object on their behalf. (Anyone > but me see irony in that?) > > —Sandy > -- -- Kind regards. Lu
Re: [db-wg] A test on AFRINIC range announcing without RIPE route object
> On Jun 15, 2018, at 9:12 AM, Sascha Luck [ml] via db-wg > wrote: > > There is nothing stupid or unreasonable about asking to delay an > action that *will* cause operational issues even if their root > cause lies elsewhere. “Our operation relies on insecurity in the IRR database, so we want you to maintain your insecurity so that we can maintain our operational design” Relaboring the point: It is not “*will* cause”. Using some other IRR database would avoid the operational issue. This operational issue could also be avoided if someone with a maintainer somewhere just proxy-registered a route object on their behalf. (Anyone but me see irony in that?) —Sandy
Re: [db-wg] A test on AFRINIC range announcing without RIPE route object
On Fri, Jun 15, 2018 at 23:50 Sandra Murphy wrote: > > > On Jun 15, 2018, at 8:55 AM, Lu Heng via db-wg wrote: > > > > It’s internet, one internet, and it belong to everyone. just don’t tell > someone else what must to be doing. > > Considering that you are asking RIPE to change RIPE's plans for what RIPE > does with RIPE’s database, I find this statement ironic. Ripe and Afrinic, are not “someone else”, they are part of an unified RIR system that adminiatrating the numbers. But again, I don’t think this part of discussion contribute to the topic on hand, so I will stop here. > > —Sandy -- -- Kind regards. Lu
Re: [db-wg] A test on AFRINIC range announcing without RIPE route object
> On Jun 15, 2018, at 8:55 AM, Lu Heng via db-wg wrote: > > It’s internet, one internet, and it belong to everyone. just don’t tell > someone else what must to be doing. Considering that you are asking RIPE to change RIPE's plans for what RIPE does with RIPE’s database, I find this statement ironic. —Sandy
Re: [db-wg] A test on AFRINIC range announcing without RIPE route object
On Fri, Jun 15, 2018 at 22:40 Job Snijders wrote: > Hi all, > > On Fri, Jun 15, 2018 at 3:37 PM, Lu Heng via db-wg wrote: > > On Fri, Jun 15, 2018 at 22:16 denis walker via db-wg > wrote: > >> > >> Lu, the point being made is that RIPE (community, working groups, > chairs, > >> NCC) have no authority to change policies or procedures in the AFRINIC > >> region. If you believe that AFRINIC refuses to create ROUTE objects > simply > >> because you do not 'own' the ASN and that causes AFRINIC address space > >> holders operational problems, then we are 'suggesting' that you raise > this > >> issue on the appropriate AFRINIC mailing list. Then this issue can be > >> discussed and addressed appropriately. > > > > > > I am asking ripe pause for a brief moment so in the meantime we can have > > Afrinic sort the issue-in which I guess technically it is quite easy. > > The issue has been raised in Afrinic. > > Please note that RIPE NCC has not yet published a timeline for their > implementation plan. > > I propose we wait before asking for delays until it is clear what RIPE > NCC considers a feasible timeline from their perspective. :-) > And hopefully...with joint community effect, we can have Afrinic fix problem even before that. > > Kind regards, > > Job > -- -- Kind regards. Lu
Re: [db-wg] A test on AFRINIC range announcing without RIPE route object
Hi all, On Fri, Jun 15, 2018 at 3:37 PM, Lu Heng via db-wg wrote: > On Fri, Jun 15, 2018 at 22:16 denis walker via db-wg wrote: >> >> Lu, the point being made is that RIPE (community, working groups, chairs, >> NCC) have no authority to change policies or procedures in the AFRINIC >> region. If you believe that AFRINIC refuses to create ROUTE objects simply >> because you do not 'own' the ASN and that causes AFRINIC address space >> holders operational problems, then we are 'suggesting' that you raise this >> issue on the appropriate AFRINIC mailing list. Then this issue can be >> discussed and addressed appropriately. > > > I am asking ripe pause for a brief moment so in the meantime we can have > Afrinic sort the issue-in which I guess technically it is quite easy. > The issue has been raised in Afrinic. Please note that RIPE NCC has not yet published a timeline for their implementation plan. I propose we wait before asking for delays until it is clear what RIPE NCC considers a feasible timeline from their perspective. :-) Kind regards, Job
Re: [db-wg] A test on AFRINIC range announcing without RIPE route object
Hi denis: On Fri, Jun 15, 2018 at 22:16 denis walker via db-wg wrote: > Colleagues > > Please keep this calm and professional. > > Lu, the point being made is that RIPE (community, working groups, chairs, > NCC) have no authority to change policies or procedures in the AFRINIC > region. If you believe that AFRINIC refuses to create ROUTE objects simply > because you do not 'own' the ASN and that causes AFRINIC address space > holders operational problems, then we are 'suggesting' that you raise this > issue on the appropriate AFRINIC mailing list. Then this issue can be > discussed and addressed appropriately. > I am asking ripe pause for a brief moment so in the meantime we can have Afrinic sort the issue-in which I guess technically it is quite easy. The issue has been raised in Afrinic. And I will do my best to push them. > cheers > denis > co-chair DB-WG > > > -- > *From:* Lu Heng > *To:* Gert Doering > *Cc:* Database WG ; denis walker > *Sent:* Friday, 15 June 2018, 15:00 > > *Subject:* Re: [db-wg] A test on AFRINIC range announcing without RIPE > route object > > Hi > > On Fri, Jun 15, 2018 at 21:57 Gert Doering wrote: > > Hi, > > On Fri, Jun 15, 2018 at 09:55:14PM +0900, Lu Heng wrote: > > > Internet doesn't distingish *traffic*, but that is not the relevant > > > question here anyway. Address management, delegation and authority > > > are very clearly regionalized, so any beef you have with > Afrinic-delegated > > > space must be solved over there. > > > > It???s internet, one internet, and it belong to everyone. just don???t > tell > > someone else what must to be doing. > > Please learn to read. > > "Address management, delegation and authority are very clearly > regionalized", > which means you cannot just go to some place you find convenient and > complain > about problems elsewhere. > > > I don’t think I future responds to your personal allegation. > > > > Gert Doering > -- NetMaster > -- > have you enabled IPv6 on something today...? > > SpaceNet AG Vorstand: Sebastian v. Bomhard, Michael > Emmer > Joseph-Dollinger-Bogen 14 > <https://maps.google.com/?q=Joseph-Dollinger-Bogen+14&entry=gmail&source=g> > Aufsichtsratsvors.: A. Grundner-Culemann > D-80807 Muenchen HRB: 136055 (AG Muenchen) > Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 > > -- > -- > Kind regards. > > Lu > > > > -- -- Kind regards. Lu
Re: [db-wg] A test on AFRINIC range announcing without RIPE route object
Colleagues Please keep this calm and professional. Lu, the point being made is that RIPE (community, working groups, chairs, NCC) have no authority to change policies or procedures in the AFRINIC region. If you believe that AFRINIC refuses to create ROUTE objects simply because you do not 'own' the ASN and that causes AFRINIC address space holders operational problems, then we are 'suggesting' that you raise this issue on the appropriate AFRINIC mailing list. Then this issue can be discussed and addressed appropriately. cheersdenisco-chair DB-WG From: Lu Heng To: Gert Doering Cc: Database WG ; denis walker Sent: Friday, 15 June 2018, 15:00 Subject: Re: [db-wg] A test on AFRINIC range announcing without RIPE route object Hi On Fri, Jun 15, 2018 at 21:57 Gert Doering wrote: Hi, On Fri, Jun 15, 2018 at 09:55:14PM +0900, Lu Heng wrote: > > Internet doesn't distingish *traffic*, but that is not the relevant > > question here anyway. Address management, delegation and authority > > are very clearly regionalized, so any beef you have with Afrinic-delegated > > space must be solved over there. > > It???s internet, one internet, and it belong to everyone. just don???t tell > someone else what must to be doing. Please learn to read. "Address management, delegation and authority are very clearly regionalized", which means you cannot just go to some place you find convenient and complain about problems elsewhere. I don’t think I future responds to your personal allegation. Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard, Michael Emmer 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
Re: [db-wg] A test on AFRINIC range announcing without RIPE route object
Hi, On Fri, Jun 15, 2018 at 02:12:54PM +0100, Sascha Luck [ml] via db-wg wrote: > There is nothing stupid or unreasonable about asking to delay an > action that *will* cause operational issues even if their root > cause lies elsewhere. Since no existing objects will be removed, it will not break anything relying on these objects today. New objects cannot be created anymore, right. Which is the whole point. Job has pointed out alternatives if people feel they must create an unauthorized route: object somewhere. And this really is something that people need to discuss with their upstream providers how *those* do filtering, and what needs to be registered where. Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard, Michael Emmer Joseph-Dollinger-Bogen 14Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 signature.asc Description: PGP signature
Re: [db-wg] A test on AFRINIC range announcing without RIPE route object
On Fri, Jun 15, 2018 at 02:57:17PM +0200, Gert Doering via db-wg wrote: Please learn to read. "Address management, delegation and authority are very clearly regionalized", which means you cannot just go to some place you find convenient and complain about problems elsewhere. I would sort out my own comprehensive reading issues before complaining about others'. Lu is complaining that RIPE is rushing the implementation of this NWI and thereby creating a problem where one did not previously exist. Nobody disputes that the root cause lies in Afrinic and ultimately needs to be fixed there, but it is also true that the Internet is supposedly a cooperative effort and that resources from different RIRs are an operational reality (or the possibility of registering foreign resources in RIPEDB wouldn't have existed in the fist place.) There is nothing stupid or unreasonable about asking to delay an action that *will* cause operational issues even if their root cause lies elsewhere. rgds, Sascha Luck
Re: [db-wg] A test on AFRINIC range announcing without RIPE route object
Hi On Fri, Jun 15, 2018 at 21:57 Gert Doering wrote: > Hi, > > On Fri, Jun 15, 2018 at 09:55:14PM +0900, Lu Heng wrote: > > > Internet doesn't distingish *traffic*, but that is not the relevant > > > question here anyway. Address management, delegation and authority > > > are very clearly regionalized, so any beef you have with > Afrinic-delegated > > > space must be solved over there. > > > > It???s internet, one internet, and it belong to everyone. just don???t > tell > > someone else what must to be doing. > > Please learn to read. > > "Address management, delegation and authority are very clearly > regionalized", > which means you cannot just go to some place you find convenient and > complain > about problems elsewhere. I don’t think I future responds to your personal allegation. > > > Gert Doering > -- NetMaster > -- > have you enabled IPv6 on something today...? > > SpaceNet AG Vorstand: Sebastian v. Bomhard, Michael > Emmer > Joseph-Dollinger-Bogen 14Aufsichtsratsvors.: A. Grundner-Culemann > D-80807 Muenchen HRB: 136055 (AG Muenchen) > Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 > -- -- Kind regards. Lu
Re: [db-wg] A test on AFRINIC range announcing without RIPE route object
Hi, On Fri, Jun 15, 2018 at 09:55:14PM +0900, Lu Heng wrote: > > Internet doesn't distingish *traffic*, but that is not the relevant > > question here anyway. Address management, delegation and authority > > are very clearly regionalized, so any beef you have with Afrinic-delegated > > space must be solved over there. > > It???s internet, one internet, and it belong to everyone. just don???t tell > someone else what must to be doing. Please learn to read. "Address management, delegation and authority are very clearly regionalized", which means you cannot just go to some place you find convenient and complain about problems elsewhere. Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard, Michael Emmer Joseph-Dollinger-Bogen 14Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 signature.asc Description: PGP signature
Re: [db-wg] A test on AFRINIC range announcing without RIPE route object
Hi On Fri, Jun 15, 2018 at 21:53 Gert Doering wrote: > Hi, > > On Fri, Jun 15, 2018 at 09:48:12PM +0900, Lu Heng via db-wg wrote: > > RIR IRR should not work separately, as internet doesn???t distinguish > from > > ripe traffic to Afrinic traffic, we shouldn???t solve one problem here > and > > create another somewhere else. > > Internet doesn't distingish *traffic*, but that is not the relevant > question here anyway. Address management, delegation and authority > are very clearly regionalized, so any beef you have with Afrinic-delegated > space must be solved over there. It’s internet, one internet, and it belong to everyone. just don’t tell someone else what must to be doing. > > Gert Doering > -- NetMaster > -- > have you enabled IPv6 on something today...? > > SpaceNet AG Vorstand: Sebastian v. Bomhard, Michael > Emmer > Joseph-Dollinger-Bogen 14Aufsichtsratsvors.: A. Grundner-Culemann > D-80807 Muenchen HRB: 136055 (AG Muenchen) > Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 > -- -- Kind regards. Lu
Re: [db-wg] A test on AFRINIC range announcing without RIPE route object
Hi, On Fri, Jun 15, 2018 at 09:48:12PM +0900, Lu Heng via db-wg wrote: > RIR IRR should not work separately, as internet doesn???t distinguish from > ripe traffic to Afrinic traffic, we shouldn???t solve one problem here and > create another somewhere else. Internet doesn't distingish *traffic*, but that is not the relevant question here anyway. Address management, delegation and authority are very clearly regionalized, so any beef you have with Afrinic-delegated space must be solved over there. Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard, Michael Emmer Joseph-Dollinger-Bogen 14Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 signature.asc Description: PGP signature
Re: [db-wg] A test on AFRINIC range announcing without RIPE route object
Hi denis: Job already did ask in their mailling and that was the situation. RIR IRR should not work separately, as internet doesn’t distinguish from ripe traffic to Afrinic traffic, we shouldn’t solve one problem here and create another somewhere else. But again, I am asking the community to allow Afrinic some time to fix their IRR, end of the day, we want to a more functional internet not an more broken one. RADB is an alternative we are currently looking into, but then again, it is best to have RIR’ IRR working as expected. With regards. Lu On Fri, Jun 15, 2018 at 21:11 denis walker wrote: > Hi Job > > This is not my understanding. But please, someone raise this specific > issue on an AFRINIC mailing list and get an official response from AFRINIC. > It is pointless debating it here. > > cheers > denis > co-chair DB-WG > > -- > *From:* Job Snijders > *To:* denis walker > *Cc:* Lu Heng ; Database WG > *Sent:* Friday, 15 June 2018, 14:03 > *Subject:* Re: [db-wg] A test on AFRINIC range announcing without RIPE > route object > > Dear Denis, > > On Fri, Jun 15, 2018 at 1:58 PM, denis walker via db-wg > wrote: > > My current understanding is that AFRINIC does not refuse to create a > ROUTE > > simply because you do not own the foreign ASN. They may do some > additional > > checks, but if everything is in order they will permit the ROUTE > creation. > > So this is not a show stopper. > > > It turns out that AfriNIC will allow you to set any African Origin ASN > - but only allows foreign ASNs as "Origin ASN" iff the prefix holder > and the ASN holder are the same organisation. This is why > organisations that lease AfriNIC IP space out to to non-AfriNIC ASNs > must use RADB, RIPE, NTTCOM, ALTDB, etc where these restrictions do > not apply. > > This restriction does not apply when creating RPKI ROAs - when > creating a ROA the prefix holder can simply input any ASN regardless > of whether it is an AfriNIC managed resource or not. > > Kind regards, > > Job > > > > -- -- Kind regards. Lu
Re: [db-wg] A test on AFRINIC range announcing without RIPE route object
Hi Job This is not my understanding. But please, someone raise this specific issue on an AFRINIC mailing list and get an official response from AFRINIC. It is pointless debating it here. cheersdenisco-chair DB-WG From: Job Snijders To: denis walker Cc: Lu Heng ; Database WG Sent: Friday, 15 June 2018, 14:03 Subject: Re: [db-wg] A test on AFRINIC range announcing without RIPE route object Dear Denis, On Fri, Jun 15, 2018 at 1:58 PM, denis walker via db-wg wrote: > My current understanding is that AFRINIC does not refuse to create a ROUTE > simply because you do not own the foreign ASN. They may do some additional > checks, but if everything is in order they will permit the ROUTE creation. > So this is not a show stopper. It turns out that AfriNIC will allow you to set any African Origin ASN - but only allows foreign ASNs as "Origin ASN" iff the prefix holder and the ASN holder are the same organisation. This is why organisations that lease AfriNIC IP space out to to non-AfriNIC ASNs must use RADB, RIPE, NTTCOM, ALTDB, etc where these restrictions do not apply. This restriction does not apply when creating RPKI ROAs - when creating a ROA the prefix holder can simply input any ASN regardless of whether it is an AfriNIC managed resource or not. Kind regards, Job
Re: [db-wg] A test on AFRINIC range announcing without RIPE route object
Dear Denis, On Fri, Jun 15, 2018 at 1:58 PM, denis walker via db-wg wrote: > My current understanding is that AFRINIC does not refuse to create a ROUTE > simply because you do not own the foreign ASN. They may do some additional > checks, but if everything is in order they will permit the ROUTE creation. > So this is not a show stopper. It turns out that AfriNIC will allow you to set any African Origin ASN - but only allows foreign ASNs as "Origin ASN" iff the prefix holder and the ASN holder are the same organisation. This is why organisations that lease AfriNIC IP space out to to non-AfriNIC ASNs must use RADB, RIPE, NTTCOM, ALTDB, etc where these restrictions do not apply. This restriction does not apply when creating RPKI ROAs - when creating a ROA the prefix holder can simply input any ASN regardless of whether it is an AfriNIC managed resource or not. Kind regards, Job
Re: [db-wg] A test on AFRINIC range announcing without RIPE route object
Hi Lu My current understanding is that AFRINIC does not refuse to create a ROUTE simply because you do not own the foreign ASN. They may do some additional checks, but if everything is in order they will permit the ROUTE creation. So this is not a show stopper. As a side note, if you have concerns about AFRINIC you are better to raise these points on an AFRINIC mailing list. It may be of interest to the RIPE community how other regions work, but you will never change AFRINIC policies or procedures by complaining about them on a RIPE mailing list. cheersdenisco-chair DB-WG From: Lu Heng via db-wg To: Database WG Sent: Wednesday, 13 June 2018, 12:19 Subject: [db-wg] A test on AFRINIC range announcing without RIPE route object Current situation: AFRINIC accepts foreign ASN with manual verification of the ownership of the ASN holder as stated by their hostmaster in the mailing list. If you don't own the ASN, they will not create the route object. Despite this, the process is long and unpractical in daily operation.
Re: [db-wg] A test on AFRINIC range announcing without RIPE route object
Hi Sean: I am supporting the proposal. But disagree the implementation details. The current implementation would solve one problem in one place but create another one in another place—and such situation can be totally avoid by let AFRINIC fix their IRR first then we continues implementation after. On Fri, Jun 15, 2018 at 02:19 Sean Stuart wrote: > Hi Lu, > > Are you disagreeing with the proposal, or disagreeing with the > implementation details? I have seen several requests to delay > implementation, but none with a valid technical reason to not close a > security flaw. As I brought up at the microphone, I would love to see a > solution built that would allow me to use address space allocated by all > RIRs where I am a member in any of their IRR systems. However, that is out > of scope for this proposal and would likely require a proposal to all five > RIRs to build an authenticated method of validating and documenting IRR > records. Please feel free to correct me if there was a technical reason to > continue allowing unvalidated space in the RIPE IRR. > > Thanks, > Sean > > On Jun 14, 2018, at 12:23 PM, Lu Heng via db-wg wrote: > > Hi Denis: > > Consensus is neither unanimity nor majority. > > Below is a quotation from RFC: > > "quite often we are letting the majority win the day without > consideration of minority concerns. " > > "Lack of disagreement is more important than agreement" > > "Rough consensus is achieved when all issues are addressed, but not > necessarily accommodated" > > We have a disagreement because one of the critical issues of our current > network is not addressed. > > If there is one strong disagreement without valid counter argument, the > disagreement/issue is therefore not addressed. > > I believe the issue raised in the thread is not properly addressed > therefore there is no actual consensus. > > That being said, we appreciate the community effort to have all the RIR > co-operated together to fix their IRR, and we also support stopping > abuse(even if only to a certain degree) in the ripe database. > > Moreover, I do realize procedurally, we were not here in the list while > the consensus was reached. > > The current process will have my full support if RIR system's IRR can be > fixed as a whole, rather than just having one more problem created in > another place. > > > > > > On 14 June 2018 at 22:57, denis walker via db-wg wrote: > >> Hi All >> >> The co-chairs of the DB-WG are talking in the background to the RIRs >> about how this change will impact the holders of their address space. We >> are following the points raised here and checking some issues with the >> appropriate RIRs. The RIPE NCC Database team is also in the loop of these >> talks so any relevant points can be included in their impact analysis. >> >> As some have already said consensus is not unanimity and there is a >> consensus to close this security hole in the RIPE Database. Even though the >> security hole will continue to exist in many alternative and commercial >> IRRs and will continue to be exploited by abusers for some considerable >> time. >> >> cheers >> denis >> co-chair DB-WG >> >> > > > -- > -- > Kind regards. > Lu > > -- -- Kind regards. Lu
Re: [db-wg] A test on AFRINIC range announcing without RIPE route object
Hi Lu, Are you disagreeing with the proposal, or disagreeing with the implementation details? I have seen several requests to delay implementation, but none with a valid technical reason to not close a security flaw. As I brought up at the microphone, I would love to see a solution built that would allow me to use address space allocated by all RIRs where I am a member in any of their IRR systems. However, that is out of scope for this proposal and would likely require a proposal to all five RIRs to build an authenticated method of validating and documenting IRR records. Please feel free to correct me if there was a technical reason to continue allowing unvalidated space in the RIPE IRR. Thanks, Sean > On Jun 14, 2018, at 12:23 PM, Lu Heng via db-wg wrote: > > Hi Denis: > > Consensus is neither unanimity nor majority. > > Below is a quotation from RFC: > > "quite often we are letting the majority win the day without consideration of > minority concerns. " > > "Lack of disagreement is more important than agreement" > > "Rough consensus is achieved when all issues are addressed, but not > necessarily accommodated" > > We have a disagreement because one of the critical issues of our current > network is not addressed. > > If there is one strong disagreement without valid counter argument, the > disagreement/issue is therefore not addressed. > > I believe the issue raised in the thread is not properly addressed therefore > there is no actual consensus. > > That being said, we appreciate the community effort to have all the RIR > co-operated together to fix their IRR, and we also support stopping > abuse(even if only to a certain degree) in the ripe database. > > Moreover, I do realize procedurally, we were not here in the list while the > consensus was reached. > > The current process will have my full support if RIR system's IRR can be > fixed as a whole, rather than just having one more problem created in another > place. > > > > > >> On 14 June 2018 at 22:57, denis walker via db-wg wrote: >> Hi All >> >> The co-chairs of the DB-WG are talking in the background to the RIRs about >> how this change will impact the holders of their address space. We are >> following the points raised here and checking some issues with the >> appropriate RIRs. The RIPE NCC Database team is also in the loop of these >> talks so any relevant points can be included in their impact analysis. >> >> As some have already said consensus is not unanimity and there is a >> consensus to close this security hole in the RIPE Database. Even though the >> security hole will continue to exist in many alternative and commercial IRRs >> and will continue to be exploited by abusers for some considerable time. >> >> cheers >> denis >> co-chair DB-WG >> > > > > -- > -- > Kind regards. > Lu >
Re: [db-wg] A test on AFRINIC range announcing without RIPE route object
Hi Denis: Consensus is neither unanimity nor majority. Below is a quotation from RFC: "quite often we are letting the majority win the day without consideration of minority concerns. " "Lack of disagreement is more important than agreement" "Rough consensus is achieved when all issues are addressed, but not necessarily accommodated" We have a disagreement because one of the critical issues of our current network is not addressed. If there is one strong disagreement without valid counter argument, the disagreement/issue is therefore not addressed. I believe the issue raised in the thread is not properly addressed therefore there is no actual consensus. That being said, we appreciate the community effort to have all the RIR co-operated together to fix their IRR, and we also support stopping abuse(even if only to a certain degree) in the ripe database. Moreover, I do realize procedurally, we were not here in the list while the consensus was reached. The current process will have my full support if RIR system's IRR can be fixed as a whole, rather than just having one more problem created in another place. On 14 June 2018 at 22:57, denis walker via db-wg wrote: > Hi All > > The co-chairs of the DB-WG are talking in the background to the RIRs about > how this change will impact the holders of their address space. We are > following the points raised here and checking some issues with the > appropriate RIRs. The RIPE NCC Database team is also in the loop of these > talks so any relevant points can be included in their impact analysis. > > As some have already said consensus is not unanimity and there is a > consensus to close this security hole in the RIPE Database. Even though the > security hole will continue to exist in many alternative and commercial > IRRs and will continue to be exploited by abusers for some considerable > time. > > cheers > denis > co-chair DB-WG > > -- -- Kind regards. Lu
Re: [db-wg] A test on AFRINIC range announcing without RIPE route object
Hi All The co-chairs of the DB-WG are talking in the background to the RIRs about how this change will impact the holders of their address space. We are following the points raised here and checking some issues with the appropriate RIRs. The RIPE NCC Database team is also in the loop of these talks so any relevant points can be included in their impact analysis. As some have already said consensus is not unanimity and there is a consensus to close this security hole in the RIPE Database. Even though the security hole will continue to exist in many alternative and commercial IRRs and will continue to be exploited by abusers for some considerable time. cheersdenisco-chair DB-WG
Re: [db-wg] A test on AFRINIC range announcing without RIPE route object
I personally think the highest priority for RIPE should be to clean up the security of the RIPE database to reduce the ability to use it for undesired purposes. Once the database is locked down to ensure that only authenticated RIPE members can register space that is registered to them, then we can look at ways to make it easier for members with space from multiple regions. Until then, as Job pointed out, there are IRR’s available to manage announcements of space consistently globally. > On Jun 13, 2018, at 8:03 AM, Lu Heng via db-wg wrote: > > The ultimate discussion should be, and will be, is it RIPE net or internet? > > I am saying the current situation will break network by forbidding change it, > and it is network we break, really doesn’t matter where it is which registry > it from. > > We are victims of massive hijacking, many of my space get registered without > our knowledge as well, we spend time and money monitoring ripe dB for none > authorised registration as well, I wish I don’t have to do it, I wish Afrinic > IRR can function properly tomorrow, but until then, now ripe dB is our most > visiable solution. > > I hope we can make effect together to get Afrinic fix their IRR, it is > internet, it’s not just “Afrinic people business”, it is all of us’s > business, internet is one. > > And until then, I think there is not enough consensus from the community to > implement this change in the future. I would > like to ask the chair, how can we ask RIPE to pause this implementation? > > > >> On Wed, Jun 13, 2018 at 19:11 Job Snijders wrote: >> On Wed, Jun 13, 2018 at 10:56 AM, Lu Heng wrote: >> > Internet is one, and this is a general problem of all Afrinic space, just >> > don’t make it personal please. >> >> I didn't intend to make anything personal, so phrased differently: >> What you highlight is ultimately a problem between AfriNIC members and >> the AfriNIC organisation. >> >> > I hope Afrinic fix it rather soon that way every thing works, until then, >> > prevent network change is one way of breaking it. >> >> I am sympathetic, but RIPE has no obligation to keep a glaring >> security hole open to accommodate another RIR's lack of expedience. >> >> As I mentioned at the microphone at the last DB-WG session, right now >> I can simply register ALL not-yet-registered IP space in the RIPE NCC >> database and in doing so lock out anyone else from making any >> registrations for non-RIPE-managed space. There is nothing in place to >> stop anyone from doing so, this would immediately fix the security >> problem. I hope this both illustrates the size of the security hole >> and the problem of any business process relying on the existence of >> the hole. >> >> Kind regards, >> >> Job > -- > -- > Kind regards. > Lu >
Re: [db-wg] A test on AFRINIC range announcing without RIPE route object
i think the bottom line here is that the IRR, and by that i mean the total collection of IRR instances, is poorly secured by design. we can spend a lot of time with patches and workarounds, or we can take it for what it is and live with it. if you want security and authenticity by design, use the RPKI you can buy a wooden or a fiberglass sailboat. do you want to spend your life sanding or sailing? randy
Re: [db-wg] A test on AFRINIC range announcing without RIPE route object
> Why can't small ISPs use the IRR provided by the RIR? this may come as a shock, but not all isps are close to their regional rir. > You only end up in a third party IRR database (such as RADB) if you > have a prefix from AfriNIC and an ASN from RIPE. and hundreds of dollars per year > But if you could afford to buy/lease the prefix from the AfriNIC > member, I think you can afford to pay the RADB fee as well... some time look up "legacy prefixes". and address space is loaned and exchanged in many ways. get over it. [part of] our job is to make it easy for the small isps, not hard.
Re: [db-wg] A test on AFRINIC range announcing without RIPE route object
BUSH, RANDY, DBWGOPS would like to recall the message, "A test on AFRINIC range announcing without RIPE route object". ?
Re: [db-wg] A test on AFRINIC range announcing without RIPE route object
> [ off list ] well, it wasn't. thanks to header modification by broken do-gooder email software. do not modify email headers!!!
Re: [db-wg] A test on AFRINIC range announcing without RIPE route object
On Wed, Jun 13, 2018 at 09:39:52AM -0700, Randy Bush via db-wg wrote: > [ off list ] this was not offlist. > isps need the irr-based filtering 'telcoms' to use all the irr > instances, as small emerging economy isps can not afford radb and will > soon not be able to use ripe. so the attackers will use the irr > instance with lowest security to spoof. Why can't small ISPs use the IRR provided by the RIR? Those are free. APNIC, AFRINIC, RIPE and ARIN do not charge for their IRR services. If the ASN and the prefix both come from RIPE, you can register them in RIPE just fine. If they both come from Afrinic, you can register them just fine in the AfriNIC IRR. You only end up in a third party IRR database (such as RADB) if you have a prefix from AfriNIC and an ASN from RIPE. But if you could afford to buy/lease the prefix from the AfriNIC member, I think you can afford to pay the RADB fee as well... Kind regards, Job
Re: [db-wg] A test on AFRINIC range announcing without RIPE route object
[ off list ] isps need the irr-based filtering 'telcoms' to use all the irr instances, as small emerging economy isps can not afford radb and will soon not be able to use ripe. so the attackers will use the irr instance with lowest security to spoof. randy
Re: [db-wg] A test on AFRINIC range announcing without RIPE route object
> On Jun 13, 2018, at 9:23 AM, Lu Heng via db-wg wrote: > > I do not mean in the very least sense to delay an implementation unless the > risk shown by it is far too serious. So if it is just because no one notices > the problem in the very beginning (which I am trying to address now) Not true that no one noticed the problem. Lots of discussion of the problem on the working group list, which included why people want to register route objects in the RIPE db for non-RIPE resources. —Sandy
Re: [db-wg] A test on AFRINIC range announcing without RIPE route object
> On Jun 13, 2018, at 8:03 AM, Lu Heng via db-wg wrote: > > The ultimate discussion should be, and will be, is it RIPE net or internet? > > I am saying the current situation will break network by forbidding change it, > and it is network we break, really doesn’t matter where it is which registry > it from. > > We are victims of massive hijacking, many of my space get registered without > our knowledge as well, we spend time and money monitoring ripe dB for none > authorised registration as well, I wish I don’t have to do it, I wish Afrinic > IRR can function properly tomorrow, but until then, now ripe dB is our most > visiable solution. I do not understand your argument. You want to register your route object, good. Afrinic makes that difficult to do securely, so sorry. Your route object is “foreign” to RIPE. You recognize that the ability to register “foreign” route objects in RIPE is a security hole in RIPE. So your registered route objects are insecure in the RIPE db. You have experienced that insecurity first hand. You have not answered why any of the other IRRs would not suit your purposes just as well. Your registered route objects would be insecure in other IRRs, but no more insecure than in the RIPE db. “most visible solution” is not the same as “only solution”. If you can’t say why only RIPE provides your needs, there is no “break” in the network, and your argument is not persuasive. —Sandy > > I hope we can make effect together to get Afrinic fix their IRR, it is > internet, it’s not just “Afrinic people business”, it is all of us’s > business, internet is one. > > And until then, I think there is not enough consensus from the community to > implement this change in the future. I would > like to ask the chair, how can we ask RIPE to pause this implementation? > > > > On Wed, Jun 13, 2018 at 19:11 Job Snijders wrote: > On Wed, Jun 13, 2018 at 10:56 AM, Lu Heng wrote: > > Internet is one, and this is a general problem of all Afrinic space, just > > don’t make it personal please. > > I didn't intend to make anything personal, so phrased differently: > What you highlight is ultimately a problem between AfriNIC members and > the AfriNIC organisation. > > > I hope Afrinic fix it rather soon that way every thing works, until then, > > prevent network change is one way of breaking it. > > I am sympathetic, but RIPE has no obligation to keep a glaring > security hole open to accommodate another RIR's lack of expedience. > > As I mentioned at the microphone at the last DB-WG session, right now > I can simply register ALL not-yet-registered IP space in the RIPE NCC > database and in doing so lock out anyone else from making any > registrations for non-RIPE-managed space. There is nothing in place to > stop anyone from doing so, this would immediately fix the security > problem. I hope this both illustrates the size of the security hole > and the problem of any business process relying on the existence of > the hole. > > Kind regards, > > Job > -- > -- > Kind regards. > Lu >
Re: [db-wg] A test on AFRINIC range announcing without RIPE route object
Lu Heng via db-wg wrote on 13/06/2018 14:23: All I am asking here is to delay implementation and give Afrinic sometime to fix their IRR. I don't see a good reason to do this. Afrinic have a process in place to create route objects and there are other IRRDBs which can be used as an alternative. If the Afrinic process is too slow, then take it up with Afrinic and actually fix the problem rather than asking the RIPE community to implement workarounds for weaknesses in other RIRs' operational practices. Nick
Re: [db-wg] A test on AFRINIC range announcing without RIPE route object
Hi colleagues: I do not mean in the very least sense to delay an implementation unless the risk shown by it is far too serious. So if it is just because no one notices the problem in the very beginning (which I am trying to address now), does that mean we have to ignore it? A dangerous bridge cannot be built even in the very last minute, no matter how long it takes to implement that project, if one notices there’s a risk it may break. This bridge now is network. To ensure the network works, it’s all RIR, not just Afrinic’s reponsibility to take care of the matter. And as for the definition of consensus, yes, the consensus is declear by the chair. What I am referring to is the definition of rough consensus(not the “consensus” happened a couple of months ago), because the resolution is not acceptable by all parties, an accutral consensus is not yet achieved. Please do not confuse the process with that of consensus. All I am asking here is to delay implementation and give Afrinic sometime to fix their IRR. On Wed, Jun 13, 2018 at 20:27 Gert Doering wrote: > Hi, > > On Wed, Jun 13, 2018 at 08:11:34PM +0800, Lu Heng wrote: > > On Wed, Jun 13, 2018 at 20:10 Gert Doering wrote: > > > > > On Wed, Jun 13, 2018 at 08:03:20PM +0800, Lu Heng via db-wg wrote: > > > > And until then, I think there is not enough consensus from the > community > > > to > > > > implement this change in the future. > > > > > > This has been discussed extensively and there has been consensus to go > > > ahead with this. > > > > That???s a bullying answer. > > It's the way our community works. > > We discuss a problem, propose a solution, get agreement on problem and > solution, get an implementation plan, agree to this, and *then implement > it*. > > We do *not* go through all the process and stop right at the end because > someone decides to disagree *months after the time for discussion was > ended*. > > > An consensus define as an acceptable resolution to all parties, and we > > being one of the party find the solution unacceptable with sounding > > argument, therefore no consensus. > > Please read RFC7282 - while we're not the IETF, this is comparably to > the way the RIPE working groups operate wrt consensus and "someone is > always complaining". > > Gert Doering > -- NetMaster > -- > have you enabled IPv6 on something today...? > > SpaceNet AG Vorstand: Sebastian v. Bomhard, Michael > Emmer > Joseph-Dollinger-Bogen 14Aufsichtsratsvors.: A. Grundner-Culemann > D-80807 Muenchen HRB: 136055 (AG Muenchen) > Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 > -- -- Kind regards. Lu
Re: [db-wg] A test on AFRINIC range announcing without RIPE route object
Hi, On Wed, Jun 13, 2018 at 08:11:34PM +0800, Lu Heng wrote: > On Wed, Jun 13, 2018 at 20:10 Gert Doering wrote: > > > On Wed, Jun 13, 2018 at 08:03:20PM +0800, Lu Heng via db-wg wrote: > > > And until then, I think there is not enough consensus from the community > > to > > > implement this change in the future. > > > > This has been discussed extensively and there has been consensus to go > > ahead with this. > > That???s a bullying answer. It's the way our community works. We discuss a problem, propose a solution, get agreement on problem and solution, get an implementation plan, agree to this, and *then implement it*. We do *not* go through all the process and stop right at the end because someone decides to disagree *months after the time for discussion was ended*. > An consensus define as an acceptable resolution to all parties, and we > being one of the party find the solution unacceptable with sounding > argument, therefore no consensus. Please read RFC7282 - while we're not the IETF, this is comparably to the way the RIPE working groups operate wrt consensus and "someone is always complaining". Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard, Michael Emmer Joseph-Dollinger-Bogen 14Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 signature.asc Description: PGP signature
[db-wg] A test on AFRINIC range announcing without RIPE route object
Hello, On 06/13/2018 01:39 PM, Sascha Luck [ml] via db-wg wrote: > There was a time when it would have been seen as the obligation > of any RIR to keep the internet running as smoothly as possible. sometimes things needs to be really breaked to get fixed them. People are lazy, they're ignoring all notifications to fix "legacy" things, refusing changes, when things "currently" somewhat works for them. > IMO such actions should be delayed until there is a mechanism for > every resource holder to register their advertisements properly, > no matter where they are. Presumably this is something the RIRs > themselves could be pushing as they are coordinating among > themselves and with ICANN anyway. There's no reason for again delaying things from my perspective. It's problem on advertising (and relevant RIR) side, and there is easy option to fix root cause of their problem. Solution exists. With regards, Daniel
Re: [db-wg] A test on AFRINIC range announcing without RIPE route object
Lu Heng via db-wg wrote on 13/06/2018 13:11: On Wed, Jun 13, 2018 at 20:10 Gert Doering wrote: This has been discussed extensively and there has been consensus to go ahead with this. That’s a bullying answer. What Gert said was simply a statement of fact: https://www.ripe.net/ripe/mail/archives/db-wg/2017-October/005711.html You are welcome to disagree with the decision of the chairs, but that decision was made several months ago. An consensus define as an acceptable resolution to all parties, and we being one of the party find the solution unacceptable with sounding argument, therefore no consensus. RIPE working groups tend to follow the rfc7282 definition, and have never considered unanimity to be grounds for consensus. Nick
Re: [db-wg] A test on AFRINIC range announcing without RIPE route object
On Wed, Jun 13, 2018 at 20:10 Gert Doering wrote: > Hi, > > On Wed, Jun 13, 2018 at 08:03:20PM +0800, Lu Heng via db-wg wrote: > > And until then, I think there is not enough consensus from the community > to > > implement this change in the future. > > This has been discussed extensively and there has been consensus to go > ahead with this. That’s a bullying answer. An consensus define as an acceptable resolution to all parties, and we being one of the party find the solution unacceptable with sounding argument, therefore no consensus. > > Gert Doering > -- NetMaster > -- > have you enabled IPv6 on something today...? > > SpaceNet AG Vorstand: Sebastian v. Bomhard, Michael > Emmer > Joseph-Dollinger-Bogen 14Aufsichtsratsvors.: A. Grundner-Culemann > D-80807 Muenchen HRB: 136055 (AG Muenchen) > Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 > -- -- Kind regards. Lu
Re: [db-wg] A test on AFRINIC range announcing without RIPE route object
Hi, On Wed, Jun 13, 2018 at 08:03:20PM +0800, Lu Heng via db-wg wrote: > And until then, I think there is not enough consensus from the community to > implement this change in the future. This has been discussed extensively and there has been consensus to go ahead with this. Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard, Michael Emmer Joseph-Dollinger-Bogen 14Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 signature.asc Description: PGP signature
Re: [db-wg] A test on AFRINIC range announcing without RIPE route object
The ultimate discussion should be, and will be, is it RIPE net or internet? I am saying the current situation will break network by forbidding change it, and it is network we break, really doesn’t matter where it is which registry it from. We are victims of massive hijacking, many of my space get registered without our knowledge as well, we spend time and money monitoring ripe dB for none authorised registration as well, I wish I don’t have to do it, I wish Afrinic IRR can function properly tomorrow, but until then, now ripe dB is our most visiable solution. I hope we can make effect together to get Afrinic fix their IRR, it is internet, it’s not just “Afrinic people business”, it is all of us’s business, internet is one. And until then, I think there is not enough consensus from the community to implement this change in the future. I would like to ask the chair, how can we ask RIPE to pause this implementation? On Wed, Jun 13, 2018 at 19:11 Job Snijders wrote: > On Wed, Jun 13, 2018 at 10:56 AM, Lu Heng wrote: > > Internet is one, and this is a general problem of all Afrinic space, just > > don’t make it personal please. > > I didn't intend to make anything personal, so phrased differently: > What you highlight is ultimately a problem between AfriNIC members and > the AfriNIC organisation. > > > I hope Afrinic fix it rather soon that way every thing works, until then, > > prevent network change is one way of breaking it. > > I am sympathetic, but RIPE has no obligation to keep a glaring > security hole open to accommodate another RIR's lack of expedience. > > As I mentioned at the microphone at the last DB-WG session, right now > I can simply register ALL not-yet-registered IP space in the RIPE NCC > database and in doing so lock out anyone else from making any > registrations for non-RIPE-managed space. There is nothing in place to > stop anyone from doing so, this would immediately fix the security > problem. I hope this both illustrates the size of the security hole > and the problem of any business process relying on the existence of > the hole. > > Kind regards, > > Job > -- -- Kind regards. Lu
Re: [db-wg] A test on AFRINIC range announcing without RIPE route object
Dear Denis, On Wed, Jun 13, 2018 at 11:45:24AM +, denis walker wrote: > >> In conclusion, If you employ a non-Afrinic asn for announcements > >> (which means a foreign asn), using RIPE’s route object will be the > >> only choice for you unless you are one of those big telecoms which > >> has the liberty to announce anything as they wish. > > > This is not correct, you can also use RADB, NTTCOM, LEVEL3, or > > ALTDB, etc. RIPE is/was not an exclusive provider for this type of > > service. > > (wearing my devil's advocate hat)... So are you saying all these > other databases offer the same service with the same security risk > that we are about to remove from the RIPE Database? That is (currently) correct. > None of these databases have any authorisation link to any of the > RIR's address registries. So can anyone create bogus ROUTE objects in > these databases for any address space? Suggesting that people can use > these databases implies that their contents are taken seriously, > including any bogus ROUTE objects. Correct. But you may recall my presentation from RIPE 76 that NTT is sponsoring a full rewrite of IRRd to be able to extend IRRd. One of the possible (and desired) extensions is an authorisation link to the authoritative RIR. Progress can be tracked here https://github.com/irrdnet/irrd4 Another aspect related to third party IRRs is to leverage RPKI data to clean up stale/rogue IRR entries, or prevent creation such not-validated route-objects. I'm very excited about having a modern IRRd and being able to innovate in this problem space. We've received commitment from multiple third party IRR operators that they'll switch to the new code bsae. In summary, the third party IRRs are insecure, and work is being done to address that issue. I love talking about those road maps but I feel this is somewhat out of scope for the RIPE database working group. > So by closing down this service in the RIPE Database are we solving a > problem (closing a security hole) or just moving the problem somewhere > else? No, we are not "just moving the problem". "Moving" would mean that the problem currently does not exist the other place and would be opened up if RIPE makes its move. The problem exists in multiple places, these must be addressed one by one. Closing down this security problem in the RIPE database is literally just that: it removes one of the security problems from the eco-system. When this is done, we move to the next problem until there is nothing left on the list. > Ideally all 5 RIRs should operate an IRR with authorisation linked to > the address registrations and not required from any ASN. Then we > would have a place to put ROUTE objects that can be trusted. This literally already exists and is called RPKI. :-) Kind regards, Job
Re: [db-wg] A test on AFRINIC range announcing without RIPE route object
Sascha Luck [ml] via db-wg wrote on 13/06/2018 12:39: Secondly, there is an unintended consequence to this, namely that, if you make it impossible for a segment of resource holders to register their routes properly, some transit providers and IXPs will have no choice but to accept their advertisements anyway without any filter. How that improves 'security', I don't know. there's nothing stopping people from contacting Afrinic to fix this problem or in a pinch, registering their routes in RADB. I'd be more sympathetic to being lax about this if the RIPE IRRDB weren't constantly targeted for abuse and if there weren't a stream of malicious bgp injection attacks which used fraudulent registrations in the RIPE IRRDB. Just like open smtp relays, open DNS resolvers and open NTP servers, a tiny number of people abuse open systems to the detriment of others. Like you, I view the situation as being both tragic and self-destructive, but as internet operators we have an obligation to ensure that we don't end up with a tragedy of the commons situation where the value of the IRRDBs is permanently destroyed by persistent abusers. Closing off access to the third party registrations in the RIPE IRRDB the lesser of the two evils, and it's deeply unfortunate that that we've been backed into this corner. Nick
Re: [db-wg] A test on AFRINIC range announcing without RIPE route object
On Wed, Jun 13, 2018 at 12:39:49PM +0100, Sascha Luck [ml] via db-wg wrote: > On Wed, Jun 13, 2018 at 11:11:09AM +, Job Snijders via db-wg wrote: > > I am sympathetic, but RIPE has no obligation to keep a glaring > > security hole open to accommodate another RIR's lack of expedience. > > There was a time when it would have been seen as the obligation of any > RIR to keep the internet running as smoothly as possible. This boat > seems to have sailed and not just in an internet context.This > paradigm shift mirrors one in general society as well, where it has > become acceptable to cause any amount of pain and inconvenience to the > general population in the name of 'security'... The above would be true if there was no alternatives and RIPE NCC was the exclusive provider of this registration service. However, as I pointed out before you can simply register your routes in other IRRs. > Secondly, there is an unintended consequence to this, namely that, if > you make it impossible for a segment of resource holders to register > their routes properly, some transit providers and IXPs will have no > choice but to accept their advertisements anyway without any filter. > How that improves 'security', I don't know. As pointed out, it is not impossible. > IMO such actions should be delayed until there is a mechanism for > every resource holder to register their advertisements properly, no > matter where they are. Presumably this is something the RIRs > themselves could be pushing as they are coordinating among themselves > and with ICANN anyway. Such a mechanism already exists. There is the RPKI registration system and there are multiple IRR systems. Kind regards, Job
Re: [db-wg] A test on AFRINIC range announcing without RIPE route object
Hi Job From: Job Snijders via db-wg To: Lu Heng Cc: Database WG Sent: Wednesday, 13 June 2018, 12:52 Subject: Re: [db-wg] A test on AFRINIC range announcing without RIPE route object >> >> In conclusion, If you employ a non-Afrinic asn for announcements >> (which means a foreign asn), using RIPE’s route object will be the >> only choice for you unless you are one of those big telecoms which has >> the liberty to announce anything as they wish. > This is not correct, you can also use RADB, NTTCOM, LEVEL3, or ALTDB, > etc. RIPE is/was not an exclusive provider for this type of service. (wearing my devil's advocate hat)... So are you saying all these other databases offer the same service with the same security risk that we are about to remove from the RIPE Database? None of these databases have any authorisation link to any of the RIR's address registries. So can anyone create bogus ROUTE objects in these databases for any address space? Suggesting that people can use these databases implies that their contents are taken seriously, including any bogus ROUTE objects. So by closing down this service in the RIPE Database are we solving a problem (closing a security hole) or just moving the problem somewhere else? Ideally all 5 RIRs should operate an IRR with authorisation linked to the address registrations and not required from any ASN. Then we would have a place to put ROUTE objects that can be trusted. cheersdenisco-chair DB-WG
Re: [db-wg] A test on AFRINIC range announcing without RIPE route object
On Wed, Jun 13, 2018 at 11:11:09AM +, Job Snijders via db-wg wrote: I am sympathetic, but RIPE has no obligation to keep a glaring security hole open to accommodate another RIR's lack of expedience. There was a time when it would have been seen as the obligation of any RIR to keep the internet running as smoothly as possible. This boat seems to have sailed and not just in an internet context. This paradigm shift mirrors one in general society as well, where it has become acceptable to cause any amount of pain and inconvenience to the general population in the name of 'security'... Secondly, there is an unintended consequence to this, namely that, if you make it impossible for a segment of resource holders to register their routes properly, some transit providers and IXPs will have no choice but to accept their advertisements anyway without any filter. How that improves 'security', I don't know. IMO such actions should be delayed until there is a mechanism for every resource holder to register their advertisements properly, no matter where they are. Presumably this is something the RIRs themselves could be pushing as they are coordinating among themselves and with ICANN anyway. rgds, Sascha Luck As I mentioned at the microphone at the last DB-WG session, right now I can simply register ALL not-yet-registered IP space in the RIPE NCC database and in doing so lock out anyone else from making any registrations for non-RIPE-managed space. There is nothing in place to stop anyone from doing so, this would immediately fix the security problem. I hope this both illustrates the size of the security hole and the problem of any business process relying on the existence of the hole. Kind regards, Job
Re: [db-wg] A test on AFRINIC range announcing without RIPE route object
+1 ... in CAPITAL LETTERS too. Regards, Peter Thimmesch -- hic sunt dracones On Jun 13, 2018, at 7:12 PM, Job Snijders via db-wg mailto:db-wg@ripe.net>> wrote: On Wed, Jun 13, 2018 at 10:56 AM, Lu Heng mailto:h...@anytimechinese.com>> wrote: Internet is one, and this is a general problem of all Afrinic space, just don’t make it personal please. I didn't intend to make anything personal, so phrased differently: What you highlight is ultimately a problem between AfriNIC members and the AfriNIC organisation. I hope Afrinic fix it rather soon that way every thing works, until then, prevent network change is one way of breaking it. I am sympathetic, but RIPE has no obligation to keep a glaring security hole open to accommodate another RIR's lack of expedience. As I mentioned at the microphone at the last DB-WG session, right now I can simply register ALL not-yet-registered IP space in the RIPE NCC database and in doing so lock out anyone else from making any registrations for non-RIPE-managed space. There is nothing in place to stop anyone from doing so, this would immediately fix the security problem. I hope this both illustrates the size of the security hole and the problem of any business process relying on the existence of the hole. Kind regards, Job
Re: [db-wg] A test on AFRINIC range announcing without RIPE route object
On Wed, Jun 13, 2018 at 10:56 AM, Lu Heng wrote: > Internet is one, and this is a general problem of all Afrinic space, just > don’t make it personal please. I didn't intend to make anything personal, so phrased differently: What you highlight is ultimately a problem between AfriNIC members and the AfriNIC organisation. > I hope Afrinic fix it rather soon that way every thing works, until then, > prevent network change is one way of breaking it. I am sympathetic, but RIPE has no obligation to keep a glaring security hole open to accommodate another RIR's lack of expedience. As I mentioned at the microphone at the last DB-WG session, right now I can simply register ALL not-yet-registered IP space in the RIPE NCC database and in doing so lock out anyone else from making any registrations for non-RIPE-managed space. There is nothing in place to stop anyone from doing so, this would immediately fix the security problem. I hope this both illustrates the size of the security hole and the problem of any business process relying on the existence of the hole. Kind regards, Job
Re: [db-wg] A test on AFRINIC range announcing without RIPE route object
Hi Job: Internet is one, and this is a general problem of all Afrinic space, just don’t make it personal please. I hope Afrinic fix it rather soon that way every thing works, until then, prevent network change is one way of breaking it. On Wed, Jun 13, 2018 at 18:52 Job Snijders wrote: > Dear Lu, > > On Wed, Jun 13, 2018 at 06:19:10PM +0800, Lu Heng via db-wg wrote: > > In the past three weeks, we have done some tests on 3 AFRINIC /24 > > which have been announced in the US, Europe, and Asia, by an ARIN ASN, > > APNIC ASN, and an RIPE ASN. > > > > Test results: > > > > If it is a direct announce to NTT, Telia, GTT as a small provider and > > without route object, announcement will not be accepted. > > It is of course expected and documented behavior. > https://www.us.ntt.net/support/policy/rr.cfm I am happy to learn that > competitors also reject announcements from their customers if no > route-object exists. > > > All of them accept RIPE route object. > > NTT would also accept the announcement if it were registered in any of > the other IRRs https://www.us.ntt.net/support/policy/routing.cfm#RR The > list of accepted IRRs differs from provider to provider. > > > Current situation: > > > > AFRINIC accepts foreign ASN with manual verification of the ownership > > of the ASN holder as stated by their hostmaster in the mailing list. > > If you don't own the ASN, they will not create the route object. > > Despite this, the process is long and unpractical in daily operation. > > For some context, here AfriNIC staff indicate they see no downside but > it is considered a low priority. > https://lists.afrinic.net/pipermail/dbwg/2018-June/53.html > > Another mail on the topic indicates that AfriNIC is taking it under > consideration to stop doing the useless manual verification: > https://lists.afrinic.net/pipermail/dbwg/2018-June/64.html > > The upside is that AfriNIC staff is properly informed and aware of > the effects of their constraints impose on operations. > > > Some providers do accept RPKI. One can create an AFRINIC RPKI that go > > though the filter, however, not all provider accept RPKI at the > > moment. > > > > In conclusion, If you employ a non-Afrinic asn for announcements > > (which means a foreign asn), using RIPE’s route object will be the > > only choice for you unless you are one of those big telecoms which has > > the liberty to announce anything as they wish. > > This is not correct, you can also use RADB, NTTCOM, LEVEL3, or ALTDB, > etc. RIPE is/was not an exclusive provider for this type of service. > > > I am not opposing to the idea of cleaning up the database, but until > > things get fixed, the current process will only break networks. > > Fortunately the current scheduled changes do not involve deleting > objects from the RIPE NCC IRR. So it will not break existing networks, > but it may inconvenience or delay provisioning if you are relying on a > security hole in the RIPE database. This is an important distinction. > > Ultimately this is a problem between you and AfriNIC. You are a member > of AfriNIC and you pay money to AfriNIC for them to provide you services > (such registration, IRR, and RPKI) and you currently you can't make good > use of those services. I hope AfriNIC will make the required changes > rather sooner than later. > > Kind regards, > > Job > -- -- Kind regards. Lu
Re: [db-wg] A test on AFRINIC range announcing without RIPE route object
Dear Lu, On Wed, Jun 13, 2018 at 06:19:10PM +0800, Lu Heng via db-wg wrote: > In the past three weeks, we have done some tests on 3 AFRINIC /24 > which have been announced in the US, Europe, and Asia, by an ARIN ASN, > APNIC ASN, and an RIPE ASN. > > Test results: > > If it is a direct announce to NTT, Telia, GTT as a small provider and > without route object, announcement will not be accepted. It is of course expected and documented behavior. https://www.us.ntt.net/support/policy/rr.cfm I am happy to learn that competitors also reject announcements from their customers if no route-object exists. > All of them accept RIPE route object. NTT would also accept the announcement if it were registered in any of the other IRRs https://www.us.ntt.net/support/policy/routing.cfm#RR The list of accepted IRRs differs from provider to provider. > Current situation: > > AFRINIC accepts foreign ASN with manual verification of the ownership > of the ASN holder as stated by their hostmaster in the mailing list. > If you don't own the ASN, they will not create the route object. > Despite this, the process is long and unpractical in daily operation. For some context, here AfriNIC staff indicate they see no downside but it is considered a low priority. https://lists.afrinic.net/pipermail/dbwg/2018-June/53.html Another mail on the topic indicates that AfriNIC is taking it under consideration to stop doing the useless manual verification: https://lists.afrinic.net/pipermail/dbwg/2018-June/64.html The upside is that AfriNIC staff is properly informed and aware of the effects of their constraints impose on operations. > Some providers do accept RPKI. One can create an AFRINIC RPKI that go > though the filter, however, not all provider accept RPKI at the > moment. > > In conclusion, If you employ a non-Afrinic asn for announcements > (which means a foreign asn), using RIPE’s route object will be the > only choice for you unless you are one of those big telecoms which has > the liberty to announce anything as they wish. This is not correct, you can also use RADB, NTTCOM, LEVEL3, or ALTDB, etc. RIPE is/was not an exclusive provider for this type of service. > I am not opposing to the idea of cleaning up the database, but until > things get fixed, the current process will only break networks. Fortunately the current scheduled changes do not involve deleting objects from the RIPE NCC IRR. So it will not break existing networks, but it may inconvenience or delay provisioning if you are relying on a security hole in the RIPE database. This is an important distinction. Ultimately this is a problem between you and AfriNIC. You are a member of AfriNIC and you pay money to AfriNIC for them to provide you services (such registration, IRR, and RPKI) and you currently you can't make good use of those services. I hope AfriNIC will make the required changes rather sooner than later. Kind regards, Job
[db-wg] A test on AFRINIC range announcing without RIPE route object
Dear colleagues, In the past three weeks, we have done some tests on 3 AFRINIC /24 which have been announced in the US, Europe, and Asia, by an ARIN ASN, APNIC ASN, and an RIPE ASN. Test results: If it is a direct announce to NTT, Telia, GTT as a small provider and without route object, announcement will not be accepted. All of them accept RIPE route object. If you announce to one of the telecoms, and that telecom happens to accept your announcement without route object, then all the other telecoms will have to accept the announcement without route object. This is simply because big guys trust each other. In the example we tested, we first announced to NTT directly and got rejected. Then we announce to CN2(next generation enterprise network of China telecom). After this NTT accepted the announcement from China telecom without route object created. Current situation: AFRINIC accepts foreign ASN with manual verification of the ownership of the ASN holder as stated by their hostmaster in the mailing list. If you don't own the ASN, they will not create the route object. Despite this, the process is long and unpractical in daily operation. Some providers do accept RPKI. One can create an AFRINIC RPKI that go though the filter, however, not all provider accept RPKI at the moment. In conclusion, If you employ a non-Afrinic asn for announcements (which means a foreign asn), using RIPE’s route object will be the only choice for you unless you are one of those big telecoms which has the liberty to announce anything as they wish. I am not opposing to the idea of cleaning up the database, but until things get fixed, the current process will only break networks. -- -- Kind regards. Lu