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.
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. 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. 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". 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. Jacob Slater On Mon, Sep 9, 2019 at 5:25 PM Carlos Friaças <cfria...@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 <cfria...@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 <mschm...@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@ripe.net> > before 4 > > > October 2019. > > > > > > > > > Kind regards, > > > > > > Marco Schmidt > > > Policy Officer > > > RIPE NCC > > > > > > > > > > > > > > > > > >
