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
