On Wed, 18 Sep 2002, Jared Mauch wrote:
And BGP should be more secure. What is the problem we should be trying to fix here? There is a "Secure BGP" draft: http://www.ir.bbn.com/projects/sbgp/draft-clynn-s-bgp-protocol-00a.txt
I think the problem that people are attempting to address is the fact that most interprovider bgp sessions are unfiltered and this can cause significant problems if someone starts leaking improper routes or decides to do something malicious.
Authentication of routing announcements is seen as better than "just letting it all slosh around".
It does. But the problem is that what you can know to be good is very likely to be a lot less than what is actually good. So if you simply start requiring authentication, you're going to break reachability in some places.
I read solutions (well, avenues for possible solutions) without a good indication of what the problem is. (That goes for both the Secure Cyberspace and S-BGP drafts.)
Well, there are significant problems today with router architecture that prevent s-bgp and other things from being deployed. Namely start looking at those still using 2500/4500/4700 for bgp in their networks (yes people still do this) and then ask it to do some major cryptograhic authentication... The hardware is not designed for this.
The protocols aren't designed for it either. This is a good thing, because every router can run the necessary protocols autonomously. But it also means a huge duplication of effort. It seems pretty ridiculous to me to have each and every router do strong crypto on each and every BGP update. This kind of stuff should run on centralized servers with adequate disk capacity to cache results. The hard part is integrating such a solution into what we have now. I'm thinking of a protocol that enables BGP routers to consult "policy servers" about the updates they receive. When very strict security is required, the router waits for the PS to clear the update before allowing it, but in a less strict setup the router could process updates and remove the routes later if the PS doesn't like them. In this case, loss of the PS doesn't break the network. So we still have autonomy and implementing new security features becomes much easier because only the policy servers have to know about them.
When "W" goes surfing the net at night to shop for things on ebay and can't get there because someone is improperly announcing a /24 to hijack/DoS them,
Announcing a /24 you have no business announcing is a VERY hard thing to do. The overwheling majority of all ISPs has strict filtering on BGP announcements from customers. Now if the same were true for source address filtering for IP packets, it would be possible to adequately filter DoS traffic (unless massively distributed in nature).
these are the things that they will suggest down that there needs to be authentication and centralized routing data created.
Actually this particular BGP weakness isn't that hard to address: you only need to verify the first few AS numbers in the path and the prefix using a routing registry. You don't even need any crypto (in BGP, at least) for that. And if you want to make it really secure you can add a signature attribute at the source. That costs extra memory in routers, but it's doable. My problems are with the assumption in the S-BGP draft that information in BGP must be protected against modification by routers it passes legitimately. I think some reasonable level of trust is necessary. After all, we trust others to prepare our food, stop for a red light when we cross the road and so on. Or maybe we can all promise to password protect our BGP sessions?