BGP as Draft vs. RFC 2385

[Steve Bellovin <smb@research.att.com>]

There's a process issue around trying to promote BGP to DS.  To do 
that, we need the security features to interoperate; the best we have 
for BGP security is RFC 2385 (TCP MD5).  The problem is that it's not 
very good.

Apart from other, deeper issues -- the real BGP security issues are the 
domain of rpsec, and are addressed by things like SBGP -- keyed MD5 
isn't good.  To quote Hugo Krawczyk:

  ... So while the
  existence of these almost-attacks should be sufficient reason not to adopt
  "appended-key MD5" in a new standard, I do not think that it is
  catastrophic to keep it in a place where it is widely deployed. 

  The document already warns about the potential vulnerabilities. I would
  actually add a stronger recommendation in the document itself to
  eventually replace the method with a stronger MAC. The right way for doing
  this is not just replace MD5 with SHA1 as indicated in the rfc but upgrade
  the method to support more than a single mechanism (adding an algorithm
  identifier) and specify HMAC as the default (possibly, HMAC-MD5 if
  performanceis an issue).

Put another way, there's no way we can advance 2385 to DS, since it has 
known technical failings.  But where does that leave BGP?

The best answer I can see is a waiver for BGP.  The other choice 
is to wait a very long time, until rpsec produces something that's 
implementable and implemented to solve the deeper BGP security prolbems.


		--Steve Bellovin, http://www.research.att.com/~smb (me)
		http://www.wilyhacker.com (2nd edition of "Firewalls" book)