so we started to wonder if, since we started protecting our bgp sessions with md5 (in the 1990s), are there still folk trying to attack? we were unable to find bgp mib counters. there are igp interface counters, but that was not our immediate interest. we did find that md5 failures are logged. looking at my logs for a few years, i find essentially nothing; two 'attackers,' one my own ibgp peer, and one that noted evildoer rob thomas, bgprs01.ord08.cymru.com. we would be interested in data from others. note that we are neither contemplating nor suggesting removing md5 from [y]our bgp sessions. randy
Just to point out - Data about md5 attacks from various organizations will depend on a number of factors such as - Is BGP TTL Security check being done? Are anti-spoofing ACLs enabled? uRPF enabled? Strict or Loose? BGP Session over a separate interface (tunnel)? With Gratitude, Pratik Lotia | Security Engineer | Advanced Engineering Security Charter Communications "A satisfied customer is the best business strategy of all." -----Original Message----- From: NANOG [mailto:nanog-bounces@nanog.org] On Behalf Of Randy Bush Sent: Tuesday, August 14, 2018 3:39 PM To: North American Network Operators' Group Subject: tcp md5 bgp attacks? so we started to wonder if, since we started protecting our bgp sessions with md5 (in the 1990s), are there still folk trying to attack? we were unable to find bgp mib counters. there are igp interface counters, but that was not our immediate interest. we did find that md5 failures are logged. looking at my logs for a few years, i find essentially nothing; two 'attackers,' one my own ibgp peer, and one that noted evildoer rob thomas, bgprs01.ord08.cymru.com. we would be interested in data from others. note that we are neither contemplating nor suggesting removing md5 from [y]our bgp sessions. randy E-MAIL CONFIDENTIALITY NOTICE: The contents of this e-mail message and any attachments are intended solely for the addressee(s) and may contain confidential and/or legally privileged information. If you are not the intended recipient of this message or if this message has been addressed to you in error, please immediately alert the sender by reply e-mail and then delete this message and any attachments. If you are not the intended recipient, you are notified that any use, dissemination, distribution, copying, or storage of this message or any attachment is strictly prohibited.
Nah, they aren't asking about the other things, and only the order of operations which vary per vendor will matter. If I am reading correctly, they aren't asking about only successful MD5 attacks, but MD5 attacks in general. All the rest of your listed security configurations would be 'extra' router demographics. -Garrett On Wed, Aug 15, 2018, 06:43 Lotia, Pratik M <Pratik.Lotia@charter.com> wrote:
Just to point out - Data about md5 attacks from various organizations will depend on a number of factors such as - Is BGP TTL Security check being done? Are anti-spoofing ACLs enabled? uRPF enabled? Strict or Loose? BGP Session over a separate interface (tunnel)?
With Gratitude,
Pratik Lotia | Security Engineer | Advanced Engineering Security Charter Communications
"A satisfied customer is the best business strategy of all."
-----Original Message----- From: NANOG [mailto:nanog-bounces@nanog.org] On Behalf Of Randy Bush Sent: Tuesday, August 14, 2018 3:39 PM To: North American Network Operators' Group Subject: tcp md5 bgp attacks?
so we started to wonder if, since we started protecting our bgp sessions with md5 (in the 1990s), are there still folk trying to attack?
we were unable to find bgp mib counters. there are igp interface counters, but that was not our immediate interest. we did find that md5 failures are logged.
looking at my logs for a few years, i find essentially nothing; two 'attackers,' one my own ibgp peer, and one that noted evildoer rob thomas, bgprs01.ord08.cymru.com.
we would be interested in data from others.
note that we are neither contemplating nor suggesting removing md5 from [y]our bgp sessions.
randy E-MAIL CONFIDENTIALITY NOTICE: The contents of this e-mail message and any attachments are intended solely for the addressee(s) and may contain confidential and/or legally privileged information. If you are not the intended recipient of this message or if this message has been addressed to you in error, please immediately alert the sender by reply e-mail and then delete this message and any attachments. If you are not the intended recipient, you are notified that any use, dissemination, distribution, copying, or storage of this message or any attachment is strictly prohibited.
On 08/14/2018 03:38 PM, Randy Bush wrote:
so we started to wonder if, since we started protecting our bgp sessions with md5 (in the 1990s), are there still folk trying to attack?
n00b response here I thought using ACLs or otherwise protecting the BGP endpoint was best practice. Thus it's really hard to even try break an MD5 protected BGP session if you can't even establish the TCP connection. Everything that I've seen or set up had an ACL to only allow the peer(s) to be able to connect to (from memory) TCP port 179. Is there something that I've missed the boat on? #learningOpportunity -- Grant. . . . unix || die
Well, think about RST attacks, in which someone bombards a TCP connection with TCP RESET in the hopes of threading a needle and taking it down. It's not the end of the world - BGP restarts - but there is an outage. The simplest way to protect against that (and against having someone with a hijacked IP address connect to your router) is to put mutual authentication on the TCP connection. Having it also at the BGP layer, and having ACLs to be sure you know what's going on, are good things, but TCP MD5, TCP-AO, or IPsec are an awful lot safer.
On Aug 14, 2018, at 4:28 PM, Grant Taylor via NANOG <nanog@nanog.org> wrote:
On 08/14/2018 03:38 PM, Randy Bush wrote:
so we started to wonder if, since we started protecting our bgp sessions with md5 (in the 1990s), are there still folk trying to attack?
n00b response here
I thought using ACLs or otherwise protecting the BGP endpoint was best practice. Thus it's really hard to even try break an MD5 protected BGP session if you can't even establish the TCP connection.
Everything that I've seen or set up had an ACL to only allow the peer(s) to be able to connect to (from memory) TCP port 179.
Is there something that I've missed the boat on?
#learningOpportunity
-- Grant. . . . unix || die
-------------------------------------------------------------------------------- The fact that there is a highway to hell and a stairway to heaven is an interesting comment on projected traffic volume...
On Tue, Aug 14, 2018 at 05:28:13PM -0600, Grant Taylor via NANOG wrote:
On 08/14/2018 03:38 PM, Randy Bush wrote:
so we started to wonder if, since we started protecting our bgp sessions with md5 (in the 1990s), are there still folk trying to attack?
n00b response here
I thought using ACLs or otherwise protecting the BGP endpoint was best practice. Thus it's really hard to even try break an MD5 protected BGP session if you can't even establish the TCP connection.
Everything that I've seen or set up had an ACL to only allow the peer(s) to be able to connect to (from memory) TCP port 179.
Is there something that I've missed the boat on?
#learningOpportunity
To further harden your setup, consider using GTSM https://tools.ietf.org/html/rfc5082 Kind regards, Job
On 8/14/18 2:38 PM, Randy Bush wrote:
so we started to wonder if, since we started protecting our bgp sessions with md5 (in the 1990s), are there still folk trying to attack? To recap for the purpose of my own edification and because hopefully someone will relieve me of my assumptions.
The purpose of of rfc 2385 tcp md5 digests is to keep in-window, tcp segments that are spoofed from being ingested into the tcp stack. At the time of it's writing (1998) some popular network operating systems did not check that the sequence number was in fact inside the window (so that any tcp packet matching the 4 tupple would be ingested whether it was in-window or not. Variously this improvement was supplemented with the checking the TTL (https://tools.ietf.org/html/draft-gill-btsh-02), checking whether the packet is actually in window, by ACLs that would limit the impacts of spoofing from off path attackers (you can't target my multihop infracture sessions from outside my network for example), and by filters that would limit the sort of thing you could inject into bgp (rendering prefix hijacking moot) ). I see broad evidence that MD5 values are extensively shared between sessions and effectively never rekeyed (including cases where I've changed employers and the same asn is using the same values for new peers). given the existance of effective mitigations for the ibgp case, I've need seen a reason to employ it internally or to explore support for rfc 4808 mechnisms since key rolling is effectively an external coordination problem. Due to window checking and the ttl hack, the best vantage point for launching an attack against a single hop ebgp sessions is as an on path attacker (such that you would be able to identify source port and window), layer-2 exchanges which flood unicast traffic (a hub I guess or any public exchange with broken mac learning) would seem particularly vulnerable since there are many on path neighbors. That is no longer a normal topology. :/
we were unable to find bgp mib counters. there are igp interface counters, but that was not our immediate interest. we did find that md5 failures are logged. I can't quite get there either.
md5 failures I see quite a lot of, as peers that formerly have it configured fail either temporarily or over longer timescales. md5 failures for unestablished connections aren't very interesting in this case. I have thousands of establish connections that last a very long time at public exchange points, so the threat of tcp rsts to sessions is clearly not being realized.
looking at my logs for a few years, i find essentially nothing; two 'attackers,' one my own ibgp peer, and one that noted evildoer rob thomas, bgprs01.ord08.cymru.com.
we would be interested in data from others.
note that we are neither contemplating nor suggesting removing md5 from [y]our bgp sessions.
randy
my memory is that seq num guessing and sending rst was the core problem motivating tcp/md5 for bgp, and btsh came some years later. but no big deal. i think that, indeed, md5 keys are shared across many links *within* an op's infrastructure. but, since integrity, and not privacy, is the goal, this does not seem risky. carrying keys to new networks seems a bit risky as does re-use with multiple external parties.
given the existance of effective mitigations for the ibgp case, I've need seen a reason to employ it internally or to explore support for rfc 4808 mechnisms since key rolling is effectively an external coordination problem.
if i need to roll keys on ibgp, i suspect i have a far more serious problem than if it is ebgp, twice as serious at a minimum :) < rathole > i am not much worried about a mesh which floods unicast. can you even buy devices which support that any more? a while back, i had to really dig in the closet to find one at 100mbps so i could shark mid-stream.
I have thousands of establish connections that last a very long time at public exchange points, so the threat of tcp rsts to sessions is clearly not being realized.
my theory is that, as the attacks were mitigated the attackers moved on to other things. after all, the non-nuisance benefit i get by resetting your bgp session with margaret is shifting your traffic past some place i can mitm or to a more expensive, to you, link. the attackers moved on to more lucrative endeavors. randy
On 15 Aug 2018, at 9:27, Randy Bush wrote:
my theory is that, as the attacks were mitigated the attackers moved on to other things.
With regards to BGP, the MD5 thing was promulgated to counter what was a largely theoretical threat. iACLs, and later GTSM and CoPP and LPTS and so forth really obviated the need for it. For IGPs, MD5 was belt-and-suspenders against someone deliberately or accidentally bringing up a new router and manipulating traffic internally. Passiving the IGP on non-core links was the BCP, but often was honored in the breach; pushing an additional feature for 'security' purposes got some folks' attention when the passiving BCP was ignored. We still see DDoS attacks against routers, of course. But the goal there is disruption of availability, not trying to move traffic onto some alternate path which would somehow benefit the attacker. ----------------------------------- Roland Dobbins <rdobbins@arbor.net>
With regards to BGP, the MD5 thing was promulgated to counter what was a largely theoretical threat.
the rst attacks were a very serious problem. attacks were very real and very disruptive. gtsm et alia were a few years later.
We still see DDoS attacks against routers, of course.
i am focused on bgp, not the daily craptastic packet fling. randy
On 8/14/18 7:27 PM, Randy Bush wrote:
< rathole > i am not much worried about a mesh which floods unicast. can you even buy devices which support that any more? a while back, i had to really dig in the closet to find one at 100mbps so i could shark mid-stream.
I'm not actually worried about it because it is rare, and not a feature, that said, unicast flooding is in fact something we detect on exchanges with a fair amount of frequency e.g. 2-3 a week across the exchanges were we are present. That traffic gets discarded on our ingress but you can count dport 179 packets in there that aren't yours. I certainly wouldn't build a business model around gaining insight from that information leakage (and the bulk of the traffic is whatever the neighbor is exchanging, with someone else, from looking at mac's that sort of thing tends to be one sided unless for example it's a whole switch).
I have thousands of establish connections that last a very long time at public exchange points, so the threat of tcp rsts to sessions is clearly not being realized.
* randy@psg.com (Randy Bush) [Wed 15 Aug 2018, 04:27 CEST]:
my memory is that seq num guessing and sending rst was the core problem motivating tcp/md5 for bgp, and btsh came some years later. but no big deal.
And a few looking glasses exposed detailed TCP window information when run against certain hardware vendors' routers, making that very easy. -- Niels.
Out of curiosity, are you asking for a specific research/project that you need some data for? GTSM is not a replacement for the ACL filtering the bgp speakers or the MD5 ( that is widely supported). If GTSM is not supported you can always predefine the TTL it in the session and manipulate the defaults ( 1 for EBGP 64 IBGP) yet this is works on small scale networks. Another practice is to define who starts the session ( as port 179 is not hard to figure). Yet in all case the ACL is your first defense who is allowed for TCP and when the session is established what they can advertise and what you are willing to accept across the session ( NXT hop, n0. of routers, as-path, communities....etc). https://www.noction.com/blog/bgp_security_md5_password_and_gtsm [https://www.noction.com/wp-content/uploads/2015/04/MD5-password.png]<https://www.noction.com/blog/bgp_security_md5_password_and_gtsm> BGP Security – the MD5 password and GTSM | Noction<https://www.noction.com/blog/bgp_security_md5_password_and_gtsm> www.noction.com There are three security mechanisms that can protect against potential security issues with BGP: the BGP TCP MD5 password, IPsec and GTSM... Brgds, LG ________________________________ From: NANOG <nanog-bounces@nanog.org> on behalf of Randy Bush <randy@psg.com> Sent: Tuesday, August 14, 2018 5:38 PM To: North American Network Operators' Group Subject: tcp md5 bgp attacks? so we started to wonder if, since we started protecting our bgp sessions with md5 (in the 1990s), are there still folk trying to attack? we were unable to find bgp mib counters. there are igp interface counters, but that was not our immediate interest. we did find that md5 failures are logged. looking at my logs for a few years, i find essentially nothing; two 'attackers,' one my own ibgp peer, and one that noted evildoer rob thomas, bgprs01.ord08.cymru.com. we would be interested in data from others. note that we are neither contemplating nor suggesting removing md5 from [y]our bgp sessions. randy [https://ipmcdn.avast.com/images/icons/icon-envelope-tick-round-orange-animated-no-repeat-v1.gif]<https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail&utm_term=icon> Virus-free. www.avast.com<https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail&utm_term=link>
participants (10)
-
Fred Baker -
Garrett Skjelstad -
Grant Taylor -
Job Snijders -
joel jaeggli -
lobna gouda -
Lotia, Pratik M -
Niels Bakker -
Randy Bush -
Roland Dobbins