[anti-abuse-wg] 2019-03 Review Phase (Resource Hijacking is a RIPE Policy Violation)

On Mon, 9 Sep 2019, Alexander Talos-Zens wrote:

> Hej,

Hi Alexander, All,
(please see inline)



> this is my first post in this list - my perspective is taht of a
> security guy with little knowledge about BGP or the inner workings of
> RIPE, but very interested in everything that helps definding against the
> bad guys.
>
> Den 2019-09-05 kl. 15:23, skrev Marco Schmidt:
>
>> The goal of this proposal is to define that BGP hijacking is not
>> accepted as normal practice within the RIPE NCC service region.
>
> Firstly, thanks everyone involved for the effort in setting up this
> policy proposal. I like many points, e.g. that it makes clear that
> accidental events shall not be reprimanded. Others might deserve being
> rephrased, e.g. CSIRTS being entitled to file reports.

That detail is new on version 2, derived from comments to version 1. :-)

The idea was to prevent anyone to "hunt" for hijacks and overload the 
system with reports, i guess. We didn't have that in version 1, so we 
added it to v2. As a workaround, a CSIRT (i work for one...) can ask the 
victim to file the report, or help the victim in doing that.



> On the other hand, I had a hard time trying to determine the positive
> impact of the proposed policy.

The original idea is/was:
Some (persistent, intentional) hijackers are RIPE NCC members, and if they 
don't respect the address space allocated to others, perhaps they 
shouldn't be inside the system.

However, it's important to note, that *one* policy violation will not 
result in the member/hijacker losing membership status...



> On the formal side, to define that hijacking is a violation of policy
> without specifying which policy is violated gives me a mental blue
> screen.

There is currently no policy against hijacking.

Member X can actually hijack blocks or parts of blocks from Members Y,W,Z 
(or members from other RIRs) and life goes on. This proposal tries to 
establish that persistent, intentional hijacking is not to be tolerated -- 
unfortunately not everyone agrees... :-)



> As far as I know, please correct me if I'm wrong, there is no
> policy in RIPE that proscribes hijacking, and neither would 2019-03 do that.

2019-03 tries to introduce the notion that hijacking (again, persistent &
intentional) is not acceptable.



> This makes sense to me, as (again, correct me if I'm wrong) RIPE isn't
> involved in routing operations - but that's where hijacking attacks take
> place.

Yes and no (imho).

RIPE NCC (and/or the RIPE community) doesn't tell anyone what to 
configure on their routers.

However what's the point of a registry system if some of its members 
decide to grab some space from other members...?



> Should RIPE kick out the evil LIRs? Maybe, but the proposed policy
> doesn't do that. The opposite holds true: "RIPE-716) may apply." and
> "This policy does not endorse the initiation of an LIR closure procedure
> on the basis of a single policy violation." No mention what happens
> after multiple (how many? depending on LIR size? ...) violations.

More than one, at least.

This is something new in v2, because in the 400+ messages discussion 
about v1, several voices pointed out that losing LIR status shouldn't 
happen immediately at the first "offence"... so we took note and 
accomodated this comment in v2. I can easily agree v2 is less "strict" 
even if not enough for some (or most) people.



> I failed to find any way how implementing this proposal would improve
> security.

The way i see this as "preventive", is that *today* there isn't absolutely 
nothing at RIR/Registry policy level against hijacks (i mean, in any of 
the 5 RIRs, where we also launched this proposal).

If the proposal reaches to a point (clearly not in v2) where it would get
adopted, then a potential hijacker would know that it could lose it's LIR 
status (and corresponding numbering resources).


> I've also tried to save the proposal's impetus by coming up
> with realistic and effective suggestions - but failed as well.

If you read v1, it was significantly shorter... but the thing is that a 
lot of people expressed opposition to several aspects (or the lack of 
some) and we've tried to address them all [back in late April...] :-)



> For now, my conclusion is that this isn't the way to go.


Thanks for your input!


Best Regards,
Carlos




> Cheers,
>
> Alexander
>
> -- 
> Alexander Talos-Zens
> IT-Security - ACOnet-CERT
> Zentraler Informatikdienst
> http://zid.univie.ac.at
>
> Universität Wien
> Universitätsstraße 7
> 1010 Wien
> T +43-1-4277-14351
> at at univie.ac.at
> GPG-Key-Id: 0x757A494B
>