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

Hi Richard, All,

Thanks for your input. Please see inline.


On Sat, 30 Mar 2019, Richard Clayton wrote:

>    <quote>
>    There are already enough sources of historic and almost real-time
>    routing data which function as a worldwide observatory. From these
>    sources it is possible to accurately evaluate who is performing BGP
>    Hijacks and harming (or trying to harm) third party networks by
>    doing so.
>    </quote>
>
> It is not necessarily the case that BGP hijacks will be visible in the
> globally collected datasets. what then ?

Then if there is no available proof related to a specific hijack, the case 
should be extremely hard to obtain confirmation from experts (or even 
reach the 2nd round of experts).


> Also, where the resources of defunct companies are hijacked then it is
> not the routing table which will be key evidence but rather the
> paperwork on file at the RIR or elsewhere. There is no discussion of
> this aspect of the issue at all (despite it being a major component of
> hijack events over the past five years)

If that data is not public, then it could hardly be referenced within a 
report filed with the RIR...... if it is public (through a companies' 
register?), i think it could be referenced so the experts can check.
I think looking at BGP neighbors might also provide some insight. But 
anyway, if there isn't enough evidence, a complaint/report should be 
dismissed.

Do you have any suggestion to improve the process?



>    <quote>
>    The external experts are mere evaluators, who can use available sets
>    of routing data to determine whether BGP hijacking events have taken
>    place, and whether were intentional.
>    </quote>
>
> It is NOT possible (for experts or almost anyone else) to accurately
> evaluate who is performing BGP hijacks -- for every announcement there
> will be at least two networks (AS numbers) who might have done it and
> the experts will be using their skill and judgment to guess which of
> them is culpable.

I think a report should only point to _one_ specific party. If it points 
to the legitimate holder, then it's logical to dismiss it. If this is not 
the case, then it should be looked into by experts.



> Although in many cases it is "obvious" who did it, there is always at
> least one other AS on the path who is able to "frame" the suspect and so
> the experts are mainly deciding how plausible it is that someone is
> being framed

The keyword here should be *persistent*.
If you see several hijacks from the same source.......
If not, anyone who is accused should have the opportunity to defend 
itself. The process could (and will) be more detailed, but the checks & 
balances already described were designed in a way that only after 
the ratification phase, an accused party is considered to have done an 
intentional hijack. It's not the accused party who has to prove that they 
didn't do it, it's the evidence that needs to be compelling enough so 
there are no doubts to (a significant amount of) experts that an 
intentional hijack had its origin on the accused party.

But again, let me remember you... a process will primarily depend on a 
report.



>    <quote>
>    The direct upstreams of the suspected hijacker, which facilitate the
>    hijack through their networks, may receive a warning the first time.
>    Nevertheless, in successive occasions they could be considered by
>    the experts, if intentional cases are reproduced, as an involved
>    party.
>    </quote>
>
> This is pretty opaque ... but if it is meant to be read as "global
> transit providers are responsible for the behaviour of their customers"
> then this is what Sir Humphrey would call a "courageous" approach.

No. Maybe a clarification is needed here, and possibly some rephrasing -- 
a transit provider should receive notices *after* an intentional hijack is 
determined and ratified. The spirit of the text above was to discourage 
people to "owning company A and B to Z, sourcing the hijacks at B and 
provide transit through A, then repeat replacing B with C, D, E, and so 
on... and keeping the transit through A".

We need to find the best wording possible, but "global transit providers" 
and "internet exchange providers" are not seen by the authors as possible 
"accused" parties.
I mean, it's possible that anyone will file a report including companies 
that fall under those categories, but those will most likely be easily 
dismissed by experts.



>    <quote>
>    The expert?s investigation, will be able to value relationships
>    between LIRs/end users, of the same business groups.
>    </quote>
>
> How ?

Looking at public companies registries, for once...
"same business groups" could possibly be reworded into "same ownership".



>    <quote>
>    Accidental cases or those that can?t be clearly classified as
>    intentional, will receive a warning, which may be considered if
>    repeated.
>    </quote>
>
> this is incoherent -- and there does not seem to be any clarity about
> what a "warning" means from a consequences point of view

Noted. The text needs more clarity. It means a message should be generated 
to the party in question. It _doesn't_ mean, "the next time it won't be 
just a warning" :-) For me it's just a "this looks odd, please take a 
look".

>From my point of view, experts _shouldn't_ be able to ADD any accused 
parties to the cases they evaluate. I'm comfortable if the "warnings" are 
not publicly visible.



