Thank you Chris! (I scribed a quick reply where a lengthier one might have been best - I usually have the opposite problem… ;-)
Best wishes and Happy Holidays! /John > On Jan 3, 2023, at 11:01 AM, Christopher Morrow <morrowc.li...@gmail.com> > wrote: > > > > On Tue, Jan 3, 2023 at 10:53 AM John Curran <jcur...@istaff.org > <mailto:jcur...@istaff.org>> wrote: >> Mike - >> >> A friendlier RPKI system would allow you to delegate/authorize the automatic >> action of refreshing your RPKI ROA’s when they are close to expiration. >> >> ARIN’s current RPKI system does not provide this (we literally cannot under >> the present schema as we never possess the private key that’s necessary for >> our HSM to perform a ROA generation on your behalf) – but other RIRs RPKI >> systems are built differently and have this functionality today in their >> hosted RPKI systems. >> >> After frequent user requests in this area – along with some requests that >> are related regarding user-interface improvements – we will be moving to a >> hosted RPKI environment that supports automatic ROA rollovers later this >> year. (Note - as a result of this change, folks who want strong assurance >> of non-repudiation of ROA generation should consider delegated or hybrid >> RPKI setups.) >> > > To clarify, your last paragraph: > today ARIN has an HSM, for parts of the work, but requires that the user > (me, mike, jared) hold our > private key(s) used to sign objects locally. this means that ARIN never > sees the private key material. > a private key would be required to be visible/accessible to ARIN's > system(s) in order to auto-update > a ROA(s) in such a new system. > > Further, the future system (that will enable auto-update of ROA) will need > access to the private key > material. This means that POSSIBLY ARIN or a bad-actor may be able to use > that private key material > for bad deeds. (note I'm not saying ARIN is a bad actor, nor that they want > to do bad things) > So folks that need/want to be more assured that their private key material > is 'safe' will need to move > off the ARIN Hosted deployment prior to the new system coming alive. > > Maybe that's all super clear to everyone else, but :) sometimes more words > are more better/clear. > >> Thanks (and Happy Holidays!) >> /John >> >> John Curran >> President and CEO >> American Registry for Internet Numbers >> >>> On Jan 3, 2023, at 10:42 AM, Mike Hammett <na...@ics-il.net >>> <mailto:na...@ics-il.net>> wrote: >>> >>> Nothing went south for me, just got an email from ARIN reminding me that >>> they were about to expire. >>> >>> The reasons you stated all make sense. We'll just have to make sure it's >>> easy enough for the less skilled or more busy operators to comply with >>> current best practices, lest they not do it at all to avoid the hassle. >>> >>> >>> >>> ----- >>> Mike Hammett >>> Intelligent Computing Solutions <http://www.ics-il.com/> >>> <https://www.facebook.com/ICSIL> >>> <https://plus.google.com/+IntelligentComputingSolutionsDeKalb> >>> <https://www.linkedin.com/company/intelligent-computing-solutions> >>> <https://twitter.com/ICSIL> >>> Midwest Internet Exchange <http://www.midwest-ix.com/> >>> <https://www.facebook.com/mdwestix> >>> <https://www.linkedin.com/company/midwest-internet-exchange> >>> <https://twitter.com/mdwestix> >>> The Brothers WISP <http://www.thebrotherswisp.com/> >>> <https://www.facebook.com/thebrotherswisp> >>> <https://www.youtube.com/channel/UCXSdfxQv7SpoRQYNyLwntZg> >>> From: "Jared Mauch" <ja...@puck.nether.net <mailto:ja...@puck.nether.net>> >>> To: "Mike Hammett" <na...@ics-il.net <mailto:na...@ics-il.net>> >>> Cc: "NANOG" <nanog@nanog.org <mailto:nanog@nanog.org>> >>> Sent: Tuesday, January 3, 2023 9:39:10 AM >>> Subject: Re: ROAs Expire >>> >>> On Tue, Jan 03, 2023 at 08:56:28AM -0600, Mike Hammett wrote: >>> > ROAs expire. Creating new ones doesn't seem to be terribly difficult, but >>> > why do they expire in the first place? >>> >>> There's several reasons I can see why one would want this: >>> >>> 1) to ensure that proper care is maintained over the IP space, domains, >>> certificiates (ROA is a certificiate), etc expire and require renewal. >>> >>> 2) If there's a new cipher algo flaw or similar, it may become necessary >>> to rotate things. >>> >>> 3) to help avoid some of the problems that exist with unmaintained IRR >>> objects. >>> >>> There's more I'm sure, but this is one of the reasons that I >>> personally have been hesitatant to roll out some tools, eg: DNSSEC >>> (which suffers from a variety of ciphers and for some cases lack of >>> ability to publish to parents - i think this was largely resolved). >>> >>> With this increased security also comes to increased fragility, >>> which I suspect is what you are writing about, something likely broke >>> for you or someone else due to lack of checking the status of the ROA >>> expiration. >>> >>> This has happened in the past with domains, including big name >>> ones, so having something setup (eg: roa watch, similar to x509watch on >>> *nix systems) would be appropriate. >>> >>> I'm sure others can refer to tools or services that can do this, >>> but it's always a good idea to check your objects and watch when they go >>> away or expire. >>> >>> - Jared >>> >>> -- >>> Jared Mauch | pgp key available via finger from ja...@puck.nether.net >>> <mailto:ja...@puck.nether.net> >>> clue++; | http://puck.nether.net/~jared/ My statements are only mine. >>
