Re: DoS attacks, NSPs unresponsiveness

[Joe Shaw <jshaw () insync net>]

On Fri, 3 Nov 2000, John Fraizer wrote:

> You can ALWAYS increase security.  You may not be able to do it the way
> you want but, you can always do it in some shape or form.

I wholeheartedly agree.  And you have to balance functionality against
security, but I believe a happy compromise is generally available.

> If they're filtering on the /19 or /20 boundry on legacy space, they're
> VERY misconfigured and breaking a whole bunch of connectivity.

I thought filtering at /19-/20 space was still considered best common
practice by some of the older Tier 1's who were interested in keeping the
routing tables small.  Maybe with less legacy equipment deployed this
isn't an issue anymore.

> OK.  Try this one on.  You're announcing 89K prefixes to customer
> X.  They're seeing the same 89K prefixes from another provider too.  They
> don't want ANY incoming traffic via their connection from you.  They do
> however preference routes to ASX, ASY and ASZ via your connection.  What's
> the best way for them to do this?  Don't announce to you and route-map
> those routes to X Y and Z to be preferred.

Wouldn't it be better, at least from an engineering standpoint, to still
announce their routes with AS padding to increase the AS-path so in the
event their other connection(s) goes down they still have some type of
inbound connectivity?  It seems like your example would work in a best
case scenario, but customer X would drop off of the planet in the event of
a partial outage without some manual reconfiguration.  I did something
similar to what you are suggesting, but we still announced the routes,
with padding, so that in the event of a failure the network could still
function.  The link did fail eventually (would you believe me if I
mentioned there was a backhoe and a contractor involved?), and while the
network was certainly slower than normal, it continued to function
adequately so that there was no perceivable outage seen by our customers.

--
Joseph W. Shaw
Sr. Network Security Specialist for Big Company not to be named because I
don't speak for them here.  I have public opinions, and they don't.