Winstar says there is no TCP/BGP vulnerability

Wed Apr 21 08:21:27 UTC 2004

On 21-apr-04, at 9:56, Michel Py 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?

Until recently, I had always worked with maximum prefixes only, but 
last month I suggested something along the lines of the above to a 
customer. However, after spending an hour trying to come up with a 
prefix filter for just one peer I changed my mind. This just doesn't 
work unless your peers are all tiny, announcing a couple of prefixes or 
so, or you generate the filters from a routing registry. However, the 
latter is very problematic as well. Just installing RAtoolset requires 
a PhD in Unix system administration, and few networks register their 
information correctly.

With max prefixes you can just set the limit at 10k and never look 
back. Obviously this still allows your peer to do lots of very bad 
things, but announcing the full table to you isn't one of them. Or you 
can keep the limit to 150% of what is actually announced but this 
requires more work and incurs occasional session drops because many 
peers don't announce an increase in the number of prefixes in advance.

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

Huh? You don't pay for peering traffic by the megabit, so the idea is 
to always prefer routes from peers.

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

Traditional way: have both prefix and AS path filters. Only update one 
at a time. You should be ok even if one filter lets something through 
during an update.

More advanced way: have route maps that tag routes with communities on 
ingress, allow only routes with the right communities on egress. Any 
problems with either set of route maps hits the implicit deny so the 
route won't be propagated so if something goes wrong, no harm, no foul.

And a nice round of "clear ip bgp * in" and "clear ip bgp * out" 
afterwards never hurts.  :-)  (CPUs can't feel pain, right?)