>It would have been better if BGPsec would have had provisions for partial >deployment, >so that you can have a path that is partially BGPsec protected even if it >can't be fully be BGPsec-protected. >That way, the filtering issue shrinks in scope as the BGPsec-enabled core >grows >and non-BGPsec branches turn into leaves and finally go away.
“path that is partially BGPsec protected” – I wouldn’t call that “partial deployment”. That is just partial path signing. Partial deployment, on the other hand, connotes that there are islands within which BGPsec is deployed, and the rest of Internet is non-BGPsec. In this sense, partial deployment is synonymous with incremental deployment. Let us discuss incremental deployment and “path that is partially BGPsec protected” separately. (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. When those prefix-routes cross from a BGPsec island into non-BGPsec Internet, then they lose the signatures entirely and lose the protection. Down the road, when ASes from the two islands in this example interconnect using BGPsec peering, then the combined BGPsec island will be much bigger, providing protection for prefix-routes for all 80K prefixes while they originate from an AS within the combined island and propagate fully signed to other ASes within the combined island. So incremental deployment can start within islands, and grow as islands expand and/or interconnect with each other. Some additional thoughts on incremental deployment can be found in Section 6.3 of the BGPSEC design discussion document: https://tools.ietf.org/html/draft-sriram-bgpsec-design-choices-07#page-21 (2) “path that is partially BGPsec protected” or Partial Path Signing If an update with partially signed path is given some sort of preference over an unsigned update that would encourage cut-and-paste attacks. Additional thoughts on why partial path signing is disallowed can be found in Section 6.4 of the BGPSEC design discussion document: https://tools.ietf.org/html/draft-sriram-bgpsec-design-choices-07#page-21 Sriram _______________________________________________ sidr mailing list [email protected] https://www.ietf.org/mailman/listinfo/sidr
