[arin-ppml] [EXT] Re: Open Petition for ARIN-prop-266: BGP Hijacking is an ARIN Policy Violation

[Owen DeLong]

> On May 3, 2019, at 14:48 , Carlos Friaças via ARIN-PPML <arin-ppml at arin.net> wrote:
> 
> 
> 
> On Fri, 3 May 2019, John Curran wrote:
> 
> (...)
>> Hank -
>> 
>> Yes, ARIN could add a statement to that effect to the registration services agreement ? note that the granting of rights to the address block in the registry is already present, so it?s really the addition of the grant of  "sole permission to announce that address block to the Internet? that would be added.
> 
> Hi,
> 
> But the data in the registry exists so that anyone can know who is the owner of a prefix, right?

Close, but not quite right.

The data in the registry exist so that anyone can know that the registration exists and the numbers are unique.

How that data is applied in the real world is not actually up to ARIN. It is ISPs who choose to operationalize that data as some
form of ability to announce a prefix. To the best of my knowledge, there is no legal basis for forcing ISPs to believe or
act upon any registration in the ARIN database in any particular way. Indeed, though this would be very problematic
and destructive, to the best of my knowledge, someone with a few servers could stand up their own IP registry tomorrow
and if they convinced enough people with enough routers to treat that registry as authoritative, there’s a very real
possibility that the RIRs could become utterly irrelevant.

Now, I think there’s lots of motivations for ISPs not to subscribe to such a registry and that as a result, such an event
is very unlikely. However, it is important to recognize when we start talking about issues like this that operational
implications of registry data are strictly by consent of the operators and not something which ARIN can mandate
or enforce in any way.

> The holdership allows the holder to announce to a single external party or to all the networks in the world (i.e. commonly, "the internet").
> This needs to be explicit?
> It isn't implicit that the registry data exists because the holder may want to actually use (at some point) the numbering resource?

It may be implicit, but it’s only implicit _BECAUSE_ operators choose to make that implication. There’s no contractual or legal
basis that I know of forcing them to do so.

>> The problem with such a statement is that it is either: 1) meaningless, or 2) creates obligations on recipients that are not clearly stated.
> 
> I fail to see "obligations on recipients". The only obligation needed is NOT announcing other parties' numbering resources.

I guess it depends on how you interpret the word announce.

If by announce you mean your obligation is not to originate an announcement of other parties numbering resources
without permission, then you are correct, that is a small and useful obligation.

OTOH, if you include renouncements of routes you receive from third parties that may or may not be under contract
with ARIN and thus may or may not have such an obligation, then it can get a lot more burdensome in a hurry.

Well, that’s quite an obligation if you’re a backbone provider that has customers who have customers who have customers.

You’r enow taking on the responsibility not only to validate your customer, but their actions, the actions of their customers, and the
actions of their customers customers and so on.

>> The reason why is that ISPs have the ability to configure their routers as they see fit, including deciding what routes they announce and what routes they accept.
> 
> As long as they announce their own routes, or routes they have authorization to announce…

The point here is that operators are not obliged to follow the registry in choosing what to announce or accept.
The registry has no power to force them to do so. Following the registry is strictly a voluntary act which is
very useful to the internet as a whole and so there is lots of peer pressure to do so and a high rate of
voluntary compliance. However, any belief that means the registry can somehow enforce the same rules
on those who choose to be bad actors is novel at best.

>> If the community wants to infringe on this freedom, then we need to be very clear on that point.
> 
> As a numbering resource holder (i.e. the org i work for) i certainly don't want to grant "the freedom" to originate OUR numbering resources to anyone! :-))))

You don’t need to… They’ve already got that freedom. The problem here is that there’s a belief that the RIRs somehow have the power to take that freedom away from them.

> The device may enable that, but the community should self-regulate to minimize these events.

For the most part, the community does self-regulate. However, the community in this context is subtly but meaningfully different from the community when we talk about ARIN policy.

The community for ARIN policy is those who choose to participate in the ARIN PDP.

The community that can self-regulate the contents of BGP announcements is the community of people running routers on the internet.

You bet there’s lots of overlap between those two communities, but ARIN has limited authority over the policy development community and virtually no authority whatsoever over the operations community, except as it relates to their interactions with the registry.

Guess what… Turns out BGP is NOT an interaction with the registry.

>> ARIN ?granting permission? for an ISP to announce a particular address block doesn?t have any meaning (they already can announce anything they wish) unless it also implies that ARIN doesn?t grant one permission to announce other not-assigned address blocks _and_ that you agree that your unauthorized announcement would be some form of breach of the agreement.
>> 
>> In effect:. ?Address Holder agrees to only route to the Internet its own address blocks, or those address blocks for which it has obtained permission of the registrant as listed in the Internet Number Registry System.?
> 
> Yes.

Spend a little more time thinking this through in the context of my expanded explanation above.

Owen


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20190504/081ee665/attachment.htm>