Winstar says there is no TCP/BGP vulnerability

Mailman List Mirror (Read Only)
1

Perhaps we are all making too much of this...

It appears that Winstar feels that there is no need for MD5
authentication of peering sessions. One of our customers has just had
the following response from Winstar following a request to implement MD5
on their OC3 connection to Winstar. My first suggestion is to locate
another upstream provider (they have 3 already).

However, perhaps someone from Winstar would care to help us all
understand what the alternative solution is to securing the session via
MD5? I would *love* an alternative to the 5 days of work we've just gone
through.

2

Seems Xspedius aka E.SPire aka ACSI doesn't feel that MD5 is
important on their BGP sessions either.

Based on the ticket we filed last week, Managment does not
feel its warranted to make these changes.

On the other hand, SPRINT was willing and able to take MD5
session info right away. WAY TO GO SPRINT.

3

While somehow I doubt that the likes of E.Spire and Winstar are doing it
because they know it is the correct thing to do, in actual fact they are
right. All the whining about how we all should have deployed MD5 years ago
proves one very important point, it hasn't been deployed widely because it
is a ROYAL PAIN IN THE !@#$%^&*. I haven't actually run the tests myself,
but people who have are telling me that the implementations of TCP-MD5 on
the major vendors do not take steps to check the sequence numbers (in the
case of a rst) or wait for a syn|ack in the syn cookie/cache/whatever
implementation (in the case of a syn) before doing the cpu burning MD5
hash. So congratulations, we all just made our routers trivially easy to
bring down with even a minor SYN/RST flood and an MD5 key included in the
packet, even an invalid one. Knee jerk security reactions don't always
work out in your favor. :slight_smile:

BTW if someone wanted to actually implement this in a way which made
sense, besides taking the opportunity to implement the checks I mentioned
above before doing MD5 processing... I think the best way to go here is a
public key authentication mechanism. Peers could post their public key on
their peering websites or easily exchange the information in clear text
offline, the other side could then install it on their devices when they
turn up the peers, and it would then be used to automatically exchange MD5
keying information. Obviously you don't want this happening every time,
but it would be easy enough to cache this data after an initial key
exchange and authentication check, and only fall back to the public key
exchange following a reboot (if you dont store keys in something other
than ram) or following an MD5 key mismatch for whatever reason.

4

I dunno...to me, this falls on the side of "wait until I see my BGP
sessions reset randomly before I get concerned". So I see where they're
coming from.

As far as I can tell, from the well reasoned responses from Richard and
Patrick, it just won't get exploited quickly enough to cause a route to
get dampened. And since no privileged access is gained, the chances of
somebody actually bothering to write an effective exploit is minimal. As
others have pointed out, you may as well just flood the router and kick it
over that way, and they already have tools for that.

I think MD5 violates the KISS principle for something as important as BGP.
Not that it's difficult to implement on a small scale, just that it
creates an additional knob for other people to break, and something else
for the CPU to chew on (making it easier to take down, likely).

Andy

5

I've left your entire message below so that one can see I've removed
nothing. Winstar has made NONE of the statements you are interpreting from
their response. They have simply stated that they don't support it at this
moment in time. I'll grant you that they could have answered "when" or
"why" or "what else". But they certainly didn't say anything you are
suggesting that they have said.

<joke>Should we ever meet, I'll remember to never turn down a beer.
You might think I'm pro-prohibition or something...</joke>

6

Joe,

Joe Rhett wrote:

I've left your entire message below so that one can see I've removed
nothing. Winstar has made NONE of the statements you are interpreting from
their response. They have simply stated that they don't support it at this
moment in time. I'll grant you that they could have answered "when" or
"why" or "what else". But they certainly didn't say anything you are
suggesting that they have said.

The only network engineer who may NOT have been aware of the building
BGP vulnerability issue over the last week has to be the engineer who is
currently on his annual vacation in Mauritius, and who refuses to take
his Blackberry, Palm, or Satellite phone with him.

