Yet, what is the (SBGP) alternative?
that the assertion of as-path is produced by the very bgp sessions themselves. simple and congruent, relying on no other data, and can vary in real-time.
I don't think we have much success distributing this kind of certificates in similar scenario either.
this is not cert distribution. all secure bgp proposals have the pki issue.
At least we _do_ have some (limited) experience and even success in recording the prefixes in routing databases
rofl. the irr is a notorious disaster and has not improved in time. and i have been a long-term supporter. it just has not worked. and this aside from the whole design issue of keeping the irr in sync with reality, protecting it from attack, ... when someone suggests keeping data in two places, this red flashing light goes off and sirens start.
Note that the original soBGP didn't require any updates when the peering relationships changed; based on a quick look, a later extension has probably changed this.
one of the 29 hacks to sobgp to try to fix this and that (kinda like w's social security program). this one was to address the attested as-path problem, which s-bgp solves so elegantly.
But this is a good point -- I think a fundamental question that needs to be asked is whether a sufficient security could be gained by just the originator and the verifier doing the cryptographic operations, and not requring everyone in the middle also do them (adding signatures etc.).
you have to or a monkey in the middle can divert the traffic. randy