On 03 May 2015, at 4:51, Sriram, Kotikalapudi <[email protected]> wrote:
> “path that is partially BGPsec protected” – I wouldn’t call that “partial > deployment”. > That is just partial path signing. The latter is a way to allow for the former. > Partial deployment, on the other hand, connotes that there are islands within > which > BGPsec is deployed, and the rest of Internet is non-BGPsec. Hm, could be islands of BGPsec in a non-BGPsec sea or islands of non-BGPsec in a BGPsec sea. In practice, what will happen very soon is that there will be a BGPsec core with non-BGPsec leaves and branches. > (1) Incremental Deployment: > BGPsec is amenable to incremental deployment, and does provide benefit to > early adopters within BGPsec islands. > For examples, you can have a BGPsec island in Asia in which, say, 30K > prefixes are originated. > And another BGPsec island in Europe in which, say, 50K prefixes are > originated. > All prefix-routes for those 30K (or 50K) prefixes within an island have the > full protection of > BGPsec while they originate from an AS within the island and propagate fully > signed to other > ASes within the same island. Sure. But what if one of those BGPsec-capable ASes has a customer that doesn't run BGPsec? So: 5+ 4+ 3+ 2+ 1- (where + is BGPsec and - is no BGPsec) In this case the entire path will be unprotected, even though four of the five ASes in the path are capable of using BGPsec. I fair argument can be made that if it's only the origin AS that's non-BGPsec, the protection afforded is very nearly as good as in the case where the complete path is BGPsec-protected. And in general it would be better for BGPsec to be more opportunistic and protect whatever it can protect, even if that falls short of full end-to-end protection. Every protected hop takes away an opportunity for malicious parties to do bad things. _______________________________________________ sidr mailing list [email protected] https://www.ietf.org/mailman/listinfo/sidr
