Re: ROAs Expire

[Christopher Morrow <morrowc.lists () gmail com>]

On Tue, Jan 3, 2023 at 11:07 AM John Curran <jcurran () 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 () gmail com>
> wrote:
>
>
>
> On Tue, Jan 3, 2023 at 10:53 AM John Curran <jcurran () 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 () 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 () puck nether net>
> > *To: *"Mike Hammett" <nanog () 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 jared () puck nether net
> > clue++;      | http://puck.nether.net/~jared/  My statements are only
> > mine.