Re: [tcpm] status of TCP-MD5 after TCP-AO publication

[Iljitsch van Beijnum <[e-mail]>]

On 5 aug 2009, at 11:22, <[e-mail]>  
<[e-mail]> wrote:

> New solutions may only become widely deployed if there is some  
> indication that the existing deployment is in some way obsolete/ 
> historic. If you are now saying we can't call the existing solution  
> obsolete/historic until there is wide deployment of the new solution  
> then we are in a Catch 22...

Despite people telling me it has been around for years, I have never  
encountered AO in the wild. And with IPsec as a mechanism to protect  
BGP being a huge failure because the vendors couldn't make it  
configurable (remember, configuring BGP is a full time job in many  
cases!) and 32-bit AS numbers taking a decade to appear on the scene,  
I am worried that making RFC 2385 historic quickly may leave some  
operators with no way to protect BGP sessions.

Don't forget that people can easily run 2 year old code and deployment  
in Quagga is complex due to the fact that the actual authentication  
happens in the kernel, so if a late model Cisco or Juniper has AO but  
no MD5 and an older model or a Quagga box only MD5 but no AO we're in  
worse shape than we are today.

Also remember that what the crypto people think is good operational  
practice has nothing to do with what really happens in practice,  
setting up MD5 once and never changing the password is what happens in  
49% of all cases (with no protection at all in 50%), and considering  
the amount of attacks happening this seems quite sufficient.

Actually the thing that worries me most about MD5 is that it allows  
for CPU exhaustion attacks, especially as implementations seem to  
authenticate first and do TCP sanity checking later and RFC 3682 never  
caught on because it doesn't autonegotiate. Not sure of AO helps  
against those attacks, but IPsec could through the anti-replay counter.