>    <quote>
>    As soon as the policy implementation is completed, a transition
>    period of 6 months will be established, so that organizations that
>    announce unassigned address space or autonomous systems numbers, due
>    to operational errors or other non-malicious reasons, receive only a
>    warning.
>    </quote>
>
> This section of the text is presumably meant to address the "bogons"
> issue -- the long-standing disputes between various networks and the
> RIRs as to whether or not they are entitled to announce various prefixes
> or use particular AS numbers.

Yes. While "warning" here might be a slightly different concept from the 
"warning" above. :-)


> It seems optimistic to assume these issues will be addressed in six
> months. Or perhaps you are expecting ARIN (and all the other RIRs) to
> void contracts with the US Department of Defence, with Level 3, with
> CenturyLink, with Hewlett Packard, with Verizon, with Comcast, with AT&T
> and with Rogers ??

What do you suggest?
Scrap the 6-month transition period? Or extend it?
Or treat all existing bogons at the implementation date as "exclusions"?
If this can't be fixed, at least new bogons shouldn't emerge, right?



>    <nonquote>
>    crickets
>    </nonquote>
>
> There is no discussion of the mis-use of AS numbers. Arguably this would
> be merely a clarification, but it would I think be a useful one to
> assist the experts in their proposed work.

Thanks for reminding us about this!

I've rephrased a passage in section 2, on v2.0's draft:

«The announcement of unallocated IP address space or unallocated 
autonomous system numbers to third parties is also considered a policy 
violation and is evaluated according to the same parameters.»

Also added the reference to ASNs on the "Lines of Action" section.



>> Actually, question for the chairs and Marco. Do you think it makes sense to
>> continue the discussion with the current version before improving it, or already
>> sending a new one?
>
> Sending RIPE the ARIN version which hardly addresses key technical
> points which have been made to you does not seem especially valuable

Each region has it's specific PDP, we didn't aim to have ARIN's v1.0 
fully aligned with RIPE's v2.0. We're still editing RIPE's v2.0.



> Also, of recent days there has been some (ill-informed) discussion about
> RPKI and the use of ROAs to settle disputes about hijacking. There is no
> mention of this in the ARIN document so it is not possible to identify
> whatever technical implausibility will be put forward.  (Hint: RPKI is
> great for reducing the incidence of "fat fingering", it merely provides
> a slight (if that) impediment to an intentional hijacker)

The point was probably: "OK, you say you are the legitimate holder. Then 
please create a ROA, so there is no doubt about it."



>> There is a lot of improvement already, the discussion has
>> been extremely useful for the authors. However, we are missing some NCC inputs,
>> for example, regarding legal questions that we raised several times, so if
>> sending a new version means we can't get those inputs, then is not good ...
>
> This relates to the part of the document where, having established that
> in intentional hijack (or some vaguely defined never-ending series of
> fat fingers) has occurred then there are consequences for the
> organisation found at fault.

Don't you think that "fat fingers" are easily identifiable, if you hold 
x.y.z.0/24 and you start announcing x.y.z+1.0/24? Or if you happen to 
start announcing a /23 when you hold only the /24?
Also, the idea is that any accused party can explain to experts how they 
fumbled...



> it's pretty clear to me that the majority of the objections made to the
> proposed policy address this issue (maybe because it is thought you
> might eventually address the detailed technical objections).

So, do you think a reference to RIPE-697 could be useful?



> I don't think (but this is not really my expertise) that a legal opinion
> (on what exactly?) is going to address most of the objections being made
> which relate to the whether it is appropriate for a technical
> transgression to result in resources being withdrawn.

"repeateadly technical transgressions"?


> The lack of clarity over the bogons issue doubtless makes everyone think 
> "that might be me"

We might be flexible about that -- i mean, relating to already existing 
bogons. :-) Does it sound like a good compromise?



> To assist the authors -- your view that "experts" can decide what is or
> is not a hijack is aspirational. It is also not how technical experts
> are used in the real world -- they generally assist adjudicators to make
> fair decisions, they do not make those decisions themselves. It would be
> far better to have the NCC Board decide whether hijacking has occurred
> but suggest that they should call upon experts as needed

At this point our vision is to minimize the NCC Board's intervention, 
while it should have the definitive word if two rounds of experts agree on 
an intentional hijack.



> To assist the chairs -- if the ARIN document was brought to RIPE I would
> not be in favour of it being adopted by RIPE. I say this as someone with
> extensive experience of tracking down and dealing with BGP hijacks by
> criminal groups.. my technical points come from experience.

We are planning for a version 2.0 in RIPE, which will not be obviously 
100% coincident with ARIN's version.


Again, this was very useful. Thanks!

Best Regards,
Carlos


>
> -- 
> richard                                                   Richard Clayton
>
> Those who would give up essential Liberty, to purchase a little temporary
> Safety, deserve neither Liberty nor Safety. Benjamin Franklin 11 Nov 1755
>