Every time I show a customer of mine how to configure a router, I
try to educate them on this. We need some kind of massive marketing
effort to get this out to people though. People would do it, but nobody
knows about it.
Maybe we should get CyberPromo to spam all the technical contacts
in Internic's database to tell them how to do filtering. 
-Jon
Well, at least there is an I-D to point them to:
ftp://ds.internic.net/internet-drafts/draft-ferguson-ingress-filtering-02.txt
Daniel Senie and I will be submitting at least on further draft before
we ask that this be published as an Informational RFC. Until then, you
can simply point people to the draft and say, 'Here.'
- paul
Ok, here's a question:
A router knows the network number and mask of each network to which it
has an interface. Does it not make sense that the default thing for
that router to do would be to trash incoming packets which carry a
source address not on the network associated with that interface.
Certainly, you'd have to tell the router to accept all comers (except
locallly addressed packets) on the WAN interface, but you need to tell
it which interface is the default route _anyway_, so that's trivial.
And for people with multiple, routed networks behind a router, well,
they could probably be assumed to be bright enough to enable additional
net/masks for a given interface _anyway_, so that's not really a
problem either.
Someone tell me, from either a technical or marketing standpoint, why
this idea is infeasible, no?
Cheers,
-- jra
Make them read the 'ingress/egress filtering' by Paul Fergusson et. al.
Apologies to
Paul if I spelled his name incorrectly.
Jon Green wrote:
A router knows the network number and mask of each network to which it
has an interface. Does it not make sense that the default thing for
that router to do would be to trash incoming packets which carry a
source address not on the network associated with that interface.
Given the predominance of Ascend in the marketplace, and their general
configuration style, it would be cool to see an option
"AllowIpSpoofing=Yes/No" or the like. The boxes already carry routes
associated with each interface. If a packet arrives that doesn't have a
route to get it back to the interface it came from, it would be dropped.
Sure, this may not always be what you want, but in 99% of the cases it
would be. Implementation via Radius would permit this to be removed from
people you wish to allow to spoof.
Josh Beck jbeck@connectnet.com
Make them read the 'ingress/egress filtering' by Paul Fergusson et. al.
Apologies to
Paul if I spelled his name incorrectly.
Short of fixing every network on the internet, does anyone have any useful
advice for what to do when smurfed? This happened to an FDT customer last
night, and it had our T1 (according to uunet) at about 500% capacity.
Obviously, until the attack stopped, our T1 wasn't too useful. I'm about
< close to just asking uunet to block all icmp echo replies from coming
into FDT...but I know customers will complain.
Short of fixing every network on the internet, does anyone have any useful
advice for what to do when smurfed? This happened to an FDT customer last
night, and it had our T1 (according to uunet) at about 500% capacity.
Obviously, until the attack stopped, our T1 wasn't too useful. I'm about
>< close to just asking uunet to block all icmp echo replies from coming
into FDT...but I know customers will complain.
Then they will start blasting UDP at you. Trust me, T1 is not that bad. We
periodically have DS-3s eaten up completely but it happens for such a
short time that it cannot really be traced 
Alex
uunet won't (can't) block those echo replies. It will KILL
their routers.
  BUT that will all change when the fast-drop code goes mainstream..
uunet and other networks are going to have to help their customers out,
by loading this code and doing some filtering for their customers.
  Will you do so? Big networks for North America?
Perhaps. The trouble is, when we get smurfed, our T1 becomes totally
useless. While talking to UUNet and Cisco about the problem, Cisco
suggested traffic shaping on the UUNet 7500 we connect to. If they did
that, and told the 7500 not to send >1.5mb/s for us to the cascade, then
would the 7500 be smart enough to prioritize the packets such that the
icmp get dropped and tcp and udp go through? The main problem, AFAICT, is
that the cascade deals very badly with the situation where it has 7mb/s of
traffic for a 1.5mb/s pipe. UUNet did not seem terribly receptive to the
idea.
Maybe it should be a pre-defined filter that the manufactures include in
the basic software configuration. If we put some pressure on
Cisco/Bay/Ascend/Livingston etc....... maybe we can get it done there, so
that we don't have to educate new people.
Alex P
Didn't I just say something like this?
Cheers,
-- jra