There's a few challenges with the adoption/deployment of RPKI.
Remember, there are two parts here:
-Signing your IP address space (generating ROAs to reference your Origin ASN and Max Prefix Length).
-Implementing Origin Validation in your network (getting an RPKI validator, grabbing ROAs, talking RTR to routers).
There's also another aspect here worth calling out. Which is that RPKI at the moment doesn't address path validation. Basically, stopping routing leaks or addressing as-path spoofing. AS Path Authorization is still in the early days at the IETF, but the idea is people can piggyback off the existing RPKI infrastructure to implement it without making any major changes. Some folks will say because there is no ASPA - that Origin Validation isn't worth the effort, but I disagree with that - any bit helps to stop hijacks.
Going back to ROA generation, there are two ways to sign announcements. You can go to your RIR and use their APIs or website to do it. Some of the RIRs have okay APIs, some are not so great (which is a pain if you are into automation). You can run in delegated RPKI mode and do your own CA, but that is a fair amount of work and only a few people on the planet do it (but props to those people who have open sourced the s/w and making this easier). The other two challenges with ROA generation are that if you screw it up, it's real painful to unwind. Revoking the ROA can take hours to take effect, or publishing a new/corrected ROA can take hours. If you screw up and specify the wrong ASNs (or lets say you migrate ASNs over), or screw up the max prefix length, you can invalidate your address space on the Internet and blackhole yourself. The other issue is with ARIN - specifically the fact that people running RPKI validators have to deliberately accept the ARIN Trust Anchor for legal reasons (ARIN indemnification). There is evidence that some people are installing the validators and not adding ARINs trust anchor, resulting in not accepting any ROAs that went through ARIN - which is a big chunk of the Internet.
As for Origin Validation, there have been some great open source efforts in the last few years to make this easier to adopt (and big thanks to those whove lowered the bar here). That said, it still means building/deploying this in a robust way, enabling RTR on all your routers and writing policy to reject invalids. It's just a bunch of work and for some networks, it takes time to roll that out globally. Then there is the question of which routes do you apply validation on? What if your have customers who screwed up ROAs? Now you have to coordinate and get them to clean up their game before you turn on the switch or poke holes (nasty). Finally, you have to agree that you are going to essentially drop invalid prefixes for destinations on the Internet. That means if someone on the other side of the world screws up a ROA, you're not routing to them. You've got to be prepared to tell a customer why they can't reach their destination on your network, but another network without origin validation can (like a competitor).
that said, there is no reason to not sign your address space today and start rolling origin validation. there are a number of network operators in the right spots (irc, mailing lists) who are there to help you and give you guidance if you need it.
ps - hi tom. i still have your enteract card from years ago and recall meeting you a few times at the third coast cafe.
Remember, there are two parts here: -Signing your IP address space (generating ROAs to reference your Origin ASN and Max Prefix Length). -Implementing Origin Validation in your network (getting an RPKI validator, grabbing ROAs, talking RTR to routers).
There's also another aspect here worth calling out. Which is that RPKI at the moment doesn't address path validation. Basically, stopping routing leaks or addressing as-path spoofing. AS Path Authorization is still in the early days at the IETF, but the idea is people can piggyback off the existing RPKI infrastructure to implement it without making any major changes. Some folks will say because there is no ASPA - that Origin Validation isn't worth the effort, but I disagree with that - any bit helps to stop hijacks.
Going back to ROA generation, there are two ways to sign announcements. You can go to your RIR and use their APIs or website to do it. Some of the RIRs have okay APIs, some are not so great (which is a pain if you are into automation). You can run in delegated RPKI mode and do your own CA, but that is a fair amount of work and only a few people on the planet do it (but props to those people who have open sourced the s/w and making this easier). The other two challenges with ROA generation are that if you screw it up, it's real painful to unwind. Revoking the ROA can take hours to take effect, or publishing a new/corrected ROA can take hours. If you screw up and specify the wrong ASNs (or lets say you migrate ASNs over), or screw up the max prefix length, you can invalidate your address space on the Internet and blackhole yourself. The other issue is with ARIN - specifically the fact that people running RPKI validators have to deliberately accept the ARIN Trust Anchor for legal reasons (ARIN indemnification). There is evidence that some people are installing the validators and not adding ARINs trust anchor, resulting in not accepting any ROAs that went through ARIN - which is a big chunk of the Internet.
As for Origin Validation, there have been some great open source efforts in the last few years to make this easier to adopt (and big thanks to those whove lowered the bar here). That said, it still means building/deploying this in a robust way, enabling RTR on all your routers and writing policy to reject invalids. It's just a bunch of work and for some networks, it takes time to roll that out globally. Then there is the question of which routes do you apply validation on? What if your have customers who screwed up ROAs? Now you have to coordinate and get them to clean up their game before you turn on the switch or poke holes (nasty). Finally, you have to agree that you are going to essentially drop invalid prefixes for destinations on the Internet. That means if someone on the other side of the world screws up a ROA, you're not routing to them. You've got to be prepared to tell a customer why they can't reach their destination on your network, but another network without origin validation can (like a competitor).
that said, there is no reason to not sign your address space today and start rolling origin validation. there are a number of network operators in the right spots (irc, mailing lists) who are there to help you and give you guidance if you need it.
ps - hi tom. i still have your enteract card from years ago and recall meeting you a few times at the third coast cafe.