Let me clarify what I said (and include context that I should have put in my earlier note).
Security mechanisms are not designed in a vacuum. One has to consider the users, the threats, and the usage scenarios. To take an absurd example, while I can do Caesar ciphers in my head I'm quite incapable of mental exponentiations of 2048-bit numbers; accordingly, I'm forced to trust a computer to do those for me. On the other hand, if I'm trying to protect a secret from a first grader who has just learned how to read, a Caesar cipher may be all I need. The same principles apply here. Given the desire to bootstrap secure routing, we concluded that most ISPs would rely on local -- very local -- caches. In fact, I suspect that many, especially large ones, would want a cache per POP. You're quite correct that this implies no validation of IGP routes. That's by intent -- the very first sentence of the abstract states that RPKI is intended to validate BGP routes. (If you have outsiders sending your internal routes into your IGP via BGP, you have bigger problems that RPKI can fix...) Given this, and given the reality of available platforms, we had to make a decision. The usage model suggests that the risk is low; the capabilities of the platforms suggest that we couldn't actually get the security we wanted, just like I can't do mental RSA (at least until I get that brain chip implanted....). On Dec 23, 2011, at 5:44 36AM, Robert Raszuk wrote: > Steven, > > If the cache is within your domain the below sentence does not apply as you > are not validating your IGP routes to bootstrap a router's reachability to a > cache. > > If the cache would be outside of your domain this sentence would apply as you > would require to accept and install some set of essentially "NOT FOUND" > routes to reach the cache. > > Therefor if authors of draft-ietf-sidr-rpki-rtr-XX are really serious about > recommending to keep the cache locally within each domian the below sentence > you are quoting should be fixed or removed. > > Rgs, > R. > >> Let me call attention to this sentence, too: >> >>> It also SHOULD be >>> topologically close so that a minimum of validated routing data >>> are needed to bootstrap a router's access to a cache. >> >> >> That is, there are other, quite important, reasons to keep the cache >> very close to the router(s) it serves. >> >> --Steve Bellovin, https://www.cs.columbia.edu/~smb >> > --Steve Bellovin, https://www.cs.columbia.edu/~smb _______________________________________________ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
