North American Network Operators Group|
Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical
RE: Winstar says there is no TCP/BGP vulnerability
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"