[anti-abuse-wg] 2019-03 New Policy Proposal (BGP Hijacking is a RIPE Policy Violation)

Dear Cynthia,


On Mon, 25 Mar 2019, Cynthia Revström wrote:

> 
> Hi Carlos,
> 
> On 2019-03-24 15:16, Carlos Friaças via anti-abuse-wg wrote:
>       "It will not stop determined miscreants" -- even if it stops some, it's already something positive, anti-abuse-wise.
>       :-))
> 
> The thing is that, if you look at it from another direction, if it just does one "false positive", I would argue that it
> outweighs 100 small hijacks.

I can relate to that argument, while probaly 100 different victims would 
be a bit more hard to convince.

Following mostly Toma's constructive arguments we understand the process
needs a lot more detail hardwired into the proposal. Our best attempt to 
control "false positives" in version 1.0 was the last "ratification" knob.



> And then we have the other co-author,
> 
> On Sat, Mar 23, 2019 at 10:42 PM JORDI PALET MARTINEZ via
> anti-abuse-wg <anti-abuse-wg at ripe.net> wrote:
> 
> I think is very obvious that the experts [..] will make sure that when a warning is sufficient
> 
> How is that obvious? Answer: it is not obvious, you are just making assumptions.

I think what Jordi meant (coming from the other direction) is a case will 
not reach the policy violation declaration stage.



> After looking at this in a bit more detail, my stance on this proposal has to be that I strongly object to it.

Understood.



> I do feel like the better way to go about this is on a technical level, with more things like RPKI and IRR, not this stuff.

This was already touched in the thread. RPKI deployment, unfortunately, is 
still in a very initial phase.

When someone asks me -- how do you know this is an hijack? -- my usual 
answer is: "OK, if they are the rightful owners then ask them to add a 
ROA". If they can't... well...

This is something which is not explicitely written, but it should be 
simple to dismiss a wrongfully submitted report -- if the ROA is not in 
place, then the "anomaly" could be fixed by creating one.

So yes, we strongly support RPKI and we will try to embed in v2.0 clauses 
that will clearly support RPKI usage.


> On another note, unless all RIRs have a similar policy, then a hijacker 
> wouldn't have to be from RIPE, or what if they have gotten hold of a 
> legacy ASN.

As i've stated before on this thread, the other four RIRs will also have a 
proposal on their tables.
About legacy resources, the RIR can't de-register anything. The only angle 
i see where they could help contain hijackers is by refusing access to 
services.



> My point is that, no matter what the authors intended, I think this 
> policy, would stop close to no determined hijackers, and

We hope it might dissuade some of even trying (and we can't measure 
that...), but having *nothing* in place might work like an incentive for 
some.

Gert already suggested a new BCP. I think we'll try that too :-)


> probably cause a few "false positives".

That's something we want to erradicate. We need more work and more text.
Any input is welcome!


Best Regards,
Carlos




> - Cynthia
> 
> 
>