NANOG, I'm currently writing a paper for submission, as part of a MSc in Data Communications, and would appreciate if anyone could update me as to the implementation of MD5 for TCP authentication in BGP. Following the alerts last year: http://www.cisco.com/warp/public/707/cisco-sa-20040616-bgp.shtml http://www.us-cert.gov/cas/techalerts/TA04-111A.html http://www.cisco.com/en/US/products/products_security_advisory09186a00803be7 d9.shtml http://www.foundrynet.com/solutions/security/TCP_Vulnerability_v1_3.pdf http://www.kb.cert.org/vuls/id/415294 http://isc.sans.org/diary.php?date=2004-04-20 What has been the general effect in the ISP/Enterprise community following the warnings? - Have people applied MD5? - If not what other technologies were implemented (IPSec AH transport mode for BGP sessions/ACL/rate limiting etc)? - Has there been any performance impacts seen since implementation? - Has the support of the BGP environment been increased because of this implementation (What policies regards changing the MD5 keys were implemented)? - 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)? 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 -------------------------------- Please do not supply confidential information or anything that would be commercially sensitive, if you want to contact me off-line or from a private account please do Yours Doug Legge MDC Student Kingston University London /UK
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
On Wed, 30 Mar 2005, John Kristoff wrote: [on bgp/md5 and acl's]
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.
I would be double careful here, just to make sure everybody understands what you're protecting. iBGP sessions? ACLs are trivial if you have your borders secured. eBGP sessions? GTSM is your friend (if supported). Practically, if you know your peer and you also protect your borders, ACLs are rather trivial as well. What you seem to be saying is using ACLs to enumerate the valid endpoints for eBGP sessions. That goes further than the above but indeed is also a pain to set up and maintain. There are other attacks you can make against TCP sessions (protected by MD5 or not) using ICMP, though. (see draft-gont-tcpm-icmp-attacks-03.txt). -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
without wishing to repeat what can be googled for.. putting acls on your edge to protect your ebgp sessions wont work for obvious reasons -- to spoof data and disrupt a session you have to spoof the srcip which of course the acl will allow in Steve On Thu, 31 Mar 2005, Pekka Savola wrote:
On Wed, 30 Mar 2005, John Kristoff wrote: [on bgp/md5 and acl's]
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.
I would be double careful here, just to make sure everybody understands what you're protecting.
iBGP sessions? ACLs are trivial if you have your borders secured.
eBGP sessions? GTSM is your friend (if supported). Practically, if you know your peer and you also protect your borders, ACLs are rather trivial as well.
What you seem to be saying is using ACLs to enumerate the valid endpoints for eBGP sessions. That goes further than the above but indeed is also a pain to set up and maintain.
There are other attacks you can make against TCP sessions (protected by MD5 or not) using ICMP, though. (see draft-gont-tcpm-icmp-attacks-03.txt).
Stephen J. Wilcox wrote:
without wishing to repeat what can be googled for.. putting acls on your edge to protect your ebgp sessions wont work for obvious reasons -- to spoof data and disrupt a session you have to spoof the srcip which of course the acl will allow in
This is why you either have a stateful firewall in your router that pushes a dynamic acl down to the linecard (or equivalent forwarding place where the for_us vs through_us decision is made), and filter it there. That makes guessing the correct 5 tuple a bit harder. Obviously GTSM is the closest we have yet to hardening (note I did not use securing) the session. On average, the stateful filter will cause the attacker to to try 32000 times to find correct 4-tuple. Conversely, attacker resources will need to be on average 32000 times greater to adversely affect a router. The cost of attacking infrastructure has risen, but the cost to defender is minor. Each configured BGP session already has all the state needed above to populate the filter. /vijay
On Thu, 31 Mar 2005, Pekka Savola wrote:
On Wed, 30 Mar 2005, John Kristoff wrote: [on bgp/md5 and acl's]
ACLs are often used, but vary widely depending on organization.
(and equipment in use)
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
provided your gear supports it an acl (this is one reason layered acls would be nice on routers) per peer with: permit /30 eq 179 /30 permit /30 /30 eq 179 deny all-network-gear-ip-space (some folks call it backbone ip space, Paul Quinn at cisco says: "Infrastructure ip space") no more traffic to the peer except BGP from the peer /30. No more ping, no more traceroute of interface... (downsides perhaps?) and the 'customer' can still DoS himself :( (or his compromised machine can DoS him)
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.
some people still use 'cisco' for their password, even on non-cisco platforms :( this md5 discussion isn't the only security problem :(
I would be double careful here, just to make sure everybody understands what you're protecting.
iBGP sessions? ACLs are trivial if you have your borders secured.
ibgp, provided your infrastructure space is seperate from 'customer' space is simpler... but keep in mind the possible downsides (no ping, no traceroute, harder troubleshooting for the customers, perhaps)
eBGP sessions? GTSM is your friend (if supported). Practically, if you know your peer and you also protect your borders, ACLs are rather trivial as well.
borders, for some folks, are wide, varied and complex :( So, for some folks with limited border size/breadth making these things trivial is, of course, easy.
What you seem to be saying is using ACLs to enumerate the valid endpoints for eBGP sessions. That goes further than the above but indeed is also a pain to set up and maintain.
and impossible to implement on some hardware. Note: Some/all of that hardware is going away as time makes it fade into the background... sometimes not fast enough though. -Chris
Christopher L. Morrow wrote:
provided your gear supports it an acl (this is one reason layered acls would be nice on routers) per peer with: permit /30 eq 179 /30 permit /30 /30 eq 179 deny all-network-gear-ip-space (some folks call it backbone ip space, Paul Quinn at cisco says: "Infrastructure ip space")
no more traffic to the peer except BGP from the peer /30. No more ping, no more traceroute of interface... (downsides perhaps?) and the 'customer' can still DoS himself :( (or his compromised machine can DoS him)
or forge the source ip on the neighbors /30 or /31 (why aren't you using /31s anyway) and call it done. /vijay
On Wed, 30 Mar 2005, vijay gill wrote:
Christopher L. Morrow wrote:
provided your gear supports it an acl (this is one reason layered acls would be nice on routers) per peer with: permit /30 eq 179 /30 permit /30 /30 eq 179 deny all-network-gear-ip-space (some folks call it backbone ip space, Paul Quinn at cisco says: "Infrastructure ip space")
no more traffic to the peer except BGP from the peer /30. No more ping, no more traceroute of interface... (downsides perhaps?) and the 'customer' can still DoS himself :( (or his compromised machine can DoS him)
or forge the source ip on the neighbors /30 or /31 (why aren't you using /31s anyway) and call it done.
curse you and your new-fangled /31's! :) Yes, someone inside the customer could dos the customer... if the customer cared, they could acl their side as well though since they aren't doing egress filtering I'm betting they aren't going to do this either ;( -Chris
On Thu, 31 Mar 2005, Stephen J. Wilcox wrote:
without wishing to repeat what can be googled for.. putting acls on your edge to protect your ebgp sessions wont work for obvious reasons -- to spoof data and disrupt a session you have to spoof the srcip which of course the acl will allow in
This is why this helps for eBGP sessions only the peer is also protecting its borders. I.e., if you know the peer's network has spoofing-prevention enabled, nobody is able to spoof the srcip the peer uses. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
On Thu, 31 Mar 2005, Pekka Savola wrote:
On Thu, 31 Mar 2005, Stephen J. Wilcox wrote:
without wishing to repeat what can be googled for.. putting acls on your edge to protect your ebgp sessions wont work for obvious reasons -- to spoof data and disrupt a session you have to spoof the srcip which of course the acl will allow in
This is why this helps for eBGP sessions only the peer is also protecting its borders. I.e., if you know the peer's network has spoofing-prevention enabled, nobody is able to spoof the srcip the peer uses.
trusting a third party to protect your network is imho not best practice, in addition many networks may have considerable customers inside them making attacking from inside trivial Steve
On Thu, 31 Mar 2005, Stephen J. Wilcox wrote:
On Thu, 31 Mar 2005, Stephen J. Wilcox wrote:
without wishing to repeat what can be googled for.. putting acls on your edge to protect your ebgp sessions wont work for obvious reasons -- to spoof data and disrupt a session you have to spoof the srcip which of course the acl will allow in
This is why this helps for eBGP sessions only the peer is also protecting its borders. I.e., if you know the peer's network has spoofing-prevention enabled, nobody is able to spoof the srcip the peer uses.
trusting a third party to protect your network is imho not best practice, in addition many networks may have considerable customers inside them making attacking from inside trivial
That is why GTSM is useful for hardening, in addition to protecting your borders. When I say 'border protection', I also mean the border between an operator and its customers. I.e., strict uRPF -like prevention, so that nobody (neither a peer, upstream or customer) is able to spoof the infrastructure IP addresses. That's what we're doing, and I'd hope more people would as well. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
Dear Fellows, a simple configuration that can help to improve security on BGP tcp sessions is to establish it using ip loopback address on both sides, even in situations with only one link between routers. By doing that the ip address used are hidden from traceroute tools discovery. Also the ip address used can be no routeable outside both routers, which will naturally block ip traffic against the BGP tcp session from any other host. Regards, Eduardo Ascenço Reis.
participants (7)
-
Christopher L. Morrow -
Doug Legge -
Eduardo Ascenco Reis -
John Kristoff -
Pekka Savola -
Stephen J. Wilcox -
vijay gill