Re: [anti-abuse-wg] Question about spam to abuse inbox
> > If you predicate sending reports via web form, then report forwarding > from the ISP to its customer should also be done via web form. > The relationship between an arbitrary internet user and an ISP is different from the relationship between an ISP and a customer who is on a contract. I can (and do) require end users of my infrastructure respond to abuse e-mails sent to them in specific ways. If they don't like the terms I've set, they are welcome to take their business elsewhere. The same relationship does not currently exist with abuse reports. At times I also try and > send fake complaints about my IP, to see if they would forward them to > me. All of those messages fall into a black black hole where time is > frozen expectations fade. Lazy. > It is also possible your ISP believes the report is fake and does not forward it on. Alternatively, perhaps their policy is to not forward reports on. They might investigate, deem it incorrect, and delete it. I personally am opposed to banning or discouraging web forms unless we standardize some system. If there is an expectation for human review on the ISP side, there should be an expectation that the sender is human. If we set an expectation for automated sending of abuse reports, limited machine review prior to acceptance should be expected. Solving this is a difficult problem. From my (admittedly limited) experience, I'm in agreement with Alex de Joode - a solution cannot impact certain operational realities of ISPs. Limited machine review - along with automation of abuse reports on the receiving side - is an operational reality. False, inaccurate, incomplete, or just plain malicious abuse reports are just as real as actual abuse reports. I would note a further operational reality: any standard we come up with outside of the current method of communication (email) is likely to never reach large-scale deployment. Even if we make a standard within e-mail (ex. ARF), some ISPs will want (or need) details beyond what would be outlined in the standard. This will inevitably require more non-standard human interaction. Those who do not care to receive abuse reports will fail to respond to them, regardless of what we decide here. - Slater On Fri, Feb 26, 2021 at 3:57 PM Alessandro Vesely wrote: > On Thu 25/Feb/2021 14:41:00 +0100 Cynthia Revström wrote: > > > I think you have misunderstood my point. > > > >> Would they send such report using their customer's own web form? > > > > No? I don't know what implied that? > > > If you predicate sending reports via web form, then report forwarding > from the ISP to its customer should also be done via web form. That > is, the ISP should jump all the required hoops until it finds out > where and how to fill the appropriate form. However, doing so defeats > the advantage of having the customer automatically identified. > > > >> Yes, doing so requires some work too, but heck aren't we paying for that > > already? > > > > The person sending the abuse report is rarely a paying customer. > > > >> The right thing to do would be to arrange for the abuse mailbox address > > to point (in)directly to the actual user of the IP address. > > > > I am assuming you are referring to having a separate abuse contact for > each > > customer, so like abuse.cust123@domain and registering it in the RIPE > > Registry/DB? > > > Yes, exactly. That's the extra work required from the ISP. It is > paid by cust123. Presumably, abuse.cust123@domain forwards to the > abuse address chosen by the customer on signing the contract. Keeping > a copy allows the ISP to monitor how many complaints its customers > receive. > > > > In some cases with large customers maybe but if you are a hosting > provider > > where each customer might only have one or two IPv4 addresses, that can > get > > to an insane amount of handles and make the database really messy. > > > You can keep a record for each IPv4 address with only a few Terabytes. > > I don't think the reason why ISPs tend to neither assign rfc2317 > reverse delegations nor customer specific abuse-mailbox is because > they or the RIPE cannot afford enough disk space to store that data. > > Every now and then I ask my ISP to assign me an abuse-mailbox (which > my previous ISP did, but then they were acquired by a bigger shark > while the RIPE changed format to abuse-c.) At times I also try and > send fake complaints about my IP, to see if they would forward them to > me. All of those messages fall into a black black hole where time is > frozen expectations fade. Lazy. > > > > Also the customer in question is not the only info that is relevant, like > > is it DoS, spam, or port scanning, etc? > > > > But in general I think there are pros and cons to web forms and email > > templates just as there are pros and cons to arbitrarily structured > emails. > > > For a third alternative, I recently added abuseipdb.com to my > end-of-day abuse reporting script. They provide an http API that > al
Re: [anti-abuse-wg] 2019-03 Review Phase (Resource Hijacking is a RIPE Policy Violation)
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 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 wrote: > > > > > &
Re: [anti-abuse-wg] 2019-03 Review Phase (Resource Hijacking is a RIPE Policy Violation)
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 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 wrote: > > > > > > On Thu, 5 Sep 2019, Jacob Slater wrote: > > > >
Re: [anti-abuse-wg] 2019-03 Review Phase (Resource Hijacking is a RIPE Policy Violation)
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. 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. While I haven't seen a proposal for establishing a system like LACNIC's WARP under RIPE, I'd be open to the idea. 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. Right now, the policy seems to pull a large amount of resources and risk (per the impact analysis) without enough of a return. Jacob Slater On Mon, Sep 9, 2019 at 3:45 PM Carlos Friaças 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 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
Re: [anti-abuse-wg] 2019-03 Review Phase (Resource Hijacking is a RIPE Policy Violation)
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), 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. 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. 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 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 before 4 > October 2019. > > > Kind regards, > > Marco Schmidt > Policy Officer > RIPE NCC > > >
Re: [anti-abuse-wg] 2019-03 New Policy Proposal (BGP Hijacking is a RIPE Policy Violation)
> > I agree, but to avoid throwing the baby out with the bathwater, I would > suggest to you that it would be best if you could suggest to the proposal's > author and sponsor some different language with respect to the procedure > for judging such matters... some different process that would address > your reasonable concerns about process... rather than just saying that > the whole proposal is unacceptable. > > In short, it appears that yur objection here is about implementation > details, and that you do not object to the over-arching concept, assuming > of course that the process of adjudicating such matters may be made > substantially more reliable and fool-proof. Perhaps. I've spoken with at least one of the authors and am still not entirely convinced the wording can be done such that it reasonably addresses the issues I've presented. I'll reserve judgement until version 2.0 is released for discussion. see last line So you do agree that there is a -possibility- that a threat exists and that > it might, in theory, and under some appropriate circumstances, be > diminished > or eliminated by the termination of the RIPE contract with certain well > proven and accurately identified "rogue" members, yes? > If a NCC member is actively and willfully, after having been notified and given ample opportunity to resolve the issue, engaged in widespread hijacking such that RIR/NIR members have complained about their ability to use their own resources, yes. That case has nothing at all to do with the theft OF IP ADDRESSES, and thus, > it is rather entirely irrelevant to this discussion. > The case does deal with the slippery slope argument in that it demonstrates at least one instance of modern law where removing content from an online service (at all) resulted in an opening for legal liability. While not an issue specific to policy discussion, I do believe it is worth consideration when determining potential breadth of the policy. Action should be well backed with evidence. see last line My apologies for not quoting the relevant section properly. I disagree, and apparently, so does Cloudflare. And they should know. > Cloudflare's blog post on the subject has comments on the matter. One of their staff members is known for stating "Is this the day the Internet dies?", a reference to the fact that they acknowledge they (at the time) were about to take content offline for what were non-required reasons. https://blog.cloudflare.com/why-we-terminated-daily-stormer/ That isn't to say that I think this is an inherently bad option. I just think it needs to be balanced such that it is clearly justified when action is taken. see last line The question is whether or not this proposal is a demonstrably bad way to > -try- to begin > to address the problem, at least in part. I remind you that right now > there > is essentially -zero- disincentive to the act of deliberate hijacking. > Getting depeered by transits, losing IX memberships, and having gear seized by authorities all seem like potential disincentives. Having a bunch of NCC-allocated IP space doesn't matter when you are unable to use it. Again, I am in agreement with you, but I do believe that this is a matter > of fine-tuning the procedural aspects of the propsal, rather than simply > opposing or abandoning it wholesale. > Agreed so far as being open to revisions. see last line Given the number of references I've made to rev 2.0, I'll likely hold additional comments until it is released, as they are quite possibly irrelevant. Jacob Slater On Mon, Apr 1, 2019 at 11:24 PM Ronald F. Guilmette wrote: > > In message < > cafv686cuabmpiq1e6owd2ovwna4x6otvbfxshd0bjosmdle...@mail.gmail.com>, > Jacob Slater wrote: > > >In the case of IP addresses and ASNs, the "convicted individual" has been, > >under the current policy draft, convicted in the mind of one - perhaps two > >upon appeal - experts (a term which has yet to be defined in policy). Such > >an opinion, no matter how professional, is a very low bar to be taking as > >objective. > > I agree, but to avoid throwing the baby out with the bathwater, I would > suggest to you that it would be best if you could suggest to the proposal's > author and sponsor some different language with respect to the procedure > for judging such matters... some different process that would address > your reasonable concerns about process... rather than just saying that > the whole proposal is unacceptable. > > In short, it appears that yur objection here is about implementation > details, and that you do not object to the over-arching concept, assuming > of course that the process of adjudicating such matters may be made > substantially more reliable and fool-proof. > > >Shoul
Re: [anti-abuse-wg] 2019-03 New Policy Proposal (BGP Hijacking is a RIPE Policy Violation)
nc. v. Cloudflare, Inc., et al. being one of them). It would seem so, at least when the "slippery slope" arguments is > clearly being made in order to falsely try to scare people with the > bogeyman of "censorship". That is clearly not what the proposal is > about, and anyone who claims otherwise needs to go back to school > until he, she or it fully grasps the difference between content and > the IP addresses that provide the technical means to distribute it. Blocking content distribution methods is effectively blocking the content itself. If your newspaper was unable to print and distribute their news because their electricity had been shut off (for anything outside of nonpayment), it would still be considered censorship. Whst this *is* actually all about is just this: You steal IPs and > then you lose your IPs. > I've still yet to be convinced that this would substantially cut down on hijacking; additionally, I've yet to be convinced that such a policy would not sweep up innocents due to its allowance of reports by the general public and incredibly low bar for labeling someone a hijacker. Jacob Slater On Mon, Apr 1, 2019 at 3:56 PM Ronald F. Guilmette wrote: > > In message , > Nick Hilliard wrote: > > >BGP hijacking is just the start, but there is an endless list of things > >which are considered offensive or illegal in some or all jurisdictions > >in the RIPE NCC service area, e.g. spam, porn, offending political > >leaders, gambling, drugs, other religions, political dissent, blasphemy > >and so on. > > As I have already pointed out, this "slippery slope" argument is a > smokescreen, and only being used to justify the inexcusible status quo. > > The proposal on the table doesn't deal with any matters which are in > any way even remotely tied to mere offenses against any local or > localize sensibilities. It doesn't even remotely have anything at > all to do with either (a) any actions or offenses in "meatspace" nor > (b) any actions or offenses having anything at all to do with -content- > in any sense. The present proposal only has to do with the outright > THEFT of IP addresses, i.e. the very commodity which RIPE is supposed to > the responsible shepard of. > > Given all of the supposed experience and intelligence of the people on > this list, I seriously have no idea why it should be necessary for me > to explain the abundantly clear distinction between content and the > wires and IP infrastructure that carries that content. Is this a > really difficult concept to understand? > > It would seem so, at least when the "slippery slope" arguments is > clearly being made in order to falsely try to scare people with the > bogeyman of "censorship". That is clearly not what the proposal is > about, and anyone who claims otherwise needs to go back to school > until he, she or it fully grasps the difference between content and > the IP addresses that provide the technical means to distribute it. > > As those of us who have actually spent years opposing Internet abuse > like to say, our concern is not about abuse "on the Internet" but > rather it has to do with abuse "of the Internet". Since this > distinction has obviously traveled slowly to the far side of the > pond, I am forced to provide some (hopefully educational) illustrations. > > If someone sends you a highly offensive email, or makes a highly offensive > Farcebook post, saying that your paternal grandmother is a actually a > closet Visigoth, then that constitutes abuse -on- the Internet. > > If, on the other hand, some hacker infects your machines, and thousands > like it, and then uses his entire collection of infescted machines to > DDoS you, presumably because you just beat him in a game of League of > Legends, then that is abuse -of- the Internet, because in this case, > it is the infrastructure itself that is being misused and abused... > and -that- kind of abuse affects all of us. > > I seriously would have hoped that it would not have been necessary for > me to provide people on this mailing list, in particular, with examples > to illustrate the clear conceptual differences betwen abuse "on" the > Internet and abuse "of' the Internet, but apparently I hoped in vain, > and this rather critical and key distinction is still being either > throughly misunderstood or else throughly ignored when it comes to > these bogus "slippery slope" arguments. > > Let me say it more clearly. Nobody wants to take away your porn. > That's not what this is about, as any fair-minded reader of the > propsal can easily see. The idea is simple: Those who steal IP > addresses shall not be a
Re: [anti-abuse-wg] 2019-03 New Policy Proposal (BGP Hijacking is a RIPE Policy Violation)
>
> First, I'm not sure I either understand or am even aware of these alleged
> "forms of permission for announcement {that} are not documented". So
> perhaps
> Mr. Slater could elaborate upon that, for my benefit, and perhaps also for
> that of others who may also be similarly in the dark about what he's
> talking
> about here.
>
Route objects are not always required. While route objects are generally
preferred and should be used, letters of authorization are still in use
today. You certainly wouldn't see them in a public database (though you
might see objects which claim to be tied to them). Even if you do, they may
well be stale and no longer accurate.
and if so, the reasons for that.
>
Because they have had no valid reason to do so yet. Making it a policy
violation doesn't seem like the right way to encourage them to do so.
It is not the job of the NCC to tell users how to run their network. As
annoying as it is at times, this includes how users choose to authenticate
their announcements.
I think the proposal moves us closer to a state of civility and
> civilization.
> You might well claim, as you have, that it permits and carves out some
> space still for "vigilantism" in the process, but it does so only with
> respect to the submission of reports that would then, by design, be
> reviewed and judged by others. I have trouble seeing how this could
> be harmful. I do agree that it opens up the possibility of perhaps
> having everyone's time wasted, perhaps even frequently, with meritless
> and bogus reports, but I think that it is premature to assume that such
> an outcome will, in practice, be common enough to merit serious concern.
> Time will tell.
>
I agree that it may be presumptuous to guess at how much time will be
wasted without any justification. That said, I have seen a significant
number of recent reports on various mailing lists of accused hijackers.
While some of them have been accurate, some of them definitively jump to
premature conclusions. I, for one, would like to at the very least minimize
the impact (in both stress and time) that such users would have on the time
of all involved.
Given your comments (along with some of the others mentioned), perhaps the
best way to approach the issue is with explicitly stated guidelines for how
hijacking reports should be processed and treated on the basis of both
credibility (i.e. bogon/prefix holder) and bulk in a holistic sense. If
done properly, it would minimize the risk for noncredible reports to cause
impact for a given entity (based on the beliefs of a particular expert)
while allowing groups beyond the specific prefix holder to make complaints
(which have the potential to be taken seriously).
>Additionally, while the policy does define a difference between accidental
> >and intentional hijacking, it does not differentiate between the two...
>
> If that's true, then it should certainly be fixed.
>
Reading through the exact text, the only mention of the distinction appears
to be a definition.
On Thu, Mar 21, 2019 at 9:34 PM Ronald F. Guilmette
wrote:
>
> In message <
> cafv686e9aa8xhacuz+epfbelu74mpce-2pic2-kpu-1xapt...@mail.gmail.com>
> Jacob Slater wrote:
>
> >... If everyone is allowed to {file reports}, we run several risks,
> >namely that individuals with no knowledge of the situation (beyond that
> >viewed in the public routing table) will file erroneous reports based on
> >what they believe to be the situation (which may not be accurate, as some
> >forms of permission for announcement are not documented in a way they
> could
> >feasibly see). Allowing for competent complaints (with teeth) to be filed
> >is a good idea; needlessly permitting internet vigilantes to eat
> management
> >time based on a flawed view of the situation is not.
>
> I have two issues with the quote above.
>
> First, I'm not sure I either understand or am even aware of these alleged
> "forms of permission for announcement {that} are not documented". So
> perhaps
> Mr. Slater could elaborate upon that, for my benefit, and perhaps also for
> that of others who may also be similarly in the dark about what he's
> talking
> about here.
>
> All I know is that the RIPE WHOIS data base contains, among much other
> stuff,
> route: object which generally document what is generally believed to be
> information about properly authorized (by the affected resources holder)
> routing permissions. If there exists information about properly authorized
> routing permissions that is -not- present in and among those data base
> route
> objects, then I do have to wonder if some such routing permissions either
> cannot be or should not be represented as route object in the official da
Re: [anti-abuse-wg] 2019-03 New Policy Proposal (BGP Hijacking is a RIPE Policy Violation)
Hello All, While I am in general support of the proposal’s ideas, I have several concerns with regards to the specific implementation. While the idea of an a complaint form (with teeth) sounds appealing, I do not believe submission should be open to everyone. Only the party holding rights (as registered in a RIR) should be able to file a report regarding their own IP space. If everyone is allowed to do so, we run several risks, namely that individuals with no knowledge of the situation (beyond that viewed in the public routing table) will file erroneous reports based on what they believe to be the situation (which may not be accurate, as some forms of permission for announcement are not documented in a way they could feasibly see). Allowing for competent complaints (with teeth) to be filed is a good idea; needlessly permitting internet vigilantes to eat management time based on a flawed view of the situation is not. Additionally, while the policy does define a difference between accidental and intentional hijacking, it does not differentiate between the two with regards to policy violations. While some discretion should be left up to the expert, it seems odd to include this differentiation without simultaneously explicitly stating that accidental hijacking should generally be treated less severely. I am by no means attempting to state that constant, unlearned-from mistakes should be overlooked; I am merely stating that the odd one-off event should be explicitly prohibited from bringing down an entire LIR. Fat fingering happens. Finally, how does the proposed policy apply to sponsored resources (ASNs and PI space)? Is an entire LIR to be held accountable for sponsoring the resources for users who are otherwise supposed to be independent? Jacob Slater On Tue, Mar 19, 2019 at 8:41 AM Marco Schmidt wrote: > Dear colleagues, > > A new RIPE Policy proposal, 2019-03, "BGP Hijacking is a RIPE Policy > Violation", is now available for discussion. > > The goal of this proposal is to define that BGP hijacking is not accepted > as normal practice within the RIPE NCC service region. > > You can find the full proposal at: > https://www.ripe.net/participate/policies/proposals/2019-03 > > As per the RIPE Policy Development Process (PDP), the purpose of this > four-week Discussion Phase is to discuss the proposal and provide feedback > to the proposer. > > At the end of the Discussion Phase, the proposers, with the agreement of > the Anti-Abuse WG co-chairs, decide how to proceed with the proposal. > > We encourage you to review this proposal and send your comments to < > anti-abuse-wg@ripe.net> before 17 April 2019. > > Kind regards, > > Marco Schmidt > Policy Officer > RIPE NCC > > Sent via RIPE Forum -- https://www.ripe.net/participate/mail/forum > >
