Re: [db-wg] A test on AFRINIC range announcing without RIPE route object
Hi All The co-chairs of the DB-WG are talking in the background to the RIRs about how this change will impact the holders of their address space. We are following the points raised here and checking some issues with the appropriate RIRs. The RIPE NCC Database team is also in the loop of these talks so any relevant points can be included in their impact analysis. As some have already said consensus is not unanimity and there is a consensus to close this security hole in the RIPE Database. Even though the security hole will continue to exist in many alternative and commercial IRRs and will continue to be exploited by abusers for some considerable time. cheersdenisco-chair DB-WG
Hi Denis: Consensus is neither unanimity nor majority. Below is a quotation from RFC: "quite often we are letting the majority win the day without consideration of minority concerns. " "Lack of disagreement is more important than agreement" "Rough consensus is achieved when all issues are addressed, but not necessarily accommodated" We have a disagreement because one of the critical issues of our current network is not addressed. If there is one strong disagreement without valid counter argument, the disagreement/issue is therefore not addressed. I believe the issue raised in the thread is not properly addressed therefore there is no actual consensus. That being said, we appreciate the community effort to have all the RIR co-operated together to fix their IRR, and we also support stopping abuse(even if only to a certain degree) in the ripe database. Moreover, I do realize procedurally, we were not here in the list while the consensus was reached. The current process will have my full support if RIR system's IRR can be fixed as a whole, rather than just having one more problem created in another place. On 14 June 2018 at 22:57, denis walker via db-wg <db-wg@ripe.net> wrote:
Hi All
The co-chairs of the DB-WG are talking in the background to the RIRs about how this change will impact the holders of their address space. We are following the points raised here and checking some issues with the appropriate RIRs. The RIPE NCC Database team is also in the loop of these talks so any relevant points can be included in their impact analysis.
As some have already said consensus is not unanimity and there is a consensus to close this security hole in the RIPE Database. Even though the security hole will continue to exist in many alternative and commercial IRRs and will continue to be exploited by abusers for some considerable time.
cheers denis co-chair DB-WG
-- -- Kind regards. Lu
Hi Lu, Are you disagreeing with the proposal, or disagreeing with the implementation details? I have seen several requests to delay implementation, but none with a valid technical reason to not close a security flaw. As I brought up at the microphone, I would love to see a solution built that would allow me to use address space allocated by all RIRs where I am a member in any of their IRR systems. However, that is out of scope for this proposal and would likely require a proposal to all five RIRs to build an authenticated method of validating and documenting IRR records. Please feel free to correct me if there was a technical reason to continue allowing unvalidated space in the RIPE IRR. Thanks, Sean
On Jun 14, 2018, at 12:23 PM, Lu Heng via db-wg <db-wg@ripe.net> wrote:
Hi Denis:
Consensus is neither unanimity nor majority.
Below is a quotation from RFC:
"quite often we are letting the majority win the day without consideration of minority concerns. "
"Lack of disagreement is more important than agreement"
"Rough consensus is achieved when all issues are addressed, but not necessarily accommodated"
We have a disagreement because one of the critical issues of our current network is not addressed.
If there is one strong disagreement without valid counter argument, the disagreement/issue is therefore not addressed.
I believe the issue raised in the thread is not properly addressed therefore there is no actual consensus.
That being said, we appreciate the community effort to have all the RIR co-operated together to fix their IRR, and we also support stopping abuse(even if only to a certain degree) in the ripe database.
Moreover, I do realize procedurally, we were not here in the list while the consensus was reached.
The current process will have my full support if RIR system's IRR can be fixed as a whole, rather than just having one more problem created in another place.
On 14 June 2018 at 22:57, denis walker via db-wg <db-wg@ripe.net> wrote: Hi All
The co-chairs of the DB-WG are talking in the background to the RIRs about how this change will impact the holders of their address space. We are following the points raised here and checking some issues with the appropriate RIRs. The RIPE NCC Database team is also in the loop of these talks so any relevant points can be included in their impact analysis.
As some have already said consensus is not unanimity and there is a consensus to close this security hole in the RIPE Database. Even though the security hole will continue to exist in many alternative and commercial IRRs and will continue to be exploited by abusers for some considerable time.
cheers denis co-chair DB-WG
-- -- Kind regards. Lu
Hi Sean: I am supporting the proposal. But disagree the implementation details. The current implementation would solve one problem in one place but create another one in another place—and such situation can be totally avoid by let AFRINIC fix their IRR first then we continues implementation after. On Fri, Jun 15, 2018 at 02:19 Sean Stuart <sean.stuart@gmail.com> wrote:
Hi Lu,
Are you disagreeing with the proposal, or disagreeing with the implementation details? I have seen several requests to delay implementation, but none with a valid technical reason to not close a security flaw. As I brought up at the microphone, I would love to see a solution built that would allow me to use address space allocated by all RIRs where I am a member in any of their IRR systems. However, that is out of scope for this proposal and would likely require a proposal to all five RIRs to build an authenticated method of validating and documenting IRR records. Please feel free to correct me if there was a technical reason to continue allowing unvalidated space in the RIPE IRR.
Thanks, Sean
On Jun 14, 2018, at 12:23 PM, Lu Heng via db-wg <db-wg@ripe.net> wrote:
Hi Denis:
Consensus is neither unanimity nor majority.
Below is a quotation from RFC:
"quite often we are letting the majority win the day without consideration of minority concerns. "
"Lack of disagreement is more important than agreement"
"Rough consensus is achieved when all issues are addressed, but not necessarily accommodated"
We have a disagreement because one of the critical issues of our current network is not addressed.
If there is one strong disagreement without valid counter argument, the disagreement/issue is therefore not addressed.
I believe the issue raised in the thread is not properly addressed therefore there is no actual consensus.
That being said, we appreciate the community effort to have all the RIR co-operated together to fix their IRR, and we also support stopping abuse(even if only to a certain degree) in the ripe database.
Moreover, I do realize procedurally, we were not here in the list while the consensus was reached.
The current process will have my full support if RIR system's IRR can be fixed as a whole, rather than just having one more problem created in another place.
On 14 June 2018 at 22:57, denis walker via db-wg <db-wg@ripe.net> wrote:
Hi All
The co-chairs of the DB-WG are talking in the background to the RIRs about how this change will impact the holders of their address space. We are following the points raised here and checking some issues with the appropriate RIRs. The RIPE NCC Database team is also in the loop of these talks so any relevant points can be included in their impact analysis.
As some have already said consensus is not unanimity and there is a consensus to close this security hole in the RIPE Database. Even though the security hole will continue to exist in many alternative and commercial IRRs and will continue to be exploited by abusers for some considerable time.
cheers denis co-chair DB-WG
-- -- Kind regards. Lu
-- -- Kind regards. Lu
participants (3)
-
denis walker -
Lu Heng -
Sean Stuart