RE: Winstar says there is no TCP/BGP vulnerability

Christopher / Patrick,

Christopher L. Morrow wrote:
I wasn't clear and for that I'm sorry. Except in the later
code trains, or until the recent past (1 year or so) changing
the BGP MD5 auth bits required the session to be reset.

Then I'm the one sorry because I never got it to work (I have not tried
hard, I have to say); I always considered the session reset to be
annoyance that was part of life. Dumb question: on what platforms is
this working? If my memory is correct nothing below the 7200; I have
seen numerous cases of peering with platforms such as 3600.

no, removing a route-map or adding a new one is painful,
changing it is just normal, no bounce required.

Maybe I have something to learn here.

- The reason I have a route-map in for a peer's BGP session is that I
want to want to shield myself against a misconfigured peer that
announces the entire world to me.
- There are cases (such as the peer being a tier-2 customer of UUNET and
me being a tier-3 customer of UUNET via a different tier-2) when the
routes seen coming from the peer will have the same length AS-PATH than
the ones coming from my transit, some other BGP tie-breaking criteria
favoring the peer over the transit, leading to disaster.
- I have equally been burned by filtering using a regexp that accepts
only routes that appear to originate from the peer. Looks good on paper
but when the peer configures aggregates of their own that leak in their
BGP, becomes messy. Also been burned with peers configuring
next-hop-self.
- I think I have a reasonably good understanding of route-maps; however
I have not found so far a mechanism that could guarantee that, when
adding/removing seqs from it, there is no transient condition that
causes the peer wrongly announcing the entire world to you to get all
his crud into my own table.
- In theory, I could add a "route-map blah deny 1" that matches
everything, then manipulate the subsequent seqs at will, then remove the
"route-map blah deny 1"; in this situation though, I do not see a clear
advantage over clearing the session.
What am I missing?

wrong program, I was referring to his reset_tcp.c program,

Oh, I see. I thought that you meant that saving the password somewhere
was useless, as any side could recover it by decrypting it from the
config. My mistake.

Remember that once you put the passwd in the config it's exposed
and the next NOC engineer that leaves will have a copy emailed to
his home email account before he stomps out :frowning:

You're preaching the choir on this. That being said, the point was how
MD5 could diffuse a DOS attack based on the vulnerability mentioned
earlier; the correlation between a BGP TCP RST DOS attack (especially
against a big networks such as yours) and a NOC engineer leaving is not
quite 1:1. As a matter of fact, if was a NOC engineer planning a DOS
attack against the company I work for, I would stay in just to have the
inside picture.

Patrick W.Gilmore wrote:
No medium or large network filters their peers on prefix. And
very few small networks do either. Prefix count, maybe, but
not individual prefixes. There are far too many changes on far
too many peers per day to keep up.

Exactly the same argument as using MD5 or not. When you build this as
part of the operation, yes it means time _and_ money but overall not
that much more and the bigger the network the lesser the
cost-per-router.

I do concede that people such as Rob and myself are sometimes living on
another planet, as there we operate a few networks for fun, not for
money. Nevertheless, time for pet projects is limited is as well as
day-time job ones, and if we lobby for something such as edge filtering
or bogon route-servers, it's because it can be worked out. We just have
the luxury to try without having to justify the time wasted on it.

Not to mention far, far, far too many chances to screw up
and get the dreaded phone call in the middle of the night.

Irrelevant:
1) Look at your watch.
2) That's what rookies are for. A NOC rookie screwing up _one_ BGP
session does not mean my phone rings. I'm sure that everyone understands
that, when I was a rookie, I _never_ screwed up a session in the middle
of the night when nobody cares :slight_smile:

Michel.

Christopher / Patrick,

> Christopher L. Morrow wrote:
> I wasn't clear and for that I'm sorry. Except in the later
> code trains, or until the recent past (1 year or so) changing
> the BGP MD5 auth bits required the session to be reset.

Then I'm the one sorry because I never got it to work (I have not tried
hard, I have to say); I always considered the session reset to be
annoyance that was part of life. Dumb question: on what platforms is

