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

[Iljitsch van Beijnum <[e-mail]>]

On 03 May 2015, at 4:51, Sriram, Kotikalapudi <[e-mail]> 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.