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

Hi Erik, All,

Thanks for your input.

Your message was quite long, so i'll try to answer several aspects of it 
below, after quoting what you wrote.


=======

> 1. "The official reaction to Dutch parliament was, that it was too hard 
> to prosecute or even find the actual people behind the hijack and they
> decided not to go after them."

This means they decided this time, it doesn't mean they wouldn't decide 
differently in a subsequent timeframe.

The hijackers could easily repeat their wrongdoings? Yes, they could, with 
the same set of resources (same ASN and same other legitimate prefixes to 
support the 'operation').

It's important also to state that a different victim might feel 
differently and it could value extra tools in fighting this. Remember, a 
non-dutch victim will have some extra difficulty engaging with dutch 
courts because those victims will lack in knowledge about dutch law.

This is also a case which involved #politics. A private company (as a 
victim), would probably in the first place defend their own interests and 
their shareholders, regardless of its country's politics.


=======

> 2. "Even IF they would have proceeded .. under Dutch law, BGP Hijacking 
> isn't a criminal offence and as a result, not directly illegal or 
> criminal.. Performing a (D)DOS or breaking into a computer system is.. 
> but BGP hijacking as such isn't.   Especially if the IP space wasn't in 
> use.. so nothing broke or stopped working .."

So, acting at RIR level could be seen as actually filling in for a gap in 
Dutch law? If this is the case, good, as this gap affects people well 
beyond dutch (and EU) borders.

Again, i think we are dismissing the relevance of the other type of 
victims involved... those who *receive* the hijacked routes announcements 
and can be easily tricked by "oh, this is the dutch parliament's space, so 
this should be fine" and then their packets go towards the hijacker's 
network/systems. That's a clear path to enable "impersonation", "fraud", 
and so on...


=======

> 3. "So even if they would get the Bulgarian spammer/hijackers in front 
> of a Dutch judge .. the change was that ... they would walk, because there 
> was no harm done .. No law was broken, no system invaded and nothing 
> stopped working..."

I think 2019-03's goal is not to bring more people from around the world 
in front of Dutch judges. :-)

With this self-regulatory framework in place hijackers (and everyone) will 
have in writing that their actions are not tolerated by the community, and 
if it comes to that, their 'business model' will be somewhat affected if 
they need to gather/find new numbers to resume their line of 'business'.


=======

> 4. "So in this case, the Italian Police (ROS) used (forced??) an Italian 
> ISP to hijack some IP space to regain control of their lost RAT C&C 
> server.. (endpoint for RAT infected machines.) This wasn't an accident 
> .. but was it criminal by the ISP to assist their local police ? And 
> what would have been the impact if they didn't... ?"

While this might be indifferent for the average Internet User in 
Kazakhstan, Malaysia, Chile, Canada, Seychelles or Belize, and any of them 
might argue this line of action should have a consequence, the best way 
2019-03 tries to accomodate this type of corner cases is the ratification 
phase. Those who will have to ratify a 2nd instance report can be provided 
with enough evidence (an Italian court order?) so that ratification 
doesn't occur.

Even if this isn't the case (and no evidence is provided) or the report 
even disputed, the ISP can only get a warning (and the concrete 
consequence is out of 2019-03's scope).


=======

> 5. "These are your/our tax dollars at work ...  They either don't care 
> or are the bad actor themselves."

It depends on the viewpoint and the available set of evidence. In this 
case it can also be argued that it was a good actor. :-)

Additionally, nothing guarantees that a report/complaint is going to 
be issued against _every_ hijack. Also, admissible evidence (from 
historical routing data) will have an expiration timeframe in version 
2.0.


=======

> 6. "So the customers that hold an SSA or End-User Agreement (PI Holders 
> for IP space and AS number) look to be the 'target' of the policy, 
> however that leaves out the legacy resource holders.."

That is unaccurate. The 'target' is everyone who intentionally performs an 
hijack. About the legacy resource holders, if they violate RIPE policies, 
i don't see why their access to NCC's Services can't be denied 
(permanently or temporarily?) -- that's my interpretation, but we can also 
have a line about that in version 2.0.

If RPKI is not available for legacy resources, that might have some 
impact.


=======

> 7. "And with the current transfer policies in place, yes it is possible 
> to obtain a legacy AS number and a legacy IPv4 prefix ...for yourself .. 
> and those can't be 'retrieved' with this policy .. And even with the 
> policy, it isn't the RIPE NCC that COULD de-register them as they are 
> not allocated by the RIPE NCC in the first place ..."

Exactly. Here we agree. The only possible consequence/effect (imho) is 
denying access to services, based on non-compliance with RIPE policies.

Anyway, 2019-03 doesn't have the "recovering" of resources back to the 
NCC as a goal.


=======

> 8. "So Legacy holders (resources with a legacy status) are for obvious 
> reasons, excluded for penalties and out of reach. Also according to the 
> policy that specifies services to Legacy holders, as this policy doesn't 
> state that it wants to include and impact legacy holders."

I don't agree. If you check i was one of the co-authors of 2012-07 :-)
In my initial drafts for 2019-03, there was a line about legacy holders. 
It seems now clear it needs to be recovered for version 2.0 :-)


=======

> 9. "The biggest issue what I see in this policy, is that the RIPE NCC ( 
> either themselves or the Exec Board. ) is desired / aimed to pull the 
> trigger on a membership or contractual relationship."

And they could (the Exec Board) decide not to do it, due to the 
ratification section. But *today*, it's a tool they don't have.

If you are uncomfortable with the Exec Board, would the RIPE 
Chair/Vice-Chair be an acceptable alternative? Or should a different set 
of people be selected to have control over the ratification knob?


=======

> 10. "These kind of actions or decisions should be kept out of the RIPE 
> NCC office and the actual case and decision should be made by a court 
> and court order."

I fully agree the NCC staff should be completely kept out of this process. 
I'm not entirely sure about the Exec Board, but would easily agree on an 
independent set of people.

As you already stated, Dutch law has a loophole (ok, you might not see it 
as a loophole) where a BGP hijack is not illegal, so saying "come back 
with a court order" is something that obviously won't happen and hijacks 
can happily proceed without any major disturbance.


=======

> 11. "If someone likes to make the case that someone is in violation, 
> there should be a neutral judge that should review the case and the 
> accuser can go to the RIPE NCC with the result .. And the RIPE NCC will 
> just execute based on the outcome."

That's what we tried to design with 2019-03, where the "neutral judge" is 
a set of experts -- i.e. more than one.


=======

> 12. "I can understand the sentiment or intent of the policy, but I'm 
> against any form of policy where the RIPE NCC or the Exec Board will be 
> involved in the actual decision like this as it will impact their 
> neutral status and the fact they are opening themselves for liability 
> claims."

As i've written above, i'm open to suggestions about how to take the Exec 
Board out of the picture, so that could be incorporated in version 2.0 
(please see #9 above).


=======


Best Regards,
Carlos