its annoying until you drop customer traffic over and over on thousands of
bgp sessions... eh? doing this is not nice.

this working? If my memory is correct nothing below the 7200; I have
seen numerous cases of peering with platforms such as 3600.

if you mean md5 auth, it works from atleast 2501->12008.
if you mean resetting sessions to change keys I believe it's more code
dependent than anythingn else.

> no, removing a route-map or adding a new one is painful,
> changing it is just normal, no bounce required.

Maybe I have something to learn here.

- The reason I have a route-map in for a peer's BGP session is that I
want to want to shield myself against a misconfigured peer that
announces the entire world to me.

caution: there are several ways to do bgp configs, i am comfortable with
the way I do it daily (or how I deal with it daily). Route-maps we use to
massage routes and add/change/delete communities or the like... or for
redist from proto to proto. Not for limiting routes injected, prefix-lists
are better/more efficient for that. For pure: "Don't blow me up with
prefixes" just limit the maximum-prefix to some # over your expected
peer's list.

- There are cases (such as the peer being a tier-2 customer of UUNET and
me being a tier-3 customer of UUNET via a different tier-2) when the
routes seen coming from the peer will have the same length AS-PATH than
the ones coming from my transit, some other BGP tie-breaking criteria
favoring the peer over the transit, leading to disaster.

use a route-map to add/remove metric or localpref? or any other settable
thing on your side? or prepend or ....

- I have equally been burned by filtering using a regexp that accepts
only routes that appear to originate from the peer. Looks good on paper
but when the peer configures aggregates of their own that leak in their
BGP, becomes messy. Also been burned with peers configuring
next-hop-self.

as-path filters are nice for bogon asn's not for limiting peer prefixes :frowning:

- I think I have a reasonably good understanding of route-maps; however
I have not found so far a mechanism that could guarantee that, when
adding/removing seqs from it, there is no transient condition that
causes the peer wrongly announcing the entire world to you to get all
his crud into my own table.

limit the max prefixes in cisco it's someting akin to:

neighbor <neighbor-ip> maximum-prefix 1000

- In theory, I could add a "route-map blah deny 1" that matches
everything, then manipulate the subsequent seqs at will, then remove the
"route-map blah deny 1"; in this situation though, I do not see a clear
advantage over clearing the session.
What am I missing?

you could tftp in your config change, that doesn't cause the problems...
then just wait for next update time.

> wrong program, I was referring to his reset_tcp.c program,

Oh, I see. I thought that you meant that saving the password somewhere
was useless, as any side could recover it by decrypting it from the
config. My mistake.

that too, but the main thing was: "once you write it down you will start a
clock to change time else it's useless"

Michael Py wrote:

Christopher / Patrick,

> Christopher L. Morrow wrote:
> I wasn't clear and for that I'm sorry. Except in the later
> code trains, or until the recent past (1 year or so) changing
> the BGP MD5 auth bits required the session to be reset.

Then I'm the one sorry because I never got it to work (I have not tried
hard, I have to say); I always considered the session reset to be
annoyance that was part of life. Dumb question: on what platforms is
this working? If my memory is correct nothing below the 7200; I have
seen numerous cases of peering with platforms such as 3600.

Have done around 100 of these in the past 24 hours. It's not
related to platform AFAIK - we've successfully done the changes
on a lowly 2651 and 3620 without outages, but a 7200 with older
IOS did have an outage.

As a general guideline 12.0S and 12.1 have the session reset on
password change, but 12.2S, 12.3 and _latest_ 12.2 mainline do
not. Older 12.2 mainline is unclear, I've had one case where
the session did reset (12.2(17a)) and a few where it did not
(12.2(23)), but I don't know for sure if the reset was caused
by not getting the password close enough to the right time in
the case it failed, or by IOS automatically resetting the
session like it did in earlier versions.

If you really want to know, test it in a lab. If setting a
password results in a syslog message about the session being
reset due to password change, then it will reset due to a
password change :slight_smile:

David.