Winstar says there is no TCP/BGP vulnerability

Wed Apr 21 06:56:33 UTC 2004

On Tue, 20 Apr 2004, Michel 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

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 :(

> - 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"