|
North American Network Operators Group Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical Secure BGP (Was: YouTube IP Hijacking)
> Right. Everyone makes mistakes, but not everyone is malicious. And > the RIRs and the big ISPs are *generally* more clueful than > the little guys and the newcomers. Note also that secured > BGP limits the kinds of mistakes people can make. If I have > a certificate from my RIR for 192.0.2.0/24, I can't neither > announce 10.0.0.0/8 nor delegate it to you, no matter how > badly I type. Secured BGP still strikes me as a net win. I suspect that a major part of the problem with implementing Secured BGP is that it is put forth as a solution that you implement in your routers. Network Operators are very careful about the stuff that goes into routers, even to the extent that many of them do not use SSH to manage them. Instead, they run SSH on trusted and secured servers inside their PoPs and configure their routers to only accept telnet sessions from those trusted and secured servers. Is there some way of deploying a solution like Secure BGP without actually requiring that it go into the routers? Perhaps something that allows the routers to still maintain BGP sessions that can withdraw routes, or announce routes which were recently withdrawn, but require a separate encrypted session between two servers, each one in a trust relationship with one of the BGP speaking routers, to handle announcements of new routes? Pushing this task off to a server that does not have packet-forwarding duties also allows for flexible interfaces to network management systems including the possibility of asking for human confirmation before announcing a new route. --Michael Dillon
|