Re: soBGP deployment

[Randy Bush <randy () psg com>]

> 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