Do Not Complicate Routing Security with Voodoo Economics

Alexander Harrowell a.harrowell at
Tue Sep 6 09:33:12 UTC 2011

On Monday 05 Sep 2011 15:53:38 Owen DeLong wrote:
> This is true in terms of whether you care or not, but, if one just 
looks at whether it changes the content of the FIB or not, changing 
which arbitrary tie breaker you use likely changes the contents of the 
FIB in at least some cases.
> The key point is that if you are to secure a previously unsecured 
database such as the routing table, you will inherently be changing the 
contents of said database, or, your security isn't actually 
accomplishing anything.

This is true and should probably be considered a universal law. If the 
introduction of security precautions to a system does not change the 
system, the security precautions are ineffective. 

This is based on the principle that people and systems are imperfect, so 
it is extremely unlikely that there are no bad actors or wildlife in the 
pre-security state, and further that false-positive results are 
inevitable. It has the corollary that introducing security precautions 
is invariably costly, and therefore that you must consider the security 
gain relative to the inevitable costs before deciding to do so.

This is of course an intellectually difficult problem. With regard to 
BGP, the security gain is not so much determined by how bad the problem 
is now, as by how bad it could potentially be if someone took it into 
their heads to tear up the rules and declare war. The answer is "very, 
very bad indeed" which is why we're having this discussion.

It also reminds me of J.K. Galbraith's notion of the bezzle - at any 
time, there is an inventory of undiscovered embezzlement in the economy. 
Before it is discovered, both the fraudster and his or her victim 
believe themselves to possess the money that has been stolen - there is 
a net increase in psychic wealth, in JKG's words. In times of 
prosperity, the bezzle grows, and in times of recession, it shrinks.

There is a bezzle of indeterminate size in the routing table, but we 
won't find out how big it is until we audit it (i.e. deploy SBGP). Some 
of it will just be randomness - misconfigurations and errors - but some 
of it will be enemy action.

The only thing worse than e-mail people who send e-mail 
to lists complaining about them
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <>

More information about the NANOG mailing list