Whitehouse Tackels Cybersecurity

Wed Sep 18 20:00:39 UTC 2002

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?