[arin-ppml] prop266 - re-framing the discussion
Carlos Friaças
cfriacas at fccn.pt
Thu May 2 18:51:44 EDT 2019
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 <abagrin at omninet.io> 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 <athompson at merlin.mb.ca> 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)
> > athompson at merlin.mb.ca
> > www.merlin.mb.ca
> >
> >
> >
> > _______________________________________________
> > ARIN-PPML
> > You are receiving this message because you are subscribed to
> > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> > Unsubscribe or manage your mailing list subscription at:
> > https://lists.arin.net/mailman/listinfo/arin-ppml
> > Please contact info at arin.net if you experience any issues.
> >
> > _______________________________________________
> > ARIN-PPML
> > You are receiving this message because you are subscribed to
> > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> > Unsubscribe or manage your mailing list subscription at:
> > https://lists.arin.net/mailman/listinfo/arin-ppml
> > Please contact info at arin.net if you experience any issues.
> >
> >
> >
>
>
>
More information about the ARIN-PPML
mailing list