[anti-abuse-wg] 2019-03 New Policy Proposal (BGP Hijacking is a RIPE Policy Violation)
- Previous message (by thread): [anti-abuse-wg] 2019-03 New Policy Proposal (BGP Hijacking is a RIPE Policy Violation)
- Next message (by thread): [anti-abuse-wg] 2019-03 New Policy Proposal (BGP Hijacking is a RIPE Policy Violation)
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Carlos Friaças
cfriacas at fccn.pt
Thu Mar 21 22:40:07 CET 2019
On Thu, 21 Mar 2019, Jacob Slater wrote: > Hello All, Hi, Thanks for your input. > 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. I had thought about that too. The problem is hijackers tend to hijack space from: - unallocated space - companies which are unreachable (bankrupt/closed?) - networks in conflict (war) zones A variation of this will be allowing anyone _receiving_ the announcement of an hijacked prefix to file a complaint/report. Hijacks don't have to be seen by every network on the planet to be an hijack... And those receiving an hijacked prefix are (according to my dictionary) also victims. > 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). Well, yes. That's one point... the IRR system is kind of broken. And RPKI, unfortunately is still taking baby steps. I would say that in case of doubt, then a rightful owner will be able to create a ROA for the suspected hijack....... Some might say NCC staff might act as a filter, before anything reaches expert's hands. I personally wish that NCC staff is not involved at all. > 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. Maybe some automated checks? The reported prefix has a valid ROA, it matches, so, the complaint is most likely bogus? :-)) > 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. I thought it did, by stating that accidental events are out of scope. > 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. Accidental hijacking should never be treated as a policy violation. It thought that was clear, but probably isn't -- despite section 3.0 and the summary. Sorry for that. Needs to be addressed in the next version. > 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. Yes, thus "This proposal aims to clarify that an intentional hijack is indeed a policy violation." Section 3.0 can be improved. > 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? In short, no. Unless the "customer" is the LIR itself. Thanks. Best Regards, Carlos > > Jacob Slater >
- Previous message (by thread): [anti-abuse-wg] 2019-03 New Policy Proposal (BGP Hijacking is a RIPE Policy Violation)
- Next message (by thread): [anti-abuse-wg] 2019-03 New Policy Proposal (BGP Hijacking is a RIPE Policy Violation)
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]