North American Network Operators Group

Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical

Re: BGP to doom us all

  • From: Iljitsch van Beijnum
  • Date: Sat Mar 01 15:11:11 2003

On Sat, 1 Mar 2003, Avi Freedman wrote:

> Re: S-BGP in particular, I think that the analysis on S-BGP has been...
> limited.  Ironic for a security protocol that I haven't seen any
> real analysis of the effect on router CPUs when *under attack*.  I
> am not saying "oh, the authentication will drive things way too high".
> I'm just saying that we don't know because the simulations have used
> very conservative parameters.

My two cents:

By looking at the packet formats I estimate that the memory requirements
for S-BGP are about 4 times those of regular BGP (mind you - just the
BGP table, RIB and FIB remain the same). This gets us pretty close to
common 32-bit CPU address space limits.

For receiving updates: you are expected to check the validity of each
hop in each AS path in the global routing table using a public key
signature verification. A Pentium-class CPU can do a few thousand of
those per second, so that adds several minutes of pure CPU time to the
initialization of each full feed. This means crypto hardware.

For sending updates: you must include the identity of the receiver in
each update (and then sign the update, unless I remember incorrectly).
That means sending out updates to a large number of peers (such as on a
public internet exchange) becomes a rather expensive operation, even
discounting the crypto.

However, there is an alternative to S-BGP: soBGP (secure origin BGP, see
URL in my sig for links). Unlike S-BGP, soBGP mainly focusses on the
origin of a route. At first sight this would make soBGP less secure than
S-BGP, but it looks like S-BGP can't protect the entire path under all
circumstances anyway. Also, soBGP is a more open protocol, which can
easily be extended with additional security checks. And a big plus for
soBGP is that unlike S-BGP, where the security information is stored in
path attributes (which means you can easily bring down an existing
router by sending it S-BGP info, no filtering on unknown attributes
AFAIK), this information is exchanged using a new type of message.
This makes it possible to offload the security processing to an external
box.

The problem with fully protecting the path (such as S-BGP wants to do)
is that the only way to do this well is to have the source say which
paths are good, but this is simply too much information. Without this,
it becomes possible for someone who legitimately received the route to
propagate it even though the source didn't intend this. Also, giving the
source full control makes dynamic rerouting (like 9/11 emergency
transit) much, much harder. Obviously we all want routes we know are
good, and don't want routes we know are bad. That's wat S-BGP and soBGP
can do. But what if we can't determine if routes are good or bad? If you
reject the routes you break a lot of connecitvity. If you don't, nobody
will bother jumping through all the hoops to make their route
authenticity verifiable. I really don't envy the first operator to
deploy (S-|so)BGP...

-- 
Iljitsch van Beijnum  -  http://www.bgpexpert.com/  (updated: Feb 27, 0:40:21)