ROAs Expire

Tue Jan 3 16:14:22 UTC 2023

On Tue, Jan 3, 2023 at 11:07 AM John Curran <jcurran at 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.lists at gmail.com>
> wrote:
>
>
>
> On Tue, Jan 3, 2023 at 10:53 AM John Curran <jcurran at 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 <nanog at 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" <jared at puck.nether.net>
>> *To: *"Mike Hammett" <nanog at ics-il.net>
>> *Cc: *"NANOG" <nanog at 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 jared at puck.nether.net
>> clue++;      | http://puck.nether.net/~jared/  My statements are only
>> mine.
>>
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20230103/a2e33d7a/attachment.html>