Hi Sriram, just a quick remark regarding "such events occur rarely". I would say that this depends on the scenario behind. If you consider complexity attacks, for example, where a prefix owner malicously changes ROAs, those event can occur often.
Cheers matthias On Tue, 14 Jan 2014, Sriram, Kotikalapudi wrote: > 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 > -- Matthias Waehlisch . Freie Universitaet Berlin, Inst. fuer Informatik, AG CST . Takustr. 9, D-14195 Berlin, Germany .. mailto:[email protected] .. http://www.inf.fu-berlin.de/~waehl :. Also: http://inet.cpt.haw-hamburg.de .. http://www.link-lab.net _______________________________________________ sidr mailing list [email protected] https://www.ietf.org/mailman/listinfo/sidr
