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

  • From: Michel Py
  • Date: Wed Apr 21 03:58:44 2004

Christopher / David,

> Christopher L. Morrow wrote:
> if you mean resetting sessions to change keys I believe
> it's more code dependent than anythingn else.

That was my point: I thought that changing keys without resetting the
session was tied to a specific version of the "S" train that I have
never seen it on anything lower than a 7200. Anyway, given David Luyer's
post, it appears that unless you are willing to accept the risk of an
unplanned session reset, you'd better have a planned outage for it.
 
> David Luyer wrote:
> 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.

Given the context, I assume that you have added MD5 to sessions that did
not have it previously, I am correct?
Then, do you mean by "without outages" that the session was not reset by
the password add/change? If I may ask, how many out of 100 did not
reset?


> Christopher L. Morrow wrote:
> For pure: "Don't blow me up with prefixes" just limit the
> maximum-prefix to some # over your expected peer's list.

Please allow me to try to make my point again: you store the expected
peer maximum-prefix somewhere in your management system. I do understand
the added complexity, but in the big scheme of things would it be _that_
more difficult to store a comma-delimited string or something that
contains the prefixes that could be announced by that peer instead of
the maximum-prefix? Yes, it generates more work to update the database,
but OTOH it provides the LIII engineer with a lot more to troubleshoot
issues. Is it simply not worth the work at your scale?


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

Based on what criteria? Both the peer and the transit announce the same
prefix with the same AS-PATH length. I agree that in many cases,
favoring the route coming from the transit provider would work, but what
guarantees it? What we are trying to define is the idiot-proof setup for
peers; what if the misconfiguration is with the transit?


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

I don't see much of a difference. AFAIK when you tftp a config into the
running-config, it is appended to the existing config same as if you
pasted the commands into conf t. What happens when the next update time
happens in the middle of tftp merging the old route-map with the new
one?

Michel.