[arin-ppml] prop266 - re-framing the discussion
scottleibrand at gmail.com
Thu May 2 11:41:06 EDT 2019
> On May 2, 2019, at 8:29 AM, Fernando Frediani <fhfrediani at gmail.com> wrote:
>> On 02/05/2019 12:16, Scott Leibrand wrote:
>> ARIN’s only authority is to over their registry of who “has” which addresses, so the only thing I can imagine they could do would be to threaten to revoke unrelated registrations from a transit provider who willfully or negligently accepted the BGP announcement of space from an entity it wasn’t registered to. But if tier 1 transit providers aren’t willing to filter, let alone depeer, each other over hijacking today, it seems unlikely they’d be willing to stop accepting formerly legitimate prefixes from a peer or customer network just because ARIN is trying to take that space away to punish the network for accepting an unrelated hijacked announcement.
> It doesn't really seem to be this the discussion about Transit providers accepting or not certain announcements. Even if a Transit Provider accepts announcements from people who are not responsible for an allocation nor has authorization to do that they should only be warned to take correction measures. I don't think the main aim of the propose is do anything with Transit providers.
> Even in a hypothesis a Transit provider has no filters a hijack will not occur if a hijacker doesn't initiate it.
If the hijacker is someone with no relationship with ARIN, we can’t punish them by kicking them out of a club they’re not a member of. If you’re ok with ARIN doing nothing about hijacks by entities who don’t have ARIN resources, fine: that’s the status quo. But if you do want ARIN to do something on those cases (which I believe are the vast majority of hijacks) the only action I can see that ARIN could take at that point is against whichever of their transit providers is accepting the hijacked routes.
>> On May 2, 2019, at 7: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:
>>> So far, we have unanimous community agreement that BGP hijacking is bad.
>>> So far, we have broad agreement that “something ought to be done” about BGP hijacking, although detailed opinions vary significantly.
>>> 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 Thompson
>>> Consultant, Infrastructure Services
>>> 100 - 135 Innovation Drive
>>> Winnipeg, MB, R3T 6A8
>>> (204) 977-6824 or 1-800-430-6404 (MB only)
>>> athompson at merlin.mb.ca
>>> 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:
>>> Please contact info at arin.net if you experience any issues.
>> 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:
>> Please contact info at arin.net if you experience any issues.
> 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:
> Please contact info at arin.net if you experience any issues.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the ARIN-PPML