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
