Hi,
On Thu, 2 May 2019, Scott Leibrand wrote:
(...)
However, some hijackers decide to use unallocated space or space which is
likely to be held by closed companies -- so a contact by the legitimate
owner becomes highly unlikely.
In that case, who is the party who is harmed by someone announcing unallocated
or unannounced space?
Those who receive it (and actually are able to send packets back towards
the hijackers).
> IMO "punishment" of those responsible for allowing hijacking seems like
something best solved through the legal system, not via extrajudicial penalties and fines
imposed by an industry association. But if we do decide
we want ARIN
> to create acceptable standards of conduct with regard to routing, and
fine resource holders who violate it, under threat of resource revocation if those
fines aren't paid, there will need to be a *lot* of work done to
set up such a
> system so that it doesn't risk ARIN picking a legal fight it's going to
lose, and putting the entire registry at risk.
I don't really see how the registry is more at risk when the data it
contains is made irrelevant by some of its members...
If ARIN overreaches in their attempt to penalize a large non-cooperative
well-lawyered transit provider for not filtering their customers well enough by
revoking their registrations, and that transit provider sues ARIN for
interfering with its business, it's likely that ARIN would lose a lawsuit and
either lose control over the registry and/or have to pay damages that might
bankrupt the organization. Those are the kinds of legal concerns that will
prevent ARIN from doing something that the community might otherwise want.
Maybe it's not explicit enough in this proposal's version, but the problem
here are not transit providers, but people who are _sourcing_ the hijacks.
Issueing notifications to transit providers could be useful, but typically
i don't see transit providers generating the hijacks themselves.
If a transit provider is not cooperating, that's unfortunate but still
fine. However, if the transit provider is "simulating" a customer so the
hijack can be blamed on that customer (that will easily go with the wind),
then the "hijacker role" needs to be re-evaluated...
(...)
If the answer is "zero" to both... then the legal system is not really an
option. :/
Even if there isn't a law explicitly disallowing BGP hijacking (I don't
know if/where there is), the legal system is still an option for going
after bad actors.
In theory i tend to agree. In practice, and especially in cross-border
cases, it isn't..... :-((
IANAL, but if nothing else, you can sue them in civil courts for the
damages caused by tortious interference with your business, or whatever
the proper legal term is for that. In the US, you can always sue
someone. ;-)
...for anything, but it doesn't guarantee it will be successful... :-))
Within ARIN, it might be a bit easier than within the RIPE NCC Service
region, which has more than 70 different countries (and legal systems), i
recognize that.
Thanks for your input.
Regards,
Carlos
-Scott
> On Thu, May 2, 2019 at 1:29 PM Andrew Bagrin <[email protected]> wrote:
> If the hijacking entity is not and ARIN customer, ARIN likely has
a relationship with adjacent ASN's that propagate the hijacked BGP routes and can
at the very least notify them that they are propagating routes
that have
> been reported as being hijacked. They can further repeat the statement with
a firm voice, and add "or else" at the end.
>
> Add penalties and fines could be a way to reduce prolonged propagation
of hijacked routes.
>
>
>
> On Thu, May 2, 2019 at 10:18 AM Adam Thompson <[email protected]>
wrote:
>
> Instead of focusing on whether the current proposal is or isn?t
in scope, I suggest we re-cast the discussion as follows:
>
>
>
> 1. So far, we have unanimous community agreement that BGP
hijacking is bad.
> 2. So far, we have broad agreement that ?something ought to be
done? about BGP hijacking, although detailed opinions vary significantly.
> 3. So what (else) can ARIN do about it? (Caveat: the answer
?nothing? is unacceptable to a significant proportion of PPML participants.)
>
>
>
> My suggested direction to the AC and/or the board would therefore
be: Find something ARIN can do to help combat the problem (more effectively). If
this requires expanding the scope of ARIN?s operations or
policies,
> bring that back to the membership (possibly via PPML?) with the
accompanying financial & legal analysis, as usual.
>
>
>
> Now the question becomes: what is the most appropriate mechanism,
within ARIN?s existing policies, to bring a request like that to the AC and/or
Board? It seems clear to me that the petition already underway here
is
> not meeting, and will not meet, the needs of the community very
well.
>
>
>
> -Adam
>
>
>
> Adam Thompson
> Consultant, Infrastructure Services
> merlin-email-logo
> 100 - 135 Innovation Drive
> Winnipeg, MB, R3T 6A8
> (204) 977-6824 or 1-800-430-6404 (MB only)
> [email protected]
> www.merlin.mb.ca
>
>
>
> _______________________________________________
> ARIN-PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List ([email protected]).
> Unsubscribe or manage your mailing list subscription at:
> https://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact [email protected] if you experience any issues.
>
> _______________________________________________
> ARIN-PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List ([email protected]).
> Unsubscribe or manage your mailing list subscription at:
> https://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact [email protected] if you experience any issues.
>
>
>
_______________________________________________
ARIN-PPML
You are receiving this message because you are subscribed to
the ARIN Public Policy Mailing List ([email protected]).
Unsubscribe or manage your mailing list subscription at:
https://lists.arin.net/mailman/listinfo/arin-ppml
Please contact [email protected] if you experience any issues.
