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
(or his compromised machine can DoS him)
Yes, someone inside the customer