And given the frantic activity by every single major backbone to protect
their connections by DEMANDING MD5 authentication, I think it is
disingenuous to suggest that a network like Winstar is merely saying
"They don't support it at this time" because they haven't gotten round
to it. They have to also be saying:

1) We don't believe there is any threat.
2) We don't want to set up MD5 because it is against our religion
3) We don't know *how* to set it up.
4) Our machines can't support setting up MD5.
5) Our network cannot support the outage as we bounce the session.
6) Our customers cannot accept the outage as we bounce the session
7) We're just thinking about it, and our planning process is taking a
long time.
8) We don't care about customer needs, even customers who spend $200k a
year with us.
9) We don't care about customers
and I am sure there are a slew of other possibilities.

But for a network provider to respond to a request from a large customer
who asks that their peering session be authenticated by just responding
"We don't use MD5 for peering currently" shows un unusually ballsy
attitude. There is more to it. Absent a specific, I chose to assume the
first option. I'm happy to hear Winstar's alternative.

I'm also interested in hearing if Winstar provided the same response to
the other big backbones? MCI, Sprint, AT&T, Level3, Verio, etc. It seems
to me that causing resets regularly forces the router to churn, dealing
with inserting routes into FIB, deleting routes from FIB, recalculate
FIB. Wash, rinse, repeat. Miscreants have no interest in a single reset.
And it won't take 200 seconds after the first reset. You probably won't
get out of the first window.

I stand by my first comment - Winstar doesn't believe that this is
enough of a threat to even craft a professional response.

<joke>Should we ever meet, I'll remember to never turn down a beer.
You might think I'm pro-prohibition or something...</joke>

No. If you were standing in the way of a scheduled trainwreck, and I
tossed you a schedule, a map, fed you live video of the approaching
train, and tossed you a lifeline, and you said you didn't believe there
was any danger I'd have to wonder.

7

1) Deploy correct ingress/egress filtering at all of your edges, and

2) Make sure your upstreams/peers do that as well at least for the
p-t-p prefixes you use between you and them.

If you can't assume 2), you need something like GTSM or MD5 for
the BGP sessions between you and your peers/upstreams.

Note that I assume that if customers don't do ingress/egress filtering
for their p-t-p prefixes, they are shooting themselves in the foot,
and are the only people suffering from the resets. Similar techniques
as mentioned in the previous paragraph could be applied as well, of
course.

That is, a thing most people seem to be forgetting that for these TCP
packets to be processed, they must be spoofed to come from a certain
source IP address. If packets spoofed from that address are summarily
discarded at appropriate places before reaching the infrastructure,
you're pretty much safe.

8

Wouldnt anti-spoofing filters largely eliminate the need for all this
panic about MD5?

-Dan

9

Wouldnt anti-spoofing filters largely eliminate the need for all this
panic about MD5?

egress filtering, yes...
but not everyone does this and thats what poses the panic i guess :frowning:

ingress filtering... largely yes, but no? consider the scenario:

someone runs traceroute to you (Joe ISP) doing bgp with your upstream (Blah Transit)
14. aggr10-fe-0-0-0.nyc.blah-transit.net (5.5.10.102)
15. joe-isp-gw.customer.blah-transit.net (5.5.254.130)

assuming the usual setup, spoof the source ip to 5.5.254.129 and start fiddling
with your router, or spoof to 5.5.254.130 and fiddle with your upstream aggr
router.

ingress filtering won't help in this situation. GTSM although... would...

rather a very stupid workaround to think about:

Haven't tested on other vendors, but at least in Cisco, you can half-way hide
your single hop peering address showing up in traceroute by putting the assigned
p2p address as secondary and spoofed/bogus ip as primary. However, users behind
your network such as customers can still guess by looking at your upstream's
aggr router showing up in outbound trace.
i.e.
interface Serial2/0
ip address 7.7.7.1 255.255.255.252
ip address 5.5.254.130 255.255.255.252 secon

