One crucial way in which S*BGP differs from other features is that ASes which deploy S*BGP *must* use their ability to validate paths to inform route selection (otherwise, adding security to BGP makes no sense). Therefore, S*BGP is bound to affect how traffic flows on the Internet. Our work is about harnessing this observation to drive S*BGP deployment.
We consider the case that security plays a very small role in the BGP decision process and, in particular, that security considerations come *after* the Local-Pref and AS-PATH length steps in the BGP decision process. We give evidence that even in this case a small set of early adopters is sufficient to transition a large fraction of the Internet to S*BGP.
Origin validation <> path validation.
Rather, that should read, 'Origin/path validation <> origin/path enforcement'.
The idea of origin validation is a simple one. The idea of path validation isn't to determine the 'correctness' or 'desirability' of a particular AS-path, but rather to determine the *validity* (or at least the *feasability*) of a given AS-path.
Origin validation is relatively easy compared to AS-path validation, and origin validation is the most important function of S*BGP. And in a world with universal origin and AS-path validation, how is there some economic advantage to be had by deploying S*BGP?
One crucial way in which S*BGP differs from other features is that
ASes which deploy S*BGP *must* use their ability to validate paths to
inform route selection
not really. you may wish to read the bgpsec docs, in particular
draft-ietf-sidr-bgpsec-ops
randy