In message <000301c2df98$1f5dcfe0$4413180a@cisco.com>, "Barry Raveendran Greene " writes:
The problem that sBGP is trying to solve is *authorization*, not identification. Briefly -- and please read the papers and the specs before flaming -- every originating AS would have a certificate chain rooted at their local RIR stating that they own a certain address block. If an ISP SWIPs a block to some customer, that ISP (which owns a certificate from the RIR for the parent block) would sign a certificate granting the subblock to the customer. The customer could then announce it via sBGP.
The other part sBGP is that it provides a chain of signatures of the entire ASpath back to the originator.
Now - show me an operational environment on the Internet were this authorizati on chain is _working_ today. RIRs and RADB do not count. As you mention before, those databases and keeping them up to date are a "pulling teeth" exercise.
It doesn't exist -- and we have routing problems, due mostly to carelessness, but...
Now -- there are clearly lots of issues here, including the fact that the the authoritative address ownership data for old allocations is, shall we say, a bit dubious. And the code itself is expensive to run, since it involves a lot of digital signatures and verifications, especially when things are thrashing because of a major backhoe hit.
But -- given things like the AS7007 incident, and given the possibility -- probability? -- that it can happen again, can we afford to not do sBGP?
AS 7007 can be solved with our existing tool set.
As mentioned here and NANOGs in the past, our biggest problem are providers no t using the tools that they have to build incident resistance into today's network.
But not against more sophisticated variants.
My own opinion is that sophisticated routing attacks are the single biggest threat to the Internet.
My opinion is that lazy operational practices are the single biggest threat to the Internet. What's the point of building security and robustness into a syst em when people choose not to turn it on?
"Never attribute to malice what can be explained by incompetence". --Steve Bellovin, http://www.research.att.com/~smb (me) http://www.wilyhacker.com (2nd edition of "Firewalls" book)