Hi Stephen, Ok, I understand the model you talk about now. Yes the CPU may not be the biggest concern as the server is verifying the Cert's offline. I guess this would also lead to models like CRL's for revocation.
Like I said earlier as SIDR does not stop malicious attacks, but only ones caused unintentionally, is it not possible to actually use a simpler mechanism to get over such errors? Thanks, Vishwas On Thu, Feb 28, 2008 at 3:35 AM, Stephen Kent <[EMAIL PROTECTED]> wrote: > > > At 8:31 PM -0800 2/27/08, Vishwas Manral wrote: > Hi Stephen, > > The point I raise is that there is a cost associated with this, using > certificates has a CPU cost associated with it. > > I may be missing the point but even if you leave aside the cost of an > off line server to do this check but if the checks are done on each > new prefix we can still overload the off line server. If we do things > like rate limiting we can still have an attacks, or cause delays in > the convergence times. > > Thanks, > Vishwas > > > I think you are missing the point. So long as the processing is done as an > offline operation, not as a gating item in routing, it does not strike me as > a DoS concern. The initial use of the infrastructure is analogous to > downloading IRR databases and processing the RPSL assertions, an operation > many ISPs perform today on a daily basis. > > > More to the point, folks have implemented the necessary software and tested > it with about 20K certs and CRLs and 10K ROAs, a reasonable starting point. > I don't have the precise figures in front of me now, but I believe their > results show that the time to do all the processing (on a laptop) is about > 20-30 minutes, and the time is dominated by the retrieval of the data from > online repositories, not by the crypto operations per se. For a once daily, > offline operations, this seems quite reasonable. > > > Steve _______________________________________________ Sidr mailing list [email protected] https://www.ietf.org/mailman/listinfo/sidr
