Hello all,
In 2018 I requested and received a /24 allocation and permission to announce it via BGP. My ISP/NSP, MonkeyBrains.net, very graciously agreed to route it to my house as part of my normal residential service. (Quite amazing!)
Now, however, they’ve sent me an unusual request (but they are excited about it): can I please setup RPKI for my IP allocation, authorizing them (MonkeyBrains) permission to advertise the block? Full quote below:
Hi Jermy,
We advertise a /24 for AMPRNET. Please setup a ROA record on ARIN authorizing us to advertise that block. (We just learned how to do this for our IPs yesterday and are exctied about RPKI.
If you haven't set up RPKI for your IP allocations, here are the steps in a nutshell:
create SSL key upload to ARIN Create ROA (image below) Thanks,
Rudy
HOW-TO on ARIN: https://www.arin.net/resources/manage/rpki/hosted/#roarequestkeypair https://slack-redir.net/link?url=https%3A%2F%2Fwww.arin.net%2Fresources%2Fmanage%2Frpki%2Fhosted%2F%23roarequestkeypair&v=3
I don’t think this is going to work as I don’t _OWN_ my block. It is licensed to me for a 5 year period. As such, there’s no record of my allocation with ARIN, and hence, nothing that I can assign.
Do any of you network gurus have a sufficiently technically advanced response I can give the ISP for their request?
73, -Jeremy Cooper
I am also in a similar position and am interested to improve the situation, if possible.
Previously, it was the case that 44/8 was a legacy resource that wasn't managed by ARIN, and so they didn't provide the delegation of the space. Looking again today, I see that "ARDC" is an OrgId in ARIN that holds the 44net IP space. Maybe that situation has changed?
If this is possible, somehow ARDC is going to need to tell ARIN about prefixes and authorized origin ASes. Since we already have an existing database of trust relationships with 44net operators in the portal, maybe a future feature could be to allow BGP-routed 44net operators to list their origin ASN(s) in the Portal for each assignment.
--j
On Thu, 30 Apr 2020 at 22:45, Jeremy Cooper via 44Net < 44net@mailman.ampr.org> wrote:
Hello all,
In 2018 I requested and received a /24 allocation and permission to announce it via BGP. My ISP/NSP, MonkeyBrains.net, very graciously agreed to route it to my house as part of my normal residential service. (Quite amazing!)
Now, however, they’ve sent me an unusual request (but they are excited about it): can I please setup RPKI for my IP allocation, authorizing them (MonkeyBrains) permission to advertise the block? Full quote below:
Hi Jermy,
We advertise a /24 for AMPRNET. Please setup a ROA record on ARIN
authorizing us to advertise that block. (We just learned how to do this for our IPs yesterday and are exctied about RPKI.
If you haven't set up RPKI for your IP allocations, here are the steps
in a nutshell:
create SSL key upload to ARIN Create ROA (image below) Thanks,
Rudy
HOW-TO on ARIN: https://www.arin.net/resources/manage/rpki/hosted/#roarequestkeypair <
https://slack-redir.net/link?url=https%3A%2F%2Fwww.arin.net%2Fresources%2Fma...
I don’t think this is going to work as I don’t _OWN_ my block. It is licensed to me for a 5 year period. As such, there’s no record of my allocation with ARIN, and hence, nothing that I can assign.
Do any of you network gurus have a sufficiently technically advanced response I can give the ISP for their request?
73, -Jeremy Cooper _________________________________________ 44Net mailing list 44Net@mailman.ampr.org https://mailman.ampr.org/mailman/listinfo/44net
Dear Jeremy,
I'm not speaking with any authority, but I've been watching the RIR / RPKI / BGP space for some time. I think it currently is not possible (or very difficult) to create RPKI ROAs for space from AMPRNET.
Availability of RPKI services (and certifiability) throughout the industry has been rolled out incrementally. For instance in Brazil RPKI wasn't available until recently (for LACNIC (RIR) -> NICBR (NIR) managed space), and in the South Korean NIR (KRNIC) as far as I know hasn't taken up the delegation from APNIC, so Korean space can't be signed today either.
My point is that there IP blocks for which nobody (yet) can create a RPKI ROA, because either there is a "Legacy" aspect that needs to be resolved or there is a lack of ability at the NIR level.
If you run into trouble with RPKI with any provider for AMPRNET, feel free to CC me at job@ntt.net - i'm happy to explain that RPKI ROAs can't be created in all cases.
RPKI is a global deployment effort that involves hundreds of organisations and thousands of people, in some (rare) cases RPKI ROAs can not be created, and I think AMPRNET is one of such cases.
Figuring out how to get AMPRNET space "RPKI enabled" probably will take between 12 and 24 months, it'll be a really big project with lots of paperwork.
Kind regards,
Job
On Thu, Apr 30, 2020, at 22:41, Jeremy Cooper via 44Net wrote:
Hello all,
In 2018 I requested and received a /24 allocation and permission to announce it via BGP. My ISP/NSP, MonkeyBrains.net, very graciously agreed to route it to my house as part of my normal residential service. (Quite amazing!)
Now, however, they’ve sent me an unusual request (but they are excited about it): can I please setup RPKI for my IP allocation, authorizing them (MonkeyBrains) permission to advertise the block? Full quote below:
Hi Jermy,
We advertise a /24 for AMPRNET. Please setup a ROA record on ARIN authorizing us to advertise that block. (We just learned how to do this for our IPs yesterday and are exctied about RPKI.
If you haven't set up RPKI for your IP allocations, here are the steps in a nutshell:
create SSL key upload to ARIN Create ROA (image below) Thanks,
Rudy
HOW-TO on ARIN: https://www.arin.net/resources/manage/rpki/hosted/#roarequestkeypair https://slack-redir.net/link?url=https%3A%2F%2Fwww.arin.net%2Fresources%2Fmanage%2Frpki%2Fhosted%2F%23roarequestkeypair&v=3
I don’t think this is going to work as I don’t _OWN_ my block. It is licensed to me for a 5 year period. As such, there’s no record of my allocation with ARIN, and hence, nothing that I can assign.
Do any of you network gurus have a sufficiently technically advanced response I can give the ISP for their request?
73, -Jeremy Cooper _________________________________________ 44Net mailing list 44Net@mailman.ampr.org https://mailman.ampr.org/mailman/listinfo/44net
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!
Here's another negative viewpoint.
https://iscloudflarerightyet.com/
Ron W6RZ
On 4/30/20 18:00, John Gilmore via 44Net wrote:
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@mailman.ampr.org https://mailman.ampr.org/mailman/listinfo/44net
Well, John, thanks for your wise argument. I understand this goes against your predilection for all things decentralized and unregulated. It’s a cogent argument that I’ve forwarded to the ISP owner.
In all fairness, he wasn’t insisting that I get an RPKI signature installed. He just sent out a form letter to all his customers informing them that RPKI is a “thing” and encouraging us to sign on.
-J
P.S. I used to attend the Cypherpunks meetings when they were held at Cygnus … albeit as a scrawny 17-year-old. Thanks for the time you took to write your reply.
On 2020-04-30, at 18:00, John Gilmore gnu@toad.com wrote:
RPKI is not an unalloyed good thing.
John,
On Thu, Apr 30, 2020 at 6:00 PM John Gilmore via 44Net < 44net@mailman.ampr.org> wrote:
The Internet routing system (based on BGP) is currently a completely decentralized system. There are no single points of control in it.
False, BGP as used on the Internet requires an Autonomous System Number. These numbers are issued by IANA, and further downstream by RIR's; such as ARIN in North America. An RF equivalent would be the ITU followed by the FCC/NTIA and finally state repeater coordination groups* (this is not 100% accurate but serves as a quick analogy)*. One could argue at a local level frequency allocations are "decentralized", but in reality they are not.
The protocol itself does have an allocation of "private ASN's", which aren't designed for usage on the internet - as the vast majority of providers filter these as a industry best practice. The protocol itself is very much decentralized in nature, however the operational usage on the internet is very much centrally coordinated and administered.
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.)
It is true that each BGP speaking organization can choose their own routing policy. This choice in routing policy has long existed, well before RPKI.
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.
False, RPKI exists for RIR's to continue to have a business model - it was never intended to break the globally distributed BGP protocol. If anything, RPKI exists to provide a global documentation trail of acceptable prefixes which abide by the trust ring, explicitly don't, or are of a neutral nature *(neither positive or false positive).*
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.
False, the RIR's were already "at the middle" of this trust chain *(IANA technically being the top)* - nothing new here. These organizations have long been the stewards of modern IP space, RPKI is a formalization of this documentation trail in a machine readable format, which operators can choose to use in their routing policies.
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.
The same could be said for ARDC, the steward of the remaining AMPRnet IP space. The level of transparency of all of the RIR's does vary, but they're certainly more forthcoming then ARDC has ever been. A good example is the lack of board meeting minutes, no published budget or P&L, etc.
My own personal operational experience is limited to ARIN and RIPE, both of these organizations ultimately do what their members ask of them - though sometimes with a strong legal focus *(ARIN more so than RIPE, though that seems more cultural to ARIN being a US entity operating in a US legal system). *They are great stewards of a shared resource, not perfect but their involvement has not hampered the internet's growth.
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
Can ARDC publicly admit that remaining allocations are not under ARIN stewardship *(either under an LRSA or RSA)*? The ARIN whois database shows updates as recently as a few weeks https://whois.arin.net/rest/org/ARDC ("Last updated 2020-05-01") ago for the ARDC organization record. Generally ARIN facilitates these changes via a web portal or API, these services are only available to ARIN members, which execute an Registration Services Agreement https://www.arin.net/about/corporate/agreements/rsa_faq/. It's highly likely that the Amazon transaction required that the "left over" prefixes be formalized with ARIN, likely with an executed RSA contract. Again, as the steward of this space - ARDC could choose to be more transparent with the operational nature of the transaction.
Don't get me wrong -- besides the Internet power politics, there is an actual problem with people hijacking other peoples' routes occasionally.
Maybe instead of focusing on your personal war against legacy prefixed holders and legitimacy of RIR's, instead focus on the real operational concern - thank you.
Several large tier 1 providers have begun filtering based on RPKI data, such as NTT, ATT, and many others. Does ARDC have a plan to support ROA's?
--Matt
Hello,
On Sun, May 24, 2020 at 9:17 PM Matt Peterson via 44Net 44net@mailman.ampr.org wrote:
Can ARDC publicly admit that remaining allocations are not under ARIN stewardship *(either under an LRSA or RSA)*? The ARIN whois database shows updates as recently as a few weeks https://whois.arin.net/rest/org/ARDC ("Last updated 2020-05-01") ago for the ARDC organization record. Generally ARIN facilitates these changes via a web portal or API, these services are only available to ARIN members, which execute an Registration Services Agreement https://www.arin.net/about/corporate/agreements/rsa_faq/. It's highly likely that the Amazon transaction required that the "left over" prefixes be formalized with ARIN, likely with an executed RSA contract. Again, as the steward of this space - ARDC could choose to be more transparent with the operational nature of the transaction.
False. You do not need to sign an LRSA or RSA to change whois records. See https://www.arin.net/resources/guide/legacy/services/. I suspect the latest change finally put Chris Smith as tech contact. I don't recall seeing it before.
When the news came in July of the sale I was excited because I thought one was signed and we would get to register to ARIN RPKI. Brian replied to me off-list (sorry for top-posts):
On Fri, Jul 19, 2019 at 8:18 PM Brian Kantor Brian@bkantor.net wrote:
No worries.
I believe the part we sold changed status, but the part we kept status was unchanged. - Brian
On Fri, Jul 19, 2019 at 08:13:37PM -0400, Scott Nicholas wrote:
Sorry. I figured it would be requirement to sell. That any change basically lost legacy status.
On Fri, Jul 19, 2019, 7:27 PM Brian Kantor Brian@bkantor.net wrote:
Where did you hear that?
It's still legacy space as far as I know!
ARDC has NOT signed an RSA or LRSA with ARIN. - Brian
Several large tier 1 providers have begun filtering based on RPKI data, such as NTT, ATT, and many others. Does ARDC have a plan to support ROA's?
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..
Regards, Scott.
On 5/24/20 11:26 PM, Scott Nicholas via 44Net wrote:
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 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?
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@mailman.ampr.org wrote:
On 5/24/20 11:26 PM, Scott Nicholas via 44Net wrote:
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 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?
-- Bryan Fields
727-409-1194 - Voice http://bryanfields.net
44Net mailing list 44Net@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.
--
[0]: https://rpki.readthedocs.io/en/latest/rpki/implementation-models.html#functi...
On A2020/05/25 PM0:38, Nate Sales via 44Net wrote:
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@mailman.ampr.org wrote:
On 5/24/20 11:26 PM, Scott Nicholas via 44Net wrote:
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 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?
-- Bryan Fields
727-409-1194 - Voice http://bryanfields.net
44Net mailing list 44Net@mailman.ampr.org https://mailman.ampr.org/mailman/listinfo/44net
44Net mailing list 44Net@mailman.ampr.org https://mailman.ampr.org/mailman/listinfo/44net
Yeah ARIN does support delegation to your own RPKI servers, this is what I run for my company - internal ROKI system based on Krill (https://github.com/NLnetLabs/krill) and then ARIN and RIPE sign my CA and delegate my resources.
Krill also supports self-signing, so it would be possible to host something completely independent of the RIRs, however, as has been mentioned before, the ARDC trust anchor would have to be manually included by all networks that implement RPKI filtering.
Chris VE7ALB
On 25/05/2020 10:29, Quan Zhou via 44Net wrote:
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.
--
On A2020/05/25 PM0:38, Nate Sales via 44Net wrote:
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@mailman.ampr.org wrote:
On 5/24/20 11:26 PM, Scott Nicholas via 44Net wrote:
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 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?
-- Bryan Fields
727-409-1194 - Voice http://bryanfields.net
44Net mailing list 44Net@mailman.ampr.org https://mailman.ampr.org/mailman/listinfo/44net
44Net mailing list 44Net@mailman.ampr.org https://mailman.ampr.org/mailman/listinfo/44net
44Net mailing list 44Net@mailman.ampr.org https://mailman.ampr.org/mailman/listinfo/44net
On 5/25/20 1:29 PM, Quan Zhou via 44Net wrote:
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.
ARDC is not an ARIN member, ARIN will not delegate to them. Full Stop.
If this is going to be a thing, it would have to be outside ARIN. I'd be in-favor of assisting on this, but we'd need buy-in from the users of RPKI to recognize the amateur certs.
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@mailman.ampr.org> wrote:
On 5/25/20 1:29 PM, Quan Zhou via 44Net wrote:
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.
ARDC is not an ARIN member, ARIN will not delegate to them. Full Stop.
If this is going to be a thing, it would have to be outside ARIN. I'd be in-favor of assisting on this, but we'd need buy-in from the users of RPKI to recognize the amateur certs. -- Bryan Fields
727-409-1194 - Voice http://bryanfields.net
44Net mailing list 44Net@mailman.ampr.org https://mailman.ampr.org/mailman/listinfo/44net
Happy to help set things up. From a technical perspective it would be relatively straightforward, the challenge is in getting the 44net trust anchor included by all the major RPKI vendors and networks. I'm not sure where to begin on that side.
Chris
On 26/05/2020 22:42, Matt Peterson via 44Net wrote:
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@mailman.ampr.org> wrote:
On 5/25/20 1:29 PM, Quan Zhou via 44Net wrote:
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.
ARDC is not an ARIN member, ARIN will not delegate to them. Full Stop.
If this is going to be a thing, it would have to be outside ARIN. I'd be in-favor of assisting on this, but we'd need buy-in from the users of RPKI to recognize the amateur certs. -- Bryan Fields
727-409-1194 - Voice http://bryanfields.net
44Net mailing list 44Net@mailman.ampr.org https://mailman.ampr.org/mailman/listinfo/44net
44Net mailing list 44Net@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:
Happy to help set things up. From a technical perspective it would be relatively straightforward, the challenge is in getting the 44net trust anchor included by all the major RPKI vendors and networks. I'm not sure where to begin on that side.
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
Hi,
On A2020/05/27 PM10:16, Job Snijders via 44Net wrote:
Hi,
On Wed, May 27, 2020, at 13:54, Christopher Munz-Michielin via 44Net wrote:
Happy to help set things up. From a technical perspective it would be relatively straightforward, the challenge is in getting the 44net trust anchor included by all the major RPKI vendors and networks. I'm not sure where to begin on that side.
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.
IANA CA is the root of all RIR CAs, maybe it's easier to work directly with IANA than millions of all equipment vendors.
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.
There's also a CA/B Forum been around for a while, regulating public facing PKIs. RPKI is like an adopted and striped to bare minimum PKI. It discourages use of identity assertions[rfc6480], has fewer x509 extensions[rfc6488], and is RSA only[rfc7935], the CPS template[rfc7382] is the BCP. This very scoped manner makes the CA much easier to implement with most preset defaults.
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.
This project looks fun and very rewarding than challenges it poses. Please allow me to have the honor of participation!
Best,
Quan
Kind regards,
Job
44Net mailing list 44Net@mailman.ampr.org https://mailman.ampr.org/mailman/listinfo/44net
Dear Quan,
On Wed, May 27, 2020 at 11:33:24PM +0800, Quan Zhou via 44Net wrote:
IANA CA is the root of all RIR CAs, maybe it's easier to work directly with IANA than millions of all equipment vendors.
Unfortunately there is no RPKI IANA Certificate Authority at this time. The IAB *wanted* one, and I think I agree with them that it would've brought many desirable properties to the system if it existed.
Kind regards,
Job
I figured that Certificate Transparency should provide a minor half of solution to the openness, but couldn't find any CT attempts in the RFC series 6480-6495, 8210 and 8360, especially in 6488 there's no SCT list extension in the template. So the hope lies on "an insider" who publishes issuance track and SLURMs config track. Looks like Cloudflare is doing this: https://ct.cloudflare.com/logs/cirrus but without individual log entries.
On A2020/05/25 PM0:06, Bryan Fields via 44Net wrote:
On 5/24/20 11:26 PM, Scott Nicholas via 44Net wrote:
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 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?
You should contact Chris G1FEF on issues like this. His email is chris@g1fef.co.uk
On 4/30/2020 4:41 PM, Jeremy Cooper via 44Net wrote:
Hello all,
In 2018 I requested and received a /24 allocation and permission to announce it via BGP. My ISP/NSP, MonkeyBrains.net, very graciously agreed to route it to my house as part of my normal residential service. (Quite amazing!)
Now, however, they’ve sent me an unusual request (but they are excited about it): can I please setup RPKI for my IP allocation, authorizing them (MonkeyBrains) permission to advertise the block? Full quote below:
Hi Jermy,
We advertise a /24 for AMPRNET. Please setup a ROA record on ARIN authorizing us to advertise that block. (We just learned how to do this for our IPs yesterday and are exctied about RPKI.
If you haven't set up RPKI for your IP allocations, here are the steps in a nutshell:
create SSL key upload to ARIN Create ROA (image below) Thanks,
Rudy
HOW-TO on ARIN: https://www.arin.net/resources/manage/rpki/hosted/#roarequestkeypair https://slack-redir.net/link?url=https%3A%2F%2Fwww.arin.net%2Fresources%2Fmanage%2Frpki%2Fhosted%2F%23roarequestkeypair&v=3
I don’t think this is going to work as I don’t _OWN_ my block. It is licensed to me for a 5 year period. As such, there’s no record of my allocation with ARIN, and hence, nothing that I can assign.
Do any of you network gurus have a sufficiently technically advanced response I can give the ISP for their request?
73, -Jeremy Cooper
On the back of this, I've had a provider no longer use unauthenticated IRR sources. I completely understand this choice however it does open up the question of how we route AMPR if route objects can't be created in a trusted IRRdb if other providers adopt this.
Is there any plans for creating IRR route objects in ARIN in the future?
On Thu, Apr 30, 2020 at 9:45 PM Jeremy Cooper via 44Net < 44net@mailman.ampr.org> wrote:
Hello all,
In 2018 I requested and received a /24 allocation and permission to announce it via BGP. My ISP/NSP, MonkeyBrains.net, very graciously agreed to route it to my house as part of my normal residential service. (Quite amazing!)
Now, however, they’ve sent me an unusual request (but they are excited about it): can I please setup RPKI for my IP allocation, authorizing them (MonkeyBrains) permission to advertise the block? Full quote below:
Hi Jermy,
We advertise a /24 for AMPRNET. Please setup a ROA record on ARIN
authorizing us to advertise that block. (We just learned how to do this for our IPs yesterday and are exctied about RPKI.
If you haven't set up RPKI for your IP allocations, here are the steps
in a nutshell:
create SSL key upload to ARIN Create ROA (image below) Thanks,
Rudy
HOW-TO on ARIN: https://www.arin.net/resources/manage/rpki/hosted/#roarequestkeypair <
https://slack-redir.net/link?url=https%3A%2F%2Fwww.arin.net%2Fresources%2Fma...
I don’t think this is going to work as I don’t _OWN_ my block. It is licensed to me for a 5 year period. As such, there’s no record of my allocation with ARIN, and hence, nothing that I can assign.
Do any of you network gurus have a sufficiently technically advanced response I can give the ISP for their request?
73, -Jeremy Cooper _________________________________________ 44Net mailing list 44Net@mailman.ampr.org https://mailman.ampr.org/mailman/listinfo/44net
Is there any plans for creating IRR route objects in ARIN in the future?
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
Dear all,
On Fri, May 1, 2020, at 11:21, William Waites via 44Net wrote:
Is there any plans for creating IRR route objects in ARIN in the future?
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.
Not true, ARIN has operated a RPSL database for decades https://www.arin.net/resources/manage/irr/
For those interested in RPKI outside 44net - here are some fun videos about RPKI! https://nlnog.net/nlnog-day-2018/
Kind regards,
Job
Job Snijders via 44Net 44net@mailman.ampr.org writes:
Not true, ARIN has operated a RPSL database for decades https://www.arin.net/resources/manage/irr/
Ok, ok. My time operating large networks in the ARIN region was a little while ago (1990s). That bit of my message was out of date. However I stand by the rest of my message.
Best, -w
Hi William,
RADB is the source that I previously referenced as untrusted due to their only barrier being a yearly fee.
Thankfully ARIN are running their own IRR so we should be able to get objects added there. This is based on IRRd 4, example below
route: 23.203.48.0/23 descr: Akamai Technologies origin: AS2914 mnt-by: MNT-AKAMAI source: ARIN changed: ip-admin@akamai.com 20200211
On Fri, May 1, 2020 at 10:21 AM William Waites ww@styx.org wrote:
Is there any plans for creating IRR route objects in ARIN in the future?
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
As far as I can tell, ARIN's IRR is currently completely separate from the rest of ARIN and may be unauthenticated too.
However according to ARIN, they will completely remake their IRR setup and it should go into production quite soon from what I have heard.
- Cynthia
On Fri, May 1, 2020 at 11:35 AM Alistair Mackenzie via 44Net < 44net@mailman.ampr.org> wrote:
Hi William,
RADB is the source that I previously referenced as untrusted due to their only barrier being a yearly fee.
Thankfully ARIN are running their own IRR so we should be able to get objects added there. This is based on IRRd 4, example below
route: 23.203.48.0/23 descr: Akamai Technologies origin: AS2914 mnt-by: MNT-AKAMAI source: ARIN changed: ip-admin@akamai.com 20200211
On Fri, May 1, 2020 at 10:21 AM William Waites ww@styx.org wrote:
Is there any plans for creating IRR route objects in ARIN in the
future?
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
44Net mailing list 44Net@mailman.ampr.org https://mailman.ampr.org/mailman/listinfo/44net
DO NOT participate in RPKI! In my view, it's all about control & goes against what the Internet is supposed to be about.
PARTICIPATION IS NOT REQUIRED. If you want to be a "gnat" under someone's thumb, then go ahead. Unfortunately, that does seem to be the contemporary, uninformed, follow-the-leader mindset of the day...
We should be protecting our Internet!! Just saying...
On Thu, Apr 30, 2020 at 4:44 PM Jeremy Cooper via 44Net < 44net@mailman.ampr.org> wrote:
Hello all,
In 2018 I requested and received a /24 allocation and permission to announce it via BGP. My ISP/NSP, MonkeyBrains.net, very graciously agreed to route it to my house as part of my normal residential service. (Quite amazing!)
Now, however, they’ve sent me an unusual request (but they are excited about it): can I please setup RPKI for my IP allocation, authorizing them (MonkeyBrains) permission to advertise the block? Full quote below:
Hi Jermy,
We advertise a /24 for AMPRNET. Please setup a ROA record on ARIN
authorizing us to advertise that block. (We just learned how to do this for our IPs yesterday and are exctied about RPKI.
If you haven't set up RPKI for your IP allocations, here are the steps
in a nutshell:
create SSL key upload to ARIN Create ROA (image below) Thanks,
Rudy
HOW-TO on ARIN: https://www.arin.net/resources/manage/rpki/hosted/#roarequestkeypair <
https://slack-redir.net/link?url=https%3A%2F%2Fwww.arin.net%2Fresources%2Fma...
I don’t think this is going to work as I don’t _OWN_ my block. It is licensed to me for a 5 year period. As such, there’s no record of my allocation with ARIN, and hence, nothing that I can assign.
Do any of you network gurus have a sufficiently technically advanced response I can give the ISP for their request?
73, -Jeremy Cooper _________________________________________ 44Net mailing list 44Net@mailman.ampr.org https://mailman.ampr.org/mailman/listinfo/44net
Thomas,
You say
On Tue, Jun 2, 2020, at 04:17, Thomas Jones - KG5ZI /8 via 44Net wrote:
DO NOT participate in RPKI!
And ...
We should be protecting our Internet!! Just saying...
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
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 44net@mailman.ampr.org wrote:
Thomas,
You say
On Tue, Jun 2, 2020, at 04:17, Thomas Jones - KG5ZI /8 via 44Net wrote:
DO NOT participate in RPKI!
And ...
We should be protecting our Internet!! Just saying...
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@mailman.ampr.org https://mailman.ampr.org/mailman/listinfo/44net
Mikrotik is adding RPKI support:
What's new in 7.0beta7 (2020-Jun-3 16:31): [...] !) enabled BGP support with multicore peer processing (CLI only); !) enabled RPKI support (CLI only); [...]
On Jun 2, 2020, at 3:34 PM, Jonathan Lassoff via 44Net 44net@mailman.ampr.org wrote:
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 44net@mailman.ampr.org wrote:
Thomas,
You say
On Tue, Jun 2, 2020, at 04:17, Thomas Jones - KG5ZI /8 via 44Net wrote:
DO NOT participate in RPKI!
And ...
We should be protecting our Internet!! Just saying...
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@mailman.ampr.org https://mailman.ampr.org/mailman/listinfo/44net
44Net mailing list 44Net@mailman.ampr.org https://mailman.ampr.org/mailman/listinfo/44net
I've been monitoring this discussion. Since our space was allocated by Jon Postel, initially around 1981 (ish), why can't we create our own trust model (CA signed by a CA signing agency like Thawte or Comodo as examples) and act as an IR for the 44.0/9 and 22.128/10 space ourselves and publish that trust model to the RIRs? They would have to accept it much like ARIN and RIPE trust each other. Then RPKI would work for AMPRNet and AMPRNet would control it's own destiny.
--tom/n2xu 44.98.62.0/29
On 6/2/20 2:34 PM, Jonathan Lassoff via 44Net wrote:
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 44net@mailman.ampr.org wrote:
Thomas,
You say
On Tue, Jun 2, 2020, at 04:17, Thomas Jones - KG5ZI /8 via 44Net wrote:
DO NOT participate in RPKI!
And ...
We should be protecting our Internet!! Just saying...
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@mailman.ampr.org https://mailman.ampr.org/mailman/listinfo/44net
44Net mailing list 44Net@mailman.ampr.org https://mailman.ampr.org/mailman/listinfo/44net
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@mailman.ampr.org wrote:
I've been monitoring this discussion. Since our space was allocated by Jon Postel, initially around 1981 (ish), why can't we create our own trust model (CA signed by a CA signing agency like Thawte or Comodo as examples) and act as an IR for the 44.0/9 and 22.128/10 space ourselves and publish that trust model to the RIRs? They would have to accept it much like ARIN and RIPE trust each other. Then RPKI would work for AMPRNet and AMPRNet would control it's own destiny.
--tom/n2xu 44.98.62.0/29
On 6/2/20 2:34 PM, Jonathan Lassoff via 44Net wrote:
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 44net@mailman.ampr.org wrote:
Thomas,
You say
On Tue, Jun 2, 2020, at 04:17, Thomas Jones - KG5ZI /8 via 44Net wrote:
DO NOT participate in RPKI!
And ...
We should be protecting our Internet!! Just saying...
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@mailman.ampr.org https://mailman.ampr.org/mailman/listinfo/44net
44Net mailing list 44Net@mailman.ampr.org https://mailman.ampr.org/mailman/listinfo/44net
44Net mailing list 44Net@mailman.ampr.org https://mailman.ampr.org/mailman/listinfo/44net
Tom,
As Q already mentioned, Thawte or Comodo (now called Sectigo) are for Web PKI, not RPKI, they have nothing to do with this. And not to mention the huge requirements something like that would have, and enormous fees.
Not entirely sure what you mean by "act as an IR"?
They would have to accept it much like ARIN and RIPE trust each other
In the context of RPKI, ARIN and RIPE NCC do not trust each other, they have their own Root CAs (TALs), which are independent of each other. An RPKI validator has to use both of them.
- Cynthia
On Wed, Jun 10, 2020 at 2:33 PM Q Misell via 44Net 44net@mailman.ampr.org wrote:
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@mailman.ampr.org> wrote:
I've been monitoring this discussion. Since our space was allocated by Jon Postel, initially around 1981 (ish), why can't we create our own trust model (CA signed by a CA signing agency like Thawte or Comodo as examples) and act as an IR for the 44.0/9 and 22.128/10 space ourselves and publish that trust model to the RIRs? They would have to accept it much like ARIN and RIPE trust each other. Then RPKI would work for AMPRNet and AMPRNet would control it's own destiny.
--tom/n2xu 44.98.62.0/29
On 6/2/20 2:34 PM, Jonathan Lassoff via 44Net wrote:
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 44net@mailman.ampr.org wrote:
Thomas,
You say
On Tue, Jun 2, 2020, at 04:17, Thomas Jones - KG5ZI /8 via 44Net
wrote:
DO NOT participate in RPKI!
And ...
We should be protecting our Internet!! Just saying...
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@mailman.ampr.org https://mailman.ampr.org/mailman/listinfo/44net
44Net mailing list 44Net@mailman.ampr.org https://mailman.ampr.org/mailman/listinfo/44net
44Net mailing list 44Net@mailman.ampr.org https://mailman.ampr.org/mailman/listinfo/44net
44Net mailing list 44Net@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:
Tom,
As Q already mentioned, Thawte or Comodo (now called Sectigo) are for Web PKI, not RPKI, they have nothing to do with this. And not to mention the huge requirements something like that would have, and enormous fees.
Not entirely sure what you mean by "act as an IR"?
They would have to accept it much like ARIN and RIPE trust each other
In the context of RPKI, ARIN and RIPE NCC do not trust each other, they have their own Root CAs (TALs), which are independent of each other. An RPKI validator has to use both of them.
- Cynthia
On Wed, Jun 10, 2020 at 2:33 PM Q Misell via 44Net 44net@mailman.ampr.org wrote:
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@mailman.ampr.org> wrote:
I've been monitoring this discussion. Since our space was allocated by Jon Postel, initially around 1981 (ish), why can't we create our own trust model (CA signed by a CA signing agency like Thawte or Comodo as examples) and act as an IR for the 44.0/9 and 22.128/10 space ourselves and publish that trust model to the RIRs? They would have to accept it much like ARIN and RIPE trust each other. Then RPKI would work for AMPRNet and AMPRNet would control it's own destiny.
--tom/n2xu 44.98.62.0/29
On 6/2/20 2:34 PM, Jonathan Lassoff via 44Net wrote:
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 44net@mailman.ampr.org wrote:
Thomas,
You say
On Tue, Jun 2, 2020, at 04:17, Thomas Jones - KG5ZI /8 via 44Net
wrote:
DO NOT participate in RPKI!
And ...
We should be protecting our Internet!! Just saying...
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@mailman.ampr.org https://mailman.ampr.org/mailman/listinfo/44net
44Net mailing list 44Net@mailman.ampr.org https://mailman.ampr.org/mailman/listinfo/44net
44Net mailing list 44Net@mailman.ampr.org https://mailman.ampr.org/mailman/listinfo/44net
44Net mailing list 44Net@mailman.ampr.org https://mailman.ampr.org/mailman/listinfo/44net
44Net mailing list 44Net@mailman.ampr.org https://mailman.ampr.org/mailman/listinfo/44net
Just an example isn't helpful here. A few issues: - Resource PKI and web PKI are completely different and incompatible - RIRs do not trust people, people trust RIRs. - 44net is not a legacy allocation, is is part of an ARIN /8 - 44net could setup their own TAL however then ever RPKI validator would need that imported (something which would be difficult to do)
Thanks, Q Director AS207960 Cyfyngedig https://as207960.net
On Wed, 10 Jun 2020 at 17:23, Tom Cardinal via 44Net 44net@mailman.ampr.org wrote:
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:
Tom,
As Q already mentioned, Thawte or Comodo (now called Sectigo) are for Web PKI, not RPKI, they have nothing to do with this. And not to mention the huge requirements something like that would have, and enormous fees.
Not entirely sure what you mean by "act as an IR"?
They would have to accept it much like ARIN and RIPE trust each other
In the context of RPKI, ARIN and RIPE NCC do not trust each other, they have their own Root CAs (TALs), which are independent of each other. An RPKI validator has to use both of them.
- Cynthia
On Wed, Jun 10, 2020 at 2:33 PM Q Misell via 44Net <
44net@mailman.ampr.org>
wrote:
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@mailman.ampr.org> wrote:
I've been monitoring this discussion. Since our space was allocated by Jon Postel, initially around 1981 (ish), why can't we create our own trust model (CA signed by a CA signing agency like Thawte or Comodo as examples) and act as an IR for the 44.0/9 and 22.128/10 space ourselves and publish that trust model to the RIRs? They would have to accept it much like ARIN and RIPE trust each other. Then RPKI would work for AMPRNet and AMPRNet would control it's own destiny.
--tom/n2xu 44.98.62.0/29
On 6/2/20 2:34 PM, Jonathan Lassoff via 44Net wrote:
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 44net@mailman.ampr.org wrote:
Thomas,
You say
On Tue, Jun 2, 2020, at 04:17, Thomas Jones - KG5ZI /8 via 44Net
wrote:
> DO NOT participate in RPKI! And ...
> We should be protecting our Internet!! Just saying... 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@mailman.ampr.org https://mailman.ampr.org/mailman/listinfo/44net
44Net mailing list 44Net@mailman.ampr.org https://mailman.ampr.org/mailman/listinfo/44net
44Net mailing list 44Net@mailman.ampr.org https://mailman.ampr.org/mailman/listinfo/44net
44Net mailing list 44Net@mailman.ampr.org https://mailman.ampr.org/mailman/listinfo/44net
44Net mailing list 44Net@mailman.ampr.org https://mailman.ampr.org/mailman/listinfo/44net
44Net mailing list 44Net@mailman.ampr.org https://mailman.ampr.org/mailman/listinfo/44net
-
Alistair Mackenzie -
Bryan Fields -
Charles J. Hargrove -
Christopher Munz-Michielin -
Cynthia Revström -
Jeremy Cooper -
Job Snijders -
John Gilmore -
Jonathan Lassoff -
Matt Peterson -
Nate Sales -
Q Misell -
Quan Zhou -
Ron Economos -
Scott Nicholas -
Thomas Jones - KG5ZI /8 -
Tom Cardinal -
Ty Bermea -
William Waites