RPKI is not an unalloyed good thing. The Internet routing system (based on BGP) is currently a completely decentralized system. There are no single points of control in it. If you want to route your own traffic to network X via interface Y, there is nobody who can tell you different; and you can advertise that route to any or all of your BGP neighbors, again no matter who cares to say no. (Those neighbors make their own individual decisions about which routes they will pick up from you, use themselves, and/or spread further.) Globally distributed protocols with no central control mechanism are rare and fragile(*). We should not help to destroy this one blindly. A huge part of what enabled the Internet to grow worldwide over 40 years, yet remain reliable and uncensorable, is exactly this lack of central control. RPKI is an effort to destroy it. RPKI puts the Regional Internet Registries (RIRs), at the top of a newly created cryptographic authentication pyramid for network routes. The RIRs are ARIN, RIPE, APNIC, LACNIC, and AfriNIC. Those nonprofits are "stewards" of the Internet address space, but like every person and every entity they tend to serve themselves better than they serve others. And they serve themselves more power by making themselves the arbiters of which addresses can be routed by whom. If the RIRs succeed at capturing control of the routing system, then, indepedent of whether the RIRs are good stewards themselves, there's another problem. Every country with jurisdiction over them will start leaning on the RIRs to censor the things that that government doesn't want the public to have access to. We have already seen plenty of countries, including nominally liberal democracies like Australia and the UK, issue orders to their ISPs to block traffic that the government disapproves of. Whether it's "to save the children", to "combat terrorism", to "deter fraud", to "smash spammers", for "national security", to "stop fake news", to "allow people to outlive their past", or whatever. A long history of such censorship lists shows that the first thing they censor is the list of what's actually being censored, and then with no public oversight, all kinds of things get censored that don't deserve it. Currently the RIRs have power over IP address allocations only in subnets allocated to them by IANA. And this power does not extend to any technical control over routing systems -- without RPKI, it's just advisory. Anyone foolish enough to sign a contract with an RIR has also granted the RIR the power to cancel their IP address allocation at will (and to demand significant annual payments just for keeping your few thousand bytes in a database entry). But, 70% of the Internet addresses were allocated before the RIRs even came into existence. Those "legacy" addresses, including 44/9 and 44.128/10, are NOT under the control of any RIR. The RIRs have always chafed at this limitation, and they tried to strangle the commercial market for IP addresses at birth, by passing rules outlawing sale of addresses, preferring instead that anybody who didn't want their IP addresses had to return them for free to their regional RIR, and then it would decide who would get them and on what terms, including what the recipients would pay for them. (Their effort failed.) The creation of a commercial market for IP addresses was a threat to them, because the RIRs' power always derived from their ability to rent you IP addresses that you couldn't get elsewhere. But that power is dissolving now that they have little or no IPv4 address space to hand out. They could have become honest registrars of third-party transactions, like any county's land deed registry (which doesn't also have a parallel business that allocates land to the needy), but they prefer a more powerful role. So they are looking for other levers of power. By default, the RIRs have been the "deed registries" of IP address space, since they kept the database of their own numerous handouts, and copied in the small number of older IANA entries for earlier legacy allocations. They tried, unsuccessfully, to get legacy address holders to sign a contract with them, the LRSA contract, in return for keeping the legacy entries in the database up to date. But everyone quickly realized that if you DON'T sign with the RIR and if they DO let your database entry get out of date, then the RIR's database becomes less and less useful to everybody. Which lessens their power -- why would anyone even bother to consult a deliberately inaccurate "deed registry"? So at the moment, the RIRs cheerfully let you update your database entry if you're a legacy address holder. EXCEPT if you sell your space -- then their current rules "require" the buyer to sign a contract of adhesion with the RIR. Some RIRs also demand that the buyer "prove" bureacratically that they need the addresses that they're spending good money to purchase. I expect that those requirements, too, will go by the wayside, if they haven't already in practice, because there is no upside for the buyer in doing so, and there is a significant downside (they can reject your purchase attempt, you have to pay them annually, and they can make up new rules and/or cancel your addresses anytime). If buyers refuse to sign up and pay annually, and just go ahead and start using the addresses they bought, the RIR database again would go out of date, which is not to the RIR's advantage. It's better for the RIR AND better for the IP address users, to let sales proceed, and record them honestly, without long-term contracts, without control, without annual fees -- than for the RIR database to become completely irrelevant. So, with this as background, RPKI looks like a great way for RIRs to assert control over legacy address space. Like a Mafia enforcer, "Nice IP addresses you've got there -- I hope you don't want to ROUTE THEM OVER THE INTERNET? You'll have to pay us for that privilege. See, we already have 18% of the Internet routers taking instructions from us, and if we don't sign your ROA, then 18% of the Internet won't be able to reach you." Every time an ISP newly demands ROAs, they incrementally add to the power of the RIRs as points of centralized control over things they formerly had no control over. RIPE has been the leader in developing RPKI and pushing the European region's ISPs to ask users to adopt it. It doesn't have much traction elsewhere. You can see some global stats on deployment of RPKI here: https://rpki-monitor.antd.nist.gov/ Currently 18.9% of global Internet routes have "valid" RPKI certificates, 0.82% have "Invalid" RPKI certificates, and 80.28% are not covered at all by RPKI certificates. In the ARIN region, 91% are not covered by RPKI. The RIRs don't like to point this out when encouraging ISPs to demand ROAs. ARIN itself doesn't use RPKI to manage its own Internet routers; see: https://www.arin.net/participate/community/acsp/suggestions/2018-13/ And there's a reliability issue. ARIN requires anyone who relies on their RPKI database to sign a contract that specifically absolves ARIN of any responsibility, if relying on them causes a problem. This contract specifically states that RPKI should *not* be used "in connection with equipment in hazardous circumstances or for uses requiring fail-safe performance, including uses in connection with the operation of nuclear facilities, aircraft navigation or communication systems, air traffic control systems, or weapons control systems, where failure could lead to death, personal injury, or severe environmental damage." It also says that "ARIN DOES NOT REPRESENT, WARRANT OR COVENANT THAT ANY ORCP SERVICES, CERTIFICATE, OR ANY ACCESS OR USE THEREOF WILL (i) BE UNINTERRUPTED, (ii) BE FREE OF DEFECTS, INACCURACIES, OR ERRORS... IN NO EVENT ... WILL ARIN’S LIABILITY TO YOU OR ANY THIRD PARTY, INCLUDING ANY OF YOUR CLIENTS OR CUSTOMERS, EXCEED ONE HUNDRED U.S. DOLLARS (US$100.00) IN THE AGGREGATE." You're on your own, suckers! It gives us power, but we are NOT responsible! https://www.arin.net/resources/manage/rpki/rpa.pdf So if you're a ham providing emergency systems for disaster communications, don't use RPKI to control your routers. And find an ISP that doesn't use RPKI to control their routers either. Don't get me wrong -- besides the Internet power politics, there is an actual problem with people hijacking other peoples' routes occasionally. Spy agencies cause their national ISPs to make "mistakes" that reroute large amounts of big companies' traffic past their wiretapping stations, "oops". Spammers like to borrow others' address space. ISP technicians mistype numeric IP prefixes and take out other peoples' addresses. Etc. See: https://en.wikipedia.org/wiki/BGP_hijacking I just don't think imposing a centralized RPKI system is a good solution to this problem. (Particularly with bureacracies desparate for new powers exerting the control. Look up Harry J. Anslinger for an instructive example.) John (speaking for myself, not for ARDC nor for net44) (*): How many globally distributed systems without centralized control can YOU think of? The Usenet used to be one, though I'd guess it's down to under a hundred sites now (maybe down to 3!). Kademlia-style distributed hash tables are another. Blockchains are another. Can you think of any more? ALL of these rely on the global Internet routing tables today. (Usenet was formerly distributed by direct modem links among sites, and over internal company leased lines, but it has entirely moved onto the Internet now.) So, if you can centrally control the global Internet routing tables, you can centrally control ALL the globally distributed systems, even if they "have no centralized control" built into their own protocols. Nice power play if you can sneak it through! _________________________________________ 44Net mailing list 44Net(a)mailman.ampr.org https://mailman.ampr.org/mailman/listinfo/44net

The Internet routing system (based on BGP) is currently a completely decentralized system. There are no single points of control in it.

you want to route your own traffic to network X via interface Y, there is nobody who can tell you different; and you can advertise that route to any or all of your BGP neighbors, again no matter who cares to say no. (Those neighbors make their own individual decisions about which routes they will pick up from you, use themselves, and/or spread further.)

Globally distributed protocols with no central control mechanism are rare and fragile(*). We should not help to destroy this one blindly. A huge part of what enabled the Internet to grow worldwide over 40 years, yet remain reliable and uncensorable, is exactly this lack of central control. RPKI is an effort to destroy it.

created cryptographic authentication pyramid for network routes. The RIRs are ARIN, RIPE, APNIC, LACNIC, and AfriNIC.

Those nonprofits are "stewards" of the Internet address space, but like every person and every entity they tend to serve themselves better than they serve others. And they serve themselves more power by making themselves the arbiters of which addresses can be routed by whom.

subnets allocated to them by IANA. And this power does not extend to any technical control over routing systems -- without RPKI, it's just advisory. Anyone foolish enough to sign a contract with an RIR has also granted the RIR the power to cancel their IP address allocation at will (and to demand significant annual payments just for keeping your few thousand bytes in a database entry). But, 70% of the Internet addresses were allocated before the RIRs even came into existence. Those "legacy" addresses, including 44/9 and 44.128/10, are NOT under the control of any RIR. The RIRs have always chafed at this limitation, and they tried

Don't get me wrong -- besides the Internet power politics, there is an actual problem with people hijacking other peoples' routes occasionally.

I think we could run our own RPKI but the ARIN won't sign us. Therefore we would just have to publish our trust anchor for others to include in their validators if they must use it..

I would certainly be interested in RPKI implementation, and a few questions come to mind. First, I'm curious is it possible to use the ARIN hosted TA even though it's legacy space? Also, I'm wondering how the ROA creation and signing process would be handled. It wont work to have the entirety of AMPRNet signed for AS7377 AMPRGW announcement, so we would have to come up with a way to create ROAs for the other networks authorized to announce smaller allocations. Nate Nate On Sun, May 24, 2020 at 9:06 PM Bryan Fields via 44Net <44net(a)mailman.ampr.org> wrote: _________________________________________ 44Net mailing list 44Net(a)mailman.ampr.org https://mailman.ampr.org/mailman/listinfo/44net

It looks like ARIN supports delegation[0], the model seems like what the relationship between 44net and ARIN  now? If that works, maybe It's like this: ARIN delegates [44/9, 44.128.0.0/10] to AMPRNet/ARDC, and they run a subordinate CA to issue RV records. Configure and keep running a compliant CA can be a real challenging though.

It's an interesting problem, what do other non ARIN members do for their own legacy space for ROA's? My guess is this is similar to the situation "alternative gTLD root" servers found themselves in many years ago. I bet we could ask common RPKI software to update their default list to include this "legacy" trust anchor. Now would be the time, as the universe of RPKI software is small. I'm happy to foot the bill for the Krill instance on DigitalOcean or the likes, maybe Chris (VE7ALB) can provide some assistance? --Matt On Tue, May 26, 2020 at 2:03 PM Bryan Fields via 44Net < 44net(a)mailman.ampr.org&gt; wrote: _________________________________________ 44Net mailing list 44Net(a)mailman.ampr.org https://mailman.ampr.org/mailman/listinfo/44net

Hi, On Wed, May 27, 2020, at 13:54, Christopher Munz-Michielin via 44Net wrote: You'd need to publish a "Certification Practice Statement" and adhere to the procedures described in that document, then RPKI vendors are able to understand the nature of the service and can test how it would interact with their existing systems. As an example: my expectation would be that network operators require the Trust Anchor's top-level certificate to immediately narrow its claimed certification authority to the 44net blocks themselves and nothing else.

We should note there currently is no industry-recognized procedure to establish and globally recognize new RPKI Trust Anchors, other than perhaps ICANN's ICP-2 process.

In summary: I expect that setting up RPKI services for 44net will be costly to operate and a lot of paperwork. I'm not saying this to discourage you, just to help recognise that it would be a significant project.

Kind regards, Job _________________________________________ 44Net mailing list 44Net(a)mailman.ampr.org https://mailman.ampr.org/mailman/listinfo/44net

On 5/24/20 11:26 PM, Scott Nicholas via 44Net wrote: I would be interested in doing this. I had a pretty long talk about it at a hotel bar about this very thing last year. It wouldn't be that hard IMHO. This does beg the question, is ARDC trustworthy/open enough to be the anchor of this?

ARIN does not run an RPSL-style database (unless that's changed recently) so has no concept of a "route object" the way that you are thinking of it.

ARIN does not run an RPSL-style database (unless that's changed recently) so has no concept of a "route object" the way that you are thinking of it. Some large providers operate their own RPSL-style database that they use to build policy for their routers out of. That makes quite a lot of sense once your network is big enough that you can't just use a text file, and it doesn't rely on anyone external to operate your database for you. You are free to have your own view of the world. It's a very different culture than what we have in RIPE-land. I agree with John that this lack of centralisation made possible, the proliferation of the Internet early on. Nowadays, in normal circumstances, we're not so much concerned with the proliferation of the Internet, in many places it's saturated. The industry has consolidated itself to a large extent. However, in disaster or crisis situations, you need agility. Sometimes you have to do things that were not forseen when the centralised synoptic view of the world was created. Especially for amateur radio operations it is crucially important not to hem ourselves in when we are needed most. This means not documenting ourselves in databases in an inflexible way that will be believed over the reality on the ground and restrict our ability to work. Speaking from personal experience in disasters and crises, it can cost lives. There is also the RADB which attempt({s?,ed?}) to be a place where people can publish their route objects and intended policies. Nobody trusts it because anybody can put anything in it and corrections are handled reactively after the fact. Best, -w

From a technical standpoint, this logical extension of systems makes a

Thomas, You say On Tue, Jun 2, 2020, at 04:17, Thomas Jones - KG5ZI /8 via 44Net wrote: And ... What are you really saying? These statements seem at odds with each other. How do you protect your internet? Maybe I can learn some tricks from you? Kind regards, Job _________________________________________ 44Net mailing list 44Net(a)mailman.ampr.org https://mailman.ampr.org/mailman/listinfo/44net

I can sympathize with the sentiment that RPKI and widespread RPKI adoption in its current form will really lock out and disenfranchise smaller network operators. Now, *more than ever*, we need to enable an Internet that any organization (a natural person, a registered entity, a hackerspace, etc.) can connect to, uniquely address itself, and begin exchanging traffic. In order to enable such an open system to function, we also need ways of ensuring that unicast addresses are unique and that there is some public, verifiable way of claiming ownership of IP space. Without this, the entire network is open to disruption and abuse by almost any operator. It's amazing we have gotten so far on the good will of most operators. The RIR model of lawyers, paperwork, and public databases works for a lot of people and organizations. IRR was the first step, but it was complex and a bit clunky to use. I see RPKI for Origin Validation as just the first/next step of extending this model of trust and numbering resource ownership into the routing protocol space more directly. From a technical standpoint, this logical extension of systems makes a lot of sense and I don't have a problem with it. For commercial network operators, a RIR registration is just the cost of doing business. But for many small nonprofits, regional amataur radio/network operators, or individuals, a few thousand dollars/euros a year is a lot of money that makes Internet independence out of reach. They end up having to resort to the hegemony of their local incumbent monopoly and chain themselves to the whims of their upstreams and regulators. I suspect many legacy resource holders find themselves in a similar limbo-state of not wanting to participate in the RIR model and pay money for essentially nothing. Echoing some similar earlier sentiments to want to create a CA for legacy address holders: How feasible would it be to create something RIR-like, but noncommercial? A place for legacy address holders to coordinate and register resources seems like a natural fit. If we're going to operate a database of ROAs, we're going to need some database of address space ownership. For 44net use cases, this seems really straightforward, since we have the Portal to draw from. But for other organizations, it gets a bit more complicated to do properly. Given some random email address/account in some hypothetical legacy RIR, how can we really validate that they're authorized to take actions on behalf of some organization? To take some random examples from the IANA IPv4 list: DISA, USPS, AT&T, Apple, etc. Doing this right is going to take some process, record keeping, and well.... work. With this context, I can see how a lot of RIRs go commercial. However, with a bit of automation, good documentation and records, and some dedicated volunteers, this seems like a really doable/achievable thing in the netops community. I would be curious to know if anyone else shares these views/dreams and would like to chat about it. Stay safe and sane out there. Cheers, jof On Tue, 2 Jun 2020 at 08:18, Job Snijders via 44Net &lt;44net(a)mailman.ampr.org&gt; wrote: _________________________________________ 44Net mailing list 44Net(a)mailman.ampr.org https://mailman.ampr.org/mailman/listinfo/44net

They would have to accept it much like ARIN and RIPE trust each other

CA's like Thawte or Comodo won't work for this, they're for web PKI not resource PKI. The 44.0.0.0/9 cert would have to be signed by one of the RIR's trust anchors (probably ARIN since they have 44.0.0.0/8 assigned to them) Thanks, Q On Wed, 10 Jun 2020 at 13:28, Tom Cardinal via 44Net < 44net(a)mailman.ampr.org&gt; wrote: wrote: _________________________________________ 44Net mailing list 44Net(a)mailman.ampr.org https://mailman.ampr.org/mailman/listinfo/44net

Cynthia, I only listed them as an example, my point was a having our own CA signed by a signing org that is trusted by RIRs. If that be ARIN then so be it. More importantly though, as you know, we have a legacy allocation. In my opinion we are equal to an RIR but with the ability to make global allocations from the 44.0/9 and 44.128/10 space. --ton/n2xu 44.98.63.0/29. On 6/10/20 7:38 AM, Cynthia Revström via 44Net wrote: 44net(a)mailman.ampr.org&gt; makes a _________________________________________ 44Net mailing list 44Net(a)mailman.ampr.org https://mailman.ampr.org/mailman/listinfo/44net