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
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
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
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
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
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
+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 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
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
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
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
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
[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
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
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
[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
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
> 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
> 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
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
> 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
[ 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 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 ] 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
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
