Hey Danny, I read the paper. Maybe it's that I'm missing the voice-over for the slides, but I don't really see anything new here. Every new security mechanism creates a new DOS possibility. If you screw up your HTTPS cert or your CA revokes it, your website goes down. This happens because only hard failures can provide real security guarantees. As the presentation notes, soft failure produces vulnerability -- a "depref invalid" policy allows sub-prefix hijacking.
One other thing to note is that manipulation is indistinguishable from legitimate revocation, at a technical level. So the only solution here is at the human layer, for RPKI relying party software to have operator overrides. Randy stated this better than I at a RIPE meeting many moons ago -- with the RPKI, we're automatically handling a common error (hijacks and fat-fingers) at the expense of having to deal manually with an uncommon error (manipulation). --Richard On Wed, Mar 20, 2013 at 8:50 AM, Danny McPherson <[email protected]> wrote: > > Interesting presentation here: > > http://www.cs.bu.edu/~goldbe/**papers/Cooper_RPKI_BFOC.pdf<http://www.cs.bu.edu/~goldbe/papers/Cooper_RPKI_BFOC.pdf> > > "The RPKI (Resource Public Key Infrastructure) is a new infrastructure to > secure Internet routing > It’s been in deployment since ~2011 But, it also creates new risks > (misconfigurations and takedowns) > that could make IP prefixes unreachable" > > Given we've been concerned (and vocal) about this from an operational > perspective since RPKI's proposed "tight coupling" into BGPSEC discussions > many years ago... > > -danny > > ______________________________**_________________ > sidr mailing list > [email protected] > https://www.ietf.org/mailman/**listinfo/sidr<https://www.ietf.org/mailman/listinfo/sidr> >
_______________________________________________ sidr mailing list [email protected] https://www.ietf.org/mailman/listinfo/sidr
