[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 ]
Carlos Friaças
cfriacas at fccn.pt
Tue Sep 10 09:26:26 CEST 2019
Hello, As the RIPE NCC's IA shows (imho), the proposed process is not perfect. The main goal of having a process to start with was to allow some action regarding evident cases, and i hope people will agree that significant effort was made to accomodate comments during v1's discussion. We tried to add more "safety knobs", because we felt that a wrong decision (by experts) would be a really, really bad thing, and we wanted to avoid that -- even knowing that sometimes even courts do get it wrong _and_ that ONE 'guilty of hijacking' case wouldn't result immediately in a LIR terminating process. In the case there were no doubts that someone/some company was doing this (i.e. a 'guilty' conclusion), the expected outcome would be for that member to stop that behaviour from that point forward. Regards, Carlos On Mon, 9 Sep 2019, Jacob Slater wrote: > 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 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
- 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 ]