>Well, at least there is an I-D to point them to:
And plugged his draft.
Jon Green replied:
That's helpful, but even as an RFC people still have to be aware that
the problem exists before they do anything about it. A typical person
that I deal with would be a small networking integrator that is selling
Bay routers to school districts. This is not somebody who reads
RFCs, and most of them don't have any idea what issues face the
Internet today. I'm not sure what we can do, but this is one of the
types of people that severely need the education. I guess it probably
falls back on the vendors here to educate their resellers and customers.
Then, I asked:
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
Jon essayed to tell me why he didn't think it was feasible, like so:
I don't think that's a good idea. The vast majority of routers that
I sell to customers are not used in Internet applications, and to add
another configuration step to enable the router to do what routers
traditionally do by default would be very confusing to the end user.
No, I think the answer really is to get some sample anti-spoofing filters
into the router documentation and find a good way to get people to
read it. There are lots of "how to configure your router for the Internet"
types of tutorials out there, and outbound filtering should be part
of every one of them.
Before I ask him why "sending packets with forged source addresses
through routers" is "what routers traditionally do" (:-), I want to
point out to him that here he's propounding getting people to read
directions on how to do it, while, above, he was noting that the
customers he sells to primarily "are not the sort of people who read
RFC's". If they're not interested in the technical details of how to
run the routers, Jon, what makes you think that putting the info in the
_manual_ will help all that much?
Inasmuch as I suggested that the default port not be ingress filtered
-- except to avoid spoofing in packets purportedly sourced on _the
other side_ of the router, I'm wondering what you think wouldn't work
As for the other gentlemans concern (which, damn it, I thought I got
quoted in here, and didn't), in a non-static routing environment, the
ports of a given router which had other routers downstream of them
would indeed need to be handled specially, but interfacing with the
routing protocol would be unnecessary, because _somewhere_ thee's a
boundary router with static ports... and it's _that_ router that would
be doing the ingress filtering, anyway.
Stipulated, turning off non-adaptive IF on a given router port would
require that that network only contain router interfaces, rather than
also containing hosts, but is that _really_ too high a price to pay,