Re: [Idr] [sidr] Levels of BGPsec/RPKI validation, was: Re: wglc for draft-ietf-sidr-bgpsec-protocol-11

["Sriram, Kotikalapudi" <[e-mail]>]

>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