On Apr 21, 2004, at 12:11 AM, Rob Thomas wrote:

] Actual data: Over the past three plus years an organization with on the ] order of a dozen MD5-ized BGP sessions has has multiple down sessions ] due to, for instance, a peer doing standard (for them) password ] rotation and forgetting to inform the organization.

Yep, that's a problem - a PROCESS problem. The definition of insanity is repeating the same behavior over and over and expecting a different result. ;)

So you think continuing to use MD5 and not see down sessions due to lost passwords would be insane? Also, PROCESSES are part of running a network. As any large network provider, they will tell you the process of keeping the network up costs more than the fiber the network runs on. In fact, operational support and complexity is one of the main reasons large networks give for not peering with other networks.

Saying that we've not seen any RST attacks may be correct, but it's not a predictor of future activity. No one can do more than model what may come next. Prior to February 2001 no one had seen massive DDoS either. Anyone still think DDoS isn't a problem?

Of course not. But I also see a reason to do DDoS attacks. Rob, you are the biggest proponent of the underground economy I have ever seen. Tell me why a miscreant would waste his time - at *least* 30 minutes (lowest report I've seen, and possibly hours or days) - trying to reset a BGP session when with less effort they could take down an entire router? I can come up with reasons, but they are pretty few and far between, especially compared with reasons to take out a whole router. Can you tell me why these miscreants - people who are lazy just like us - would not rather packet the router off the 'Net than do this slow, possibly useless exercise?

We manage well over 150 peering sessions with MD5 passwords in place. This includes bogon peering, route-server peering, and production traffic peering. This has grown over the past three years. The total number of MD5-related outages: zero.

In other words, your mileage may vary. :)

Awesome news. And your milage *will* vary, since you cannot control separate organizations. -- TTFN, patrick

May be, it is reasonable to have a simple MD-5 key - I mean, without a rotation, use e-mail to exchange it instead of the phone, do not generate but use simple password, and so on. If this key is never changed, then risk to lost a session is very low, and I do not see _any_ reason to keep it on rotation plan (hacker must know too much and can damage too little, in this case). Even such keys as '415' or 'monday' will prevent TCP attacks in alll cases - if single attack require 5 - 30 minutes for the one hit, then no any way exists to use dictionary 'guess' for password cracking. Now, we can see a _histeria_ around this problem; but yes, when it will coll down (1 - 2 weeks), it will be a time to make a reasonable improvements. ----- Original Message ----- From: "Patrick W.Gilmore" <patrick@ianai.net> To: <nanog@merit.edu> Cc: "Patrick W.Gilmore" <patrick@ianai.net> Sent: Tuesday, April 20, 2004 8:49 PM Subject: Re: Winstar says there is no TCP/BGP vulnerability

On Apr 20, 2004, at 11:29 PM, Michel Py wrote:

...

Please forgive me if I'm naive and/or ask a stupid question, but is there any reason (besides your platform not supporting it) _not_ to MD5 your BGP sessions? Geez, on my _home_ router all my v4 BGP sessions are MD5ed (v6 not there yet).

There is serious operational overhead in maintaining sync'ed passwords between separate organizations. IOW: Eventually someone will screw up and lose the password. When they do, the session goes down, and probably for far longer than if some miscreant tries to RST it via the "vulnerability".

Actual data: Over the past three plus years an organization with on the order of a dozen MD5-ized BGP sessions has has multiple down sessions due to, for instance, a peer doing standard (for them) password rotation and forgetting to inform the organization. Each time incurred a minimum of several hours downtime, once stretching into several days as the peer could not figure out what was wrong and get the right person with the password to give it to the organization.

Over the past three plus years with over 1000 non-MD5-ized BGP sessions, the same organization experienced exactly *ZERO* seconds of downtime identified as due to RST-style attacks. And certainly no prolonged outages due to it.

Add to that the additional CPU overhead some people have reported, making it easier to packet the router to its knees, and MD5 looks like a cure worse than the disease.

All that said, it is your router, your peers, your decision. I would never dream of telling anyone who wanted MD5 to not do it. I just don't understand people who want to do it. Especially when they could be doing things like filtering at the leaf nodes and forcing their vendors to support the TTL hack.

But that's me.

-- TTFN, patrick

"Christopher L. Morrow" <christopher.morrow@mci.com> writes:

there is the issue of changing the keys during operations without impacting the network, eh? Having to bounce every bgp session in your network can be pretty darned painful... if you change the key(s) of course. If you don't you might as well not have keys, since adding the 3 lines of C code required to Paul Watsons' program making it do the hashing certainly won't be a big deal, eh?

I've added keys without bouncing the sessions... doesn't seem to cause any difficulties at all. You just add the password clause on both ends within the window for a BGP keepalive timeout. Worst case, this line: Milwaukee#sho ip bgp neigh 203.176.61.22 | inc md5 Flags: passive open, nagle, gen tcbs, md5 Milwaukee# is lying, and the md5 won't actually come up until some nogoodnik or bad fortune causes the session to bounce. 12.0S. ---Rob