Re: Secure BGP (Was: YouTube IP Hijacking)
[EMAIL PROTECTED] wrote: [..] 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. There is no (direct) requirement for most of these solutions to do it in the router that forwards actual packets, just add a special BGP box for this. This box then 'verifies' if the update looks OK. When the update looks fishy, it can either, depending on what you want either notify your favourite $nocmonkey to look at it and/or at least instruct the real routers to not use that path. You can take (S-)BGP(-S) for verification, but you can also use IRR data or whatever source you have for stating 'this prefix from there over this path is trusted', compare against that and voila, you got a report when the assumed vectors don't match and you can at least react to them. These kind of systems already exist, see previous emails, but clearly not too many actually make use of them, now that is too bad for your customers who couldn't see their lolcats or worse who couldn't reach their stock house for quickly selling their shares before that company went down the drain completely... Greets, Jeroen signature.asc Description: OpenPGP digital signature
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
Re: Secure BGP (Was: YouTube IP Hijacking)
Is there some way of deploying a solution like Secure BGP without actually requiring that it go into the routers? The IETF SIDR wg (shameless plug as I'm wg co-chair) is working on a way to say with strong assurance who holds what prefixes, and therefore who can authorize the origination of what prefixes. This could be used in creating filter lists, answering customer request (please announce this for me...), checking the RIB out-of-band, etc. Such info is also the foundation of any yet proposed mechanism for doing in-band bgp security (S-BGP, soBGP, psBGP, SPV, etc., etc.), but the sidr work by itself does not need to be done in the router. Maybe some of you could take a look and comment. Look for the drafts at http://www.ietf.org/html.charters/sidr-charter.html --Sandy
