[ARIN-consult] Reminder on ARIN Consultation on RPKI/BGP

[Owen DeLong]

> On Feb 21, 2024, at 06:42, John Curran <jcurran at arin.net> wrote:
> 
> 
>>> On Feb 21, 2024, at 1:56 AM, Owen DeLong <owen at delong.com> wrote:
>>> On Feb 20, 2024, at 16:55, John Curran <jcurran at arin.net> wrote:
>>> 
>>> Alas, the challenge is that there are legacy resource holders who have made a conscious decision 
>>> over the years that they are better off not entering into a registration services agreement with ARIN – 
>>> the same agreement that every other resource holder has & with the same terms and conditions – 
>>> and thus they decline to receive the full set of services as every other registry customer.   While it is
>>> possible that the benefits of RPKI will impact their consideration of the matter, it’s not at all assured.
>> 
>> In its current state, RPKI is at best a cryptographically signed hint at how to best spoof an advertisement.
> 
> That is case only for those who do not perform RPKI ROV – as it is those who fail to perform ROV (or rely
> on others that fail to perform ROV) that run the risk of routing impact by such spoofing… i.e., a self-inflicted
> injury to some extent. 

Simply untrue. All ROV does is ensure that the first AS in the AS path marches the ROA. Anyone who can find an upstream that doesn’t validate the advertised AS-path and isn’t carefully filtering what they accept from their downstream (not as hard as you might wish) can prepend the AS advertised in the ROA and achieve valid spoofed routes. 

> 
>>> As for the reason why, we’ve heard it asserted by some legacy resource holders that they hold 
>>> unspecified and/or unproven rights to their number resource entries in the ARIN registry, and 
>>> furthermore that entry into an ARIN registration services agreement would impact those rights.  
>>> While ARIN has changed the registration agreement several times to reduce the probability of 
>>> any conflict, it is a realistic concern given the otherwise indeterminate nature of the assertions. 
>> 
>> In my case, I entered into the ARIN Legacy RSA based on a set of conditions that were not expected to change. The
>> ARIN board chose to change those conditions over my objections, but would not give me the option of retaining my
>> resources and going back to an uncontracted state. Fortunately, I found a loophole by transferring my resources to
>> the RIPE NCC as uncontracted legacy resources, so my only relationship with ARIN regards my IPv6 /48.
> 
> That is not a “loophole” but rather a feature of the confederated nature of Internet numbers registry system – 
> each RIR community, through its own governance mechanisms, determines its own policies and services.   
> 
>>> ARIN was formed to take on full responsibility for the Internet number registry that was previously 
>>> administered under USG direction, and to provide a clear voice to this community on how these 
>>> number resources are managed.  We have provided this community with the ability to elect its own 
>>> governing body for ARIN (the ARIN Board of Trustees) and that body has consistently held for over 
>>> 25 years that that ARIN should provide legacy holders with the same basic registry services that they 
>>> were receiving at ARIN’s formation without cost or contract.  However, we have also heard consistent  
>>> community demand for equitable treatment of _all_ ARIN customers in terms of agreements and fees; 
>>> this should not be surprising given that the ARIN registry exists in service to the entire community. 
>> 
>> No, you have provided the membership, not the community, with the ability to elect the BOT and the AC.
> 
> Note that when ARIN was first formed even that ability for the community to elect a Board wasn’t present – 
> we had to define the membership and provide it with the right to elect the Board and the AC.   Over time 
> we have continued to vest more authority in the ARIN membership, and this has included the member right 
> to remove trustees, to be consulted on governance bylaw changes, etc. 
> 
> We have even gone as far as to place control over changes to the registration service agreement itself with 
> the members (as the latest RSA provides that ARIN may only modify its terms for a compelling need to due 
> to a discrete, identifiable change in relevant statute or caselaw, or upon recommendation of the Board with 
> a ratification by ARIN member vote.) 
> 
>> Please note that the membership consists solely of those who have both opted in to some form of RSA and expressed a desire to participate in ARIN governance.
> 
> To be clear, the membership now consists of all organizations receiving ARIN services for their Internet 
> number resources under contract (this includes IPv4, IPv6, and ASN holders), as these are all Service 
> Members.  Those that wish to participate in ARIN governance may opt to become ARIN General Members 
> (by agreeing to vote in elections, be published in the membership directory, contacted with governance 
> information, etc. )
> 
> The goal is a stable self-governing organization that allows those in the community that wish to participate
> in governance to have a voice in the way that number resources are managed in the registry, and those 
> simply want to receive registry services to do so without the overhead of governance involvement.   One
> doesn’t have to participate in ARIN governance, but you are still governed by the whatever those that do 
> participate end up deciding. 
> 
>> Further, the holding of the BoT that ARIN should provide those services to legacy holders without contract or cost is widely understood to be a promise ARIN made to the resource holding community at or near the time that it was awarded with that responsibility.
> 
> ARIN has continued provide such service to date, as it has been viewed as appropriate course by the 
> member-elected Board of Trustees.  Ultimately, however, ARIN is a membership organization, and it will 
> take whatever course of action is set by the ARIN membership who choose to participate in its governance. 
> 
>> ...
>>> However, if they want to receive all of services that have been funded by the ARIN members – such as 
>>> authenticated IRR and RPKI – then they have to agree to the same registry terms as everyone else. 
>>> Doing so is quite simple, but does require being comfortable with being treated the same as every other 
>>> ARIN member – a problematic requirement for some given that they hold inherently inequitable beliefs
>>> regarding their number resources in the ARIN registry. 
>> 
>> IMHO, this is a derogatory and unfair characterization of the legacy holders who have, for various reasons, chosen not to adopt the ARIN RSA.
> 
> Apologies, it was not my goal to cast aspersions on those who have chosen not to enter into a registration 
> services agreement, but rather to simply convey (in a clear and accurate manner) the inherent conflict between
> their expectations and ARIN’s goals of a member-governed organization that provides equitable treatment of
> all members. 

Well, since legacy holders without contract aren’t members, I guess you’ve done that if you consider the current treatment of members equitable. I’m not saying it is or is not here, but pointing out that since legacy holders without contract aren’t members, they aren’t part of your defined equitable treatment goal as you have stated it here. 

> I note that this thread, while perhaps informative on several related topics, has wandered a bit astray from the 
> original question of the community consultation – i.e., the proposal that we change the ARIN Online interface 
> for the Hosted RPKI service to provide additional information on current routing state to the user (as further 
> described here – https://www.arin.net/participate/community/acsp/consultations/2024/2024-1/)   
> 
> To the extent that there is further feedback or suggestions regarding this proposed service change, please 
> provide it here on the list as soon as possible (as this consultation will close in just over one week’s time.) 

I don’t have a dog in that particular fight as I see hosted RPKI as a further degradation of the (minimal) security potentially provided by RPKI. 

Owen

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-consult/attachments/20240221/b5bdc5c9/attachment-0001.htm>