spare swamp space?

Jeff,

Sorry I thought you were talking about router load.

Yeah, if you discard at the end of your upstream provider's link, then
that link will get saturated if you are smurfed enough. Last time we
had a really bad one, we were looking at 6-10Mb/s which was not enough
to saturate transit DS-3s, but enough to saturate a few bits of internal
network (us international providers have the odd small line here and
there). Obviously the further upstream you put it the better.

One of the problems here is lack of interest from peers and upstreams. If
you catch their interest at sales time rather than at abuse time
(i.e. you configure something similar into their router on setup),
that would be optimal.

Alex Bligh
GX Networks (formerly Xara Networks)

Try using CAR to rate-limit ICMP or UDP to the IRC server to 256k or a
comfortable norm with 8k or 10k of burstability. Your upstreams will die,
but your internal network will be fine as any excess of the limited
protocols will be dropped before they hit the lan interface.

Yeah, if you discard at the end of your upstream provider's link, then
that link will get saturated if you are smurfed enough. Last time we
had a really bad one, we were looking at 6-10Mb/s which was not enough
to saturate transit DS-3s, but enough to saturate a few bits of internal
network (us international providers have the odd small line here and
there). Obviously the further upstream you put it the better.

See that's the beauty of using either the swamp space or, if I have to and
can negotiate it, private space. The echo-replies get dropped right at
their source since there's no route back to me.

One of the problems here is lack of interest from peers and upstreams. If
you catch their interest at sales time rather than at abuse time
(i.e. you configure something similar into their router on setup),
that would be optimal.

This is exactly what I'm doing going forward with new external
connectivity. One of the questions I will have of all future transit
negotiations will be to ask if they are willing to trace spoofed traffic
and to ask if they will commit to a reasonable turnaround time to get
their customer's amplifying networks fixed once reported.

Brandon Ross Network Engineering 404-815-0770 800-719-4664
Director, Network Engineering, MindSpring Ent., Inc. info@mindspring.com
                                                            ICQ: 2269442

Stop Smurf attacks! Configure your router interfaces to block directed
broadcasts. See http://www.quadrunner.com/~chuegen/smurf.cgi for details.