we would like to MD5 too ...
There is an interesting discussion going on regarding the MD5 hype on the NYIIX mailing list, where, I guess, most of you don't have access to. It explains much about current BGP hole, which is about to be announced in a few days.
<quoted from Steve Francis of Expertcity>
Not to pick on anyone specifically here, but why all of a sudden a rush to implement MD5 checksums on peerings?
I'm usually all for all sorts of obscure security implementations, but in this case, I think that MD5 checksums reduces peering availability, not protects it.
You are protecting against one small class of attacks, BGP TCP session data injection or resetting, that I have never heard of being sucessfully executed in the wild. The attacker has to correctly guess both the ephemeral port of the connection, and the TCP sequence number, in order to have any impact. (as well as the peer address.)
Adding MD5 checksums will protect against that attack - but possibly lower the bar for a DoS (which is a much simpler way to take down the peering, anyway.) Now the router also has to check the MD5 on all the attack packets, possibly driving up CPU load at a lower pps rate. (I have not tested this - speculation.)
Also, you are now assuming the administrative burden on exchanging unique keys with every peer, and trusting that they will keep their configs secure; their routers secure. What happens when one peer needs to replace a router engine, and only has the rancid config with the MD5 password stripped out? And MD5 authentication has no provision for overlapping keys, so changing those keys is another burden of synchronization and change control with an external entity. I think such issues will result in more peer outages. Not changing them regularly obviously mitigates any advantage they bring.
To me, a better solution is to implement the TTL hack, so that the router will only accept BGP packets with a TTL of X (usually 1) so only a local peer could possibly attempt to inject a packet into the session. On a shared exchange such as NYIIX, this does not ensure protection, as one of the peering AS's could be Evil, but it sure narrows the range of attackers, imposes no extra admin overhead, and also reduces the DoS exposure.
Of course, the versions of code and platforms that support that is currently limited.
That said, if one of our peers insists upon MD5 authentication, we will do it, but I'd urge you to assess your security stance to see if it is in fact the right tool for the job.
Thanks
(While the opinions above are mine, the exposition above owes much to others on other mailing lists.)
<quoted of Adam Rothschild of lntc>
On 2004-04-16-23:53:07, Steve Francis <#####################> wrote:>
Not to pick on anyone specifically here, but why all of a sudden a rush to implement MD5 checksums on peerings?
Rumours of a multi-vendor vulnerability allowing BGP sessions to be reset by a remote attacker. Apparently the UNIRAS/NISC folk will publish more details on 2004-04-21, with Cisco, Juniper, and friends to follow. The sky isn't falling... yet.
The vendor TACs we contacted were tight-lipped, basically saying "there's a problem, we can't tell you more about it now, but we strongly recommend that you implement MD5 auth on all BGP neighbors ASAP". I'd imagine others are being told more or less the same.
You are protecting against one small class of attacks, BGP TCP session data injection or resetting, that I have never heard of being sucessfully executed in the wild. The attacker has to correctly guess both the ephemeral port of the connection, and the TCP sequence number, in order to have any impact. (as well as the peer address.)
Correct. All of which takes a non-trivial amount of time, and generates a non-trivial amount of packets, to execute. Unless, of course, there's some newly discovered weakness which makes the attacker's work easier, which remains to be seen.
Some food for thought, coming from a Juniper running 6.2R1.5 in its default sysctl variables:
% sysctl -a | grep -i portrange net.inet.ip.portrange.lowfirst: 1023 net.inet.ip.portrange.lowlast: 600 net.inet.ip.portrange.first: 1024 net.inet.ip.portrange.last: 5000 ^^^^
I'm inclined to agree with you.Adding MD5 checksums will protect against that attack - but possibly lower the bar for a DoS (which is a much simpler way to take down the peering, anyway.) Now the router also has to check the MD5 on all the attack packets, possibly driving up CPU load at a lower pps rate. (I have not tested this - speculation.)
Also, you are now assuming the administrative burden on exchanging unique keys with every peer, and trusting that they will keep their configs secure; their routers secure.
Yup.
What happens when one peer needs to replace a router engine, and only has the rancid config with the MD5 password stripped out?
You could maintain two RANCID instances and CVS trees -- one which is very tightly locked down, containing SNMP communities, password hashes, and so on, and another "less secure" one with the info stripped w/ '$filter_pwds', which is accessible via cvsweb and mailed out to ops staff as changes are made.
Better still would be to store this data in an abstract format (CSV file, SQL database, etc), and have an automated mechanism for spitting out and committing the appropriate vendor-specific BGP configs. But we're beginning to get off-topic for [EMAIL PROTECTED]
To me, a better solution is to implement the TTL hack, so that the router will only accept BGP packets with a TTL of X (usually 1) so^^^^^^^^^ s/1/255/, if I'm reading RFC 3682[1] correctly.
[...]only a local peer could possibly attempt to inject a packet into the session. On a shared exchange such as NYIIX, this does not ensure protection, as one of the peering AS's could be Evil, but it sure narrows the range of attackers, imposes no extra admin overhead, and also reduces the DoS exposure.
Agreed in theory. Things are a bit complex in practice. Juniper can't filter based on TTL (unclear whether this is a hardware or software limitation, though I'm told the latter, so there might be hope for future JunOS builds). Nor can Riverstone and others.
Just my $0.02, speaking on behalf of myself only. No NDA's were harmed in the making of this message.
-a
[1] <http://www.faqs.org/rfcs/rfc3682.html>
---------------------------------------------- [EMAIL PROTECTED] Maillist-Archive: http://www.mail-archive.com/swinog%40swinog.ch/
