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
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/000053.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/000064.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
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 <job@instituut.net> 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/000053.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/000064.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
On Wed, Jun 13, 2018 at 10:56 AM, Lu Heng <h.lu@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
+1 ... in CAPITAL LETTERS too. Regards, Peter Thimmesch ------------------------------ hic sunt dracones On Jun 13, 2018, at 7:12 PM, Job Snijders via db-wg <db-wg@ripe.net<mailto:db-wg@ripe.net>> wrote: On Wed, Jun 13, 2018 at 10:56 AM, Lu Heng <h.lu@anytimechinese.com<mailto:h.lu@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
On Wed, Jun 13, 2018 at 11:11:09AM +0000, 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
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 +0000, 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
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
[ 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
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
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.
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
[ off list ]
well, it wasn't. thanks to header modification by broken do-gooder email software. do not modify email headers!!!
BUSH, RANDY, DBWGOPS would like to recall the message, "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
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 <job@instituut.net> wrote:
On Wed, Jun 13, 2018 at 10:56 AM, Lu Heng <h.lu@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
-- -- Kind regards. Lu
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 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279
On Wed, Jun 13, 2018 at 20:10 Gert Doering <gert@space.net> 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 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279
-- -- Kind regards. Lu
Lu Heng via db-wg wrote on 13/06/2018 13:11:
On Wed, Jun 13, 2018 at 20:10 Gert Doering <gert@space.net> 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
Hi, On Wed, Jun 13, 2018 at 08:11:34PM +0800, Lu Heng wrote:
On Wed, Jun 13, 2018 at 20:10 Gert Doering <gert@space.net> 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 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279
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 <gert@space.net> 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 <gert@space.net> 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 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279
-- -- Kind regards. Lu
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
On Jun 13, 2018, at 9:23 AM, Lu Heng via db-wg <db-wg@ripe.net> 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
On Jun 13, 2018, at 8:03 AM, Lu Heng via db-wg <db-wg@ripe.net> 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 <job@instituut.net> wrote: On Wed, Jun 13, 2018 at 10:56 AM, Lu Heng <h.lu@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 -- -- Kind regards. Lu
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 <db-wg@ripe.net> 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 <job@instituut.net> wrote: On Wed, Jun 13, 2018 at 10:56 AM, Lu Heng <h.lu@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 -- -- Kind regards. Lu
Hi Job From: Job Snijders via db-wg <db-wg@ripe.net> To: Lu Heng <h.lu@anytimechinese.com> Cc: Database WG <db-wg@ripe.net> 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
Dear Denis, On Wed, Jun 13, 2018 at 11:45:24AM +0000, 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
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 <db-wg@ripe.net> To: Database WG <db-wg@ripe.net> 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.
Dear Denis, On Fri, Jun 15, 2018 at 1:58 PM, denis walker via db-wg <db-wg@ripe.net> 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
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 <job@instituut.net> To: denis walker <ripedenis@yahoo.co.uk> Cc: Lu Heng <h.lu@anytimechinese.com>; Database WG <db-wg@ripe.net> 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 <db-wg@ripe.net> 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
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 <ripedenis@yahoo.co.uk> 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 <job@instituut.net> *To:* denis walker <ripedenis@yahoo.co.uk> *Cc:* Lu Heng <h.lu@anytimechinese.com>; Database WG <db-wg@ripe.net> *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 <db-wg@ripe.net> 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
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 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279
Hi On Fri, Jun 15, 2018 at 21:53 Gert Doering <gert@space.net> 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 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279
-- -- Kind regards. Lu
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 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279
Hi On Fri, Jun 15, 2018 at 21:57 Gert Doering <gert@space.net> 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
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 <h.lu@anytimechinese.com> To: Gert Doering <gert@space.net> Cc: Database WG <db-wg@ripe.net>; denis walker <ripedenis@yahoo.co.uk> 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 <gert@space.net> 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
Hi denis: On Fri, Jun 15, 2018 at 22:16 denis walker via db-wg <db-wg@ripe.net> 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 <h.lu@anytimechinese.com> *To:* Gert Doering <gert@space.net> *Cc:* Database WG <db-wg@ripe.net>; denis walker <ripedenis@yahoo.co.uk> *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 <gert@space.net> 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
Hi all, On Fri, Jun 15, 2018 at 3:37 PM, Lu Heng via db-wg <db-wg@ripe.net> wrote:
On Fri, Jun 15, 2018 at 22:16 denis walker via db-wg <db-wg@ripe.net> 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
On Fri, Jun 15, 2018 at 22:40 Job Snijders <job@instituut.net> wrote:
Hi all,
On Fri, Jun 15, 2018 at 22:16 denis walker via db-wg <db-wg@ripe.net> 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
On Fri, Jun 15, 2018 at 3:37 PM, Lu Heng via db-wg <db-wg@ripe.net> wrote: 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
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
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 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279
On Jun 15, 2018, at 9:12 AM, Sascha Luck [ml] via db-wg <db-wg@ripe.net> 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
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 <db-wg@ripe.net> wrote:
On Jun 15, 2018, at 9:12 AM, Sascha Luck [ml] via db-wg <db-wg@ripe.net> 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
On Jun 15, 2018, at 8:55 AM, Lu Heng via db-wg <db-wg@ripe.net> 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
On Fri, Jun 15, 2018 at 23:50 Sandra Murphy <sandy@tislabs.com> wrote:
On Jun 15, 2018, at 8:55 AM, Lu Heng via db-wg <db-wg@ripe.net> 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
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
Hi On Sat, Jun 16, 2018 at 00:11 Daniel Suchy via db-wg <db-wg@ripe.net> 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
participants (11)
-
Daniel Suchy -
denis walker -
Gert Doering -
Job Snijders -
Lu Heng -
Nick Hilliard -
Peter Thimmesch -
Randy Bush -
Sandra Murphy -
Sascha Luck [ml] -
Sean Stuart