Mailing List Archive

ROAs Expire
ROAs expire. Creating new ones doesn't seem to be terribly difficult, but why do they expire in the first place?




-----
Mike Hammett
Intelligent Computing Solutions

Midwest Internet Exchange

The Brothers WISP
Re: ROAs Expire [ In reply to ]
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.
Re: ROAs Expire [ In reply to ]
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

Midwest Internet Exchange

The Brothers WISP

----- Original Message -----

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.
Re: ROAs Expire [ In reply to ]
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.)

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.
Re: ROAs Expire [ In reply to ]
On Tue, Jan 3, 2023 at 9:58 AM Mike Hammett <nanog@ics-il.net> wrote:

> ROAs expire. Creating new ones doesn't seem to be terribly difficult, but
> why do they expire in the first place?
>
>
I think this is covered in the overview rpki document (design decisions):
https://datatracker.ietf.org/doc/rfc8374/

maybe particularly section 9.2 is of interest?
Re: ROAs Expire [ In reply to ]
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.
>
>
>
Re: ROAs Expire [ In reply to ]
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.lists@gmail.com> wrote:
>
>
>
> On Tue, Jan 3, 2023 at 10:53 AM John Curran <jcurran@istaff.org <mailto: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 <mailto: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 <mailto:jared@puck.nether.net>>
>>> To: "Mike Hammett" <nanog@ics-il.net <mailto:nanog@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 jared@puck.nether.net <mailto:jared@puck.nether.net>
>>> clue++; | http://puck.nether.net/~jared/ My statements are only mine.
>>
Re: ROAs Expire [ In reply to ]
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.
>>
>>
>>
>
Re: ROAs Expire [ In reply to ]
If you run Krill Delegated CA software you will get auto-renewing ROAs, which can be managed based on the BGP announcements seen with your prefixes. You’ll also get the ability to seamlessly manage multiple organisational entities in a single Krill instance, even spanning several RIR service regions. Lastly, you can delegate resources to other business units or customers, who in turn run their own CA to manage ROAs.

The ARIN Publication Service for Delegated RPKI launched in March 2022 and currently hosts over 2000 validated ROA payloads. I published a step-by-step guide to set this up with Krill:

https://blog.nlnetlabs.nl/running-krill-under-arin/

RIPE NCC and APNIC offer RPKI publication services as well, and there are similar guides for these RIRs:

https://blog.nlnetlabs.nl/running-krill-under-ripe-ncc/
https://blog.nlnetlabs.nl/running-krill-under-apnic/

Cheers,

Alex


> On 3 Jan 2023, at 16:53, 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.)
>
> 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
>>
>> Midwest Internet Exchange
>>
>> The Brothers WISP
>>
>> 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.
>
>