Correct, Im talking about really short lifetimes for ROAs (EE
certificates). The RP software would be forced to cryptographically
checks the objects again and again over short intervals.
But long lifetimes for ROAs (EE certificates) mean at least bigger CRLs.
This would be one benefit of short lifetimes.
Kind regards
Demian
Am 14.01.2014 02:32, schrieb Sriram, Kotikalapudi:
Comments below.
Sriram
2.2 System related
2.2.1 Replay attack:A whole old dataset could replace a newer one and
could be still valid.
That's one reason for the manifests. If you manage to come up with a
scenario where replay occurred but was undetected by the manifest, it would
be very interesting.
2.2.2 Short lifetime attack: Recurring ROA sets with short lifetimes
could overload the RP software because of it's cryptographic checks.
I think that might depend on whether the RP software is setup to re-sync with
the repositories on a periodic basis on on events like expiration.
Another interesting question is whether short lifetimes would cause churn in
the routing space.
I think Demian is speculating having short life-times for ROAs.
(May be you propose doing it by having short-lived certs for the prefix?)
I would like add/caution here is that I don't see any benefit or usefulness
for having short life-times for certificates/ROAs in this context.
It would increase churn a lot but provide no real benefit.
I think a better solution would be to revoke cert and issue CRL when such
(rare) need arises.
Two scenarios as I see them are:
(1) When prefix ownership changes:
When a prefix ownership changes, the CA will anyway generate a CRL
for the previous cert before issuing the new cert to the new owner.
The CRL would render the old ROA invalid.
If the certificate authority (e.g., ISP, RIR) is also the RPKI repository
provider;
they must also delete from the repository any existing ROAs signed by
the revoked cert at the time of issuing the CRL.
(2) When prefix ownership does not change but the originating AS changes:
The CA will revoke the previous cert and issue a new one for the same owner.
Again, the old ROAs can be deleted from the RPKI repository if CA has control.
The vulnerability period is only the duration until the CRL and manifests
propagate in RPKI.
I think using the revocation/CRL approach is need based, and such events occur
rarely.
So I feel it is better than the short-lived prefix cert/ROA approach, which
generates undesirable churn.
Sriram
_______________________________________________
sidr mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/sidr
