On Wed, 30 Mar 2005 16:50:38 +0100 Doug Legge <Doug.Legge@BerkeleyGroup.co.uk> wrote:
What has been the general effect in the ISP/Enterprise community following the warnings? - Have people applied MD5?
Without question more BGP sessions suddenly became 'MD5-enabled' across the net. It has been debated whether this was a necessary or even if it was a good thing. You should find some references, including some on this list where BGP peer sessions were being reconfigured with MD5 applied during the last TCP sequence number scare.
- If not what other technologies were implemented (IPSec AH transport mode for BGP sessions/ACL/rate limiting etc)?
I don't know of any widespread use of IPsec for BGP sessions even after that last round of alerts, but I am sure some exists. I would be interested in hearing from those that have implemented it in production. ACLs are often used, but vary widely depending on organization. It can be difficult to manage ACLs on a box with a large number of peers that uses many local BGP peering addresses. I'm sure some organizations reviewed and updated their ACLs as a result of the last scare, but that is a local, private decision and it would probably be hard to get good sample of who and what changed.
- Has there been any performance impacts seen since implementation?
Not real world cases that I've heard, but I believe a number of sites prefer not implement MD5 in part because of the potential performance/DoS issues with it enabled.
- Has the support of the BGP environment been increased because of this implementation (What policies regards changing the MD5 keys were implemented)?
Not in my case. We use a simple algorithm to come up with the shared secret, then document it in our peering contact database, which is in a secure, internal location that we can reference if we ever need it. In our case it is just relatively simple additional step when configuring or reconfiguring a BGP session. Although I have seen some compatibility issues between platforms. For example, relatively long length passphrases were not properly supported. In my experience, I haven't seen much practice of changing MD5 keys on BGP sessions except when an organization makes major changes or hasn't kept a record of the shared secret during changes. That is probably the most common time it will get changed. I suppose some organizations may change it when employees who knew it leave the organization, but I've not seen much evidence of that.
- Was this seen as a valid fix or a knee-jerk reaction (Having re-read the exchanges on NANOG regards the actual mathematical probability of generating this attack, what did the ISP community actually do (compared to what the academic/vendor community were suggesting)?
I think that has probably been discussed enough already and will probably be again now so I'll leave it to others to re-hash that. Do note that at least a two specific and related solutions have appeared in the last few years. One is the Generalized TTL Security Mechanism (GTSM) as defined in RFC 3682. It was originally written with BGP in mind, but is also useful for things like MSDP peering. See the RFC for details and why this might be used on BGP sessions. Another is smooth transition between shared secret changes or when applying authentication where none existed. I don't have references handy, but I seem to recall this was still vendor-specific and not fully implemented. Perhaps others will step in with updated info. MD5 can mitigate a risk, but it can come with some operational costs. Some operators prefer one side of the risk equation over the other. Some place a higher weight on one side of the equation than the other depending on the organization and the network. In my experience most will do MD5 if asked and only a small number would actually refuse.
Whilst I've had some response from bgp-info and bgp-security, it's not really been sufficient to draw any real conclusions. From your knowledge and experience are you aware, either internally or with customers the take up of MD5 implementations and had anyone actually suffered an attack prior to implementation
Not that I'm aware of, but I've almost always used it and other knobs when I could so maybe I just didn't notice? John