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

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 :-) Michel.