On Tue, Jan 3, 2023 at 11:07 AM John Curran <jcur...@istaff.org> wrote:
> Thank you Chris! > > (I scribed a quick reply where a lengthier one might have been best - I > usually have the opposite problem… ;-) > > hehe :) thanks for the update on the ARIN systems! > Best wishes and Happy Holidays! > you as well! > /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> 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> 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> >> *To: *"Mike Hammett" <na...@ics-il.net> >> *Cc: *"NANOG" <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 >> clue++; | http://puck.nether.net/~jared/ My statements are only >> mine. >> >> >> >