This archive is retained to ensure existing URLs remain functional. It will not contain any emails sent to this mailing list after July 1, 2024. For all messages, including those sent before and after this date, please visit the new location of the archive at https://mailman.ripe.net/archives/list/anti-abuse-wg@ripe.net/
[anti-abuse-wg] 2019-03 Review Phase (Resource Hijacking is a RIPE Policy Violation)
- Previous message (by thread): [anti-abuse-wg] 2019-03 Review Phase (Resource Hijacking is a RIPE Policy Violation)
- Next message (by thread): [anti-abuse-wg] 2019-03 Review Phase (Resource Hijacking is a RIPE Policy Violation)
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Jacob Slater
jacob at rezero.org
Tue Sep 10 00:25:11 CEST 2019
All, Sure, but stat.ripe.net, bgp.he.net, rpki, and many other sources are free > for everyone to access. :-) > Having a copy of the table and see historical data doesn't automatically give one the ability to determine if a given announcement was a hijack. I might strongly suspect that it was - sure. My personal suspicions should not be enough in this instance. Honestly, i handed it back in late April. The IA and publishing took some > time... :-) > What i think supports what i wrote above is in Section 7.0, clause 1: > "The RIPE NCC will verify that a report contains sufficient information > before assigning it to a group of experts. If this is not the case, the > report will be dismissed." > > Maybe it could be a bit clearer, or we could textually add "one event or a > handful of events is not enough". > Stating that a single report isn't enough doesn't solve the issue. A thousand reports might not give enough quality information to justify an investigation; a single report from an authoritative source might. It is for this reason that - in order to save resources - I'm concerned with the amount of people who could potentially submit a report. Hence Section 7.0, clause 1 :-) > Section 7 of the current draft gives the accused the opportunity to defend themselves as the second step, right after the NCC "verifies" the request. The accused entity is still being "asked" (under pressure) to provide information on the basis of a report that may or may not have come from someone who actually knows about the situation. Sure. And i have already read the IA. All of it. > OK. I've done the same. I still feel that the IA outlines a lot of issues and problems. At this time, I don't think that the potential benefits of the proposal outweigh the costs. Jacob Slater On Mon, Sep 9, 2019 at 5:56 PM Carlos Friaças <cfriacas at fccn.pt> wrote: > > > Hi, > > > On Mon, 9 Sep 2019, Jacob Slater wrote: > > > All, > > If it's *your* table, you should be able. > > > > Again, I disagree. Just because you have a copy of the routing table > doesn't automatically put you in a position to know what is going on with > each entry present in that table. > > Sure, but stat.ripe.net, bgp.he.net, rpki, and many other sources are > free > for everyone to access. :-) > > > > But please keep in mind than one event or a handful of events > shouldn't > > justify an investigation, or handing a case to "experts". > > > > The current policy proposal doesn't have text to support this. > > Honestly, i handed it back in late April. The IA and publishing took some > time... :-) > What i think supports what i wrote above is in Section 7.0, clause 1: > "The RIPE NCC will verify that a report contains sufficient information > before assigning it to a group of experts. If this is not the case, the > report will be dismissed." > > Maybe it could be a bit clearer, or we could textually add "one event or a > handful of events is not enough". > > > > > If the issue is fixed and the issue originator isn't always the > same, then > > no real need for an investigation. Maybe the amount of text on the > current > > version fades a bit the two main concepts of "persistent" and > > "intentional". > > > > I am in agreement with you on this. > > > > There should be enough "trail" to justify starting an > investigation... > > > > If the person submitting a report isn't in an authoritative position to > say whether or not an announcement was a hijack, there isn't a good enough > "trail" to justify starting an investigation. > > Hence Section 7.0, clause 1 :-) > > > > > The "proposal". It's just a proposal...! :-) > > > > > > > > I agree that there isn't a way to measure how many people around > the > > > > world would not resort to hijacking if this proposal was in place > today > > > > My apologies for misspeaking on that one. Any references I may have > made to 2019-3 as a "policy" should read as "policy proposal". > > No harm done :-) > > > > Just because a policy proposal has the chance to discourage bad actors > doesn't mean we should ignore the potential consequences of implementing > the proposal. > > Sure. And i have already read the IA. All of it. > > > Regards, > Carlos > > > > > Jacob Slater > > > > > > > > On Mon, Sep 9, 2019 at 5:25 PM Carlos Friaças <cfriacas at fccn.pt> wrote: > > > > > > Hi, > > > > > > On Mon, 9 Sep 2019, Jacob Slater wrote: > > > > > All, > > > If that happens, then potentially everyone can be a > victim, yes. > > > Then they should be able to place a report. > > > > > > > > > I disagree. Just because you see what you think is a hijack in > the full table doesn't mean you have enough information to justify a full > investigation that is likely to consume valuable time and resources. > > > > If it's *your* table, you should be able. > > But please keep in mind than one event or a handful of events > shouldn't > > justify an investigation, or handing a case to "experts". > > > > > > > Afaik, this is possible within LACNIC (i.e. through > warp.lacnic.net). When > > > the same proposal was discussed there, the yearly number > of reports (if > > > i'm not mistaken) was on the scale of dozens -- and they > have a very high > > > degree of helping stop/mitigate the incidents, almost > close to 100%, which > > > is fantastic! > > > > > > > > > Being asked to fix an issue is very different from getting > investigated for an issue with the potential for termination of membership. > > > > If the issue is fixed and the issue originator isn't always the > same, then > > no real need for an investigation. Maybe the amount of text on the > current > > version fades a bit the two main concepts of "persistent" and > > "intentional". > > > > > > > While I haven't seen a proposal for establishing a system like > LACNIC's WARP under RIPE, I'd be > > > open to the idea. > > > > Great. Does anyone think this is a bad idea? > > > > That would probably fall under the ncc-services-wg, so we'll have > to see > > :-) > > > > > > > > > I fail to identify exactly were the proposal describes > such a need. > > > Even so, the experts should be binded to NDAs... :-) > > > > > > > > > While having the experts under NDA is a step in the right > direction, it still involves effectively being required to turn information > over to external parties due to the suspicions of some random AS. My > concern isn't so > > much that the > > > information will be leaked; my concern is that, fundamentally, > being required to turn information over to a third party on someone's > unsupported suspicions seems wrong. > > > > There should be enough "trail" to justify starting an > investigation... > > > > > > > > > Right now, the policy seems to pull a large amount of resources > and risk (per the impact analysis) without enough of a return. > > > > The "proposal". It's just a proposal...! :-) > > > > I agree that there isn't a way to measure how many people around > the > > world would not resort to hijacking if this proposal was in place > today > > :-) > > > > > > Regards, > > Carlos > > > > > > > > > > > Jacob Slater > > > > > > > > > > > > > > > > > > > > > On Mon, Sep 9, 2019 at 3:45 PM Carlos Friaças <cfriacas at fccn.pt> > wrote: > > > > > > > > > On Thu, 5 Sep 2019, Jacob Slater wrote: > > > > > > > All, > > > > > > Hi Jacob, All, > > > > > > > > > > Given the number of people who may submit a report > (anyone receiving a > > > > full table from their upstream(s), assuming the accused > hijack makes it > > > > into the DFZ), > > > > > > If that happens, then potentially everyone can be a > victim, yes. > > > Then they should be able to place a report. > > > But that's a fundamental part of why some changes are > needed: it's not > > > only the legitimate address space owner who is the victim > of an hijack. > > > People/networks whose packets are diverted by an hijack > are also victims > > > of traffic interception. > > > > > > Afaik, this is possible within LACNIC (i.e. through > warp.lacnic.net). When > > > the same proposal was discussed there, the yearly number > of reports (if > > > i'm not mistaken) was on the scale of dozens -- and they > have a very high > > > degree of helping stop/mitigate the incidents, almost > close to 100%, which > > > is fantastic! > > > > > > > > > > I'm still concerned that the proposed policy would cause > more harm than > > > > good. A random AS that happens to receive the > announcement isn't in an > > > > authoritative position to know if a given announcement > was unauthorized. > > > > > > I can fully agree that a system based on (possibly forged) > LOAs, and > > > unauthenticated IRR created the huge mess we are submerged > in today... > > > :((( > > > > > > > > > > Putting them through a reporting process that might well > require the > > > > disclosure of internal information because of an > unrelated > > > > individual/group being suspicious is a problem. > > > > > > I fail to identify exactly were the proposal describes > such a need. > > > Even so, the experts should be binded to NDAs... :-) > > > > > > > > > Regards, > > > Carlos > > > > > > > > > > > > > Combined with the issues detailed in the Impact > Analysis, I'm opposed to the policy as written. > > > > > > > > Jacob Slater > > > > > > > > On Thu, Sep 5, 2019 at 9:24 AM Marco Schmidt < > mschmidt at ripe.net> wrote: > > > > Dear colleagues, > > > > > > > > Policy proposal 2019-03, "Resource Hijacking is a > RIPE Policy Violation" > > > > is now in the Review Phase. > > > > > > > > The goal of this proposal is to define that BGP > hijacking is not > > > > accepted as normal practice within the RIPE NCC > service region. > > > > > > > > The proposal has been updated following the last > round of discussion and > > > > is now at version v2.0. Some of the changes made > to version v1.0 include: > > > > - Includes procedural steps for reporting and > evaluation of potential > > > > hijacks > > > > - Provides guidelines for external experts > > > > - Adjusted title > > > > > > > > The RIPE NCC has prepared an impact analysis on > this latest proposal > > > > version to support the community?s discussion. You > can find the full > > > > proposal and impact analysis at: > > > > > https://www.ripe.net/participate/policies/proposals/2019-03 > > > > > https://www.ripe.net/participate/policies/proposals/2019-03#impact-analysis > > > > > > > > And the draft documents at: > > > > > https://www.ripe.net/participate/policies/proposals/2019-03/draft > > > > > > > > As per the RIPE Policy Development Process (PDP), > the purpose of this > > > > four week Review Phase is to continue discussion > of the proposal, taking > > > > the impact analysis into consideration, and to > review the full draft > > > > RIPE Policy Document. > > > > > > > > At the end of the Review Phase, the Working Group > (WG) Chairs will > > > > determine whether the WG has reached rough > consensus. It is therefore > > > > important to provide your opinion, even if it is > simply a restatement of > > > > your input from the previous phase. > > > > > > > > We encourage you to read the proposal, impact > analysis and draft > > > > document and send any comments to < > anti-abuse-wg at ripe.net> before 4 > > > > October 2019. > > > > > > > > > > > > Kind regards, > > > > > > > > Marco Schmidt > > > > Policy Officer > > > > RIPE NCC > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: </ripe/mail/archives/anti-abuse-wg/attachments/20190909/a78f8a3f/attachment.html>
- Previous message (by thread): [anti-abuse-wg] 2019-03 Review Phase (Resource Hijacking is a RIPE Policy Violation)
- Next message (by thread): [anti-abuse-wg] 2019-03 Review Phase (Resource Hijacking is a RIPE Policy Violation)
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]