Anyhow the idea is that IOS replies icmp with interface's primary ip, not
secondary. so traceroute would show 7.7.7.1 instead of 5.5.254.130.

if i were you... i would only do that on ebgp interfaces, and not on any core/
internal interfaces.....

I still think good way around is use different address other than what shows up
in traceroute to maintain EBGP sessions. Not the best solution, but largely
secure as long as you and your peer don't publicly provide such information.
No need to worry about md5 implications or password management etc. If really
concerned, supplement it with GTSM to make it bit stronger.

For looking glass.. use a different loopback addr to peer up looking glass/
route server to your routers. use different set of non-publicly-known loopback
addrs to maintain ibgp sessions.. Again, not The solution, but better than
nothing compared with implications with md5 deployment.

-J

10

Date: Wed, 21 Apr 2004 02:01:56 -0700 (PDT)
From: Dan Hollis

Wouldnt anti-spoofing filters largely eliminate the need for
all this panic about MD5?

But that doesn't push the short-term cost onto other networks.

Eddy

11

Not sure what you're saying. You don't need to deploy anti-spoofing
filters everywhere. It needs to be done by those parties which are
the ones setting up MD5 passwords. No more than that. (See my thread
"Alternatives to MD5" for more.)

12

Date: Wed, 21 Apr 2004 14:23:38 +0300 (EEST)
From: Pekka Savola

> But that doesn't push the short-term cost onto other networks.

Not sure what you're saying. You don't need to deploy
anti-spoofing filters everywhere. It needs to be done by

I was being sarcastic wrt networks not being good netizens. If
networks egress-filtered spoofed traffic, it would be much more
difficult for someone to send a spoofed SYN or RST.

Eddy

13

If they make proper anty-spoofiing filtering, no need in MD5.

14

anti spoofing filtering won't help you with your ebgp peer if the packet
is spoofed to your peer's address and hits the peering interface. try
adding GTSM with anti-spoofing. makes it far harder..

-J

15

You can add a RPF-flavored filter like:

Make core-facing network interfaces drop or not route the /30 or /24 your peering interface is on. Many NAP fabrics IPs are blackholed at borders like they should be.

Or you could move your peers to 10.x.x.x addresses and NOT route them inside your network, or have them destined to your blackhole community..

Better still. Just have all of your border routers announce the specpfic address blocks you have peers or directly connected interfaces on with your blackhole community. The routers with directly connected interfaces shouldn't mind the exported route and the routers that receive it shouldn't be routing it anyway.

Deepak Jain
AiNET

James wrote:

16

Hi Deepak,

  Yes you are correct, but really... getting all your peers to do
  this new security policy gets into politics. the fact that you don't
  control your peer's security policy is the problem.. The issue here is
  that you have to make sure you protect your peer for traffic origined
  from your network, whether via filter or blackhole, and your peer has
  to do the same for traffic originating from theirs. What if someone
  at either end by mistake mess up the filter? It's a royal pain in the
#@$%%.

  running bgp session over a /30 that's invisible from traceroute and
  obscured from public knowledge is a better idea, although it is security
  by obscurity, it is a better practice, and easier to manage than having
  both sides abide to a filtering / mutual protection policy.

-J

17

Is there any way to move BGP completely out-of-band?

I know multihop may be out of the question but maybe someone should write
up a proposal for PTP links. :slight_smile:

-Dan

18

BGP over PPP? Could be specified, but that'd require replacing the use of TCP. Might be a bit ugly to implement, especially on larger routers with separate control planes.

19

wasn't there a PPP over SMTP spec? that sounds like a plan for this!

20

I swear to ghod I was thinking of the telnet over SMTP spec when I read this, and wondering if we should use that and have the routers telnet to port 179 over SMTP. Then you could PGP sign the messages! Of course, you'd have to update your spam filters.... :slight_smile: