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. 
This won't work on anything with multiple diverse paths. And I don't know
many companies with their own WANs that don't have such.
So, yes, the idea is nice but the logic would have to be much more
comprehensive than that. And I honestly don't know how you could safely do
it, that won't break half the routing topologies out there.
(if you assume multipath OSPF for the IGP... maybe. But that's one hell of
an assumption.)
> 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.
This won't work on anything with multiple diverse paths. And I don't know
many companies with their own WANs that don't have such.
So, yes, the idea is nice but the logic would have to be much more
comprehensive than that. And I honestly don't know how you could safely do
it, that won't break half the routing topologies out there.
(if you assume multipath OSPF for the IGP... maybe. But that's one hell of
an assumption.)
--
Joe Rhett Systems Engineer
JRhett@ISite.Net ISite Services
PGP keys and contact information: http://www.navigist.com/Staff/JRhett
True, but there are a lot of small ISPs whom something like this
could help. Granted, perhaps you should know enough of filters and routes
to run an ISP, but there are those who don't, and their numbers will only
increase as the involved equipment and technologies become more accessible
to more people, and more PC shops and small businesses decide to become
their own ISPs.
Josh Beck jbeck@connectnet.com
> > 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.
>
> This won't work on anything with multiple diverse paths. And I don't know
> many companies with their own WANs that don't have such.
Are those companies connecting their LANs to the net through _dialup_
ports on Ascend Boxen?
Come _on_ folks; pay attention.
> So, yes, the idea is nice but the logic would have to be much more
> comprehensive than that. And I honestly don't know how you could safely do
> it, that won't break half the routing topologies out there.
True, but there are a lot of small ISPs whom something like this
could help. Granted, perhaps you should know enough of filters and routes
to run an ISP, but there are those who don't, and their numbers will only
increase as the involved equipment and technologies become more accessible
to more people, and more PC shops and small businesses decide to become
their own ISPs.
I'd venture to speculate that the _vast_ majority of ports on routing
devices in the work have networks connected to them which contain only
hosts -- no other routers.
Remember, that description includes dialup PPP ports.
I think if Ascend, Livingston, and USR -- just those 3 -- put filters
on their dialup ports to prevent source address spoofing, the problem
would probably drop in half.
Adding it to the boundary routers on college campuses would cut another 40%
The remaining 10% comes from AGIS.
Cheers,
-- jra
"Jay R. Ashworth" <jra@scfn.thpl.lib.fl.us> writes:
I think if Ascend, Livingston, and USR -- just those 3 -- put filters
on their dialup ports to prevent source address spoofing, the problem
would probably drop in half.
Don't hold your breath if you're expecting the vendors to implement
it. I hope they do, but I'm certainly not waiting for it. Features
tend to appear in order of financial impact, and I can't imagine the
large customers of Ascend, Livingston, and USR walking away from their
current access platforms if their vendors don't implement automatic
source address filters. I say that as a fairly large USR/3com
customer, but two or three ports shy of IBM and Compuserve.
I've just finished some RADIUS server patches which implement per-user
anti-spoofing filter creation on USR Total Control NETservers (and
probably USR/3com HiPer ARCs, but I haven't tested with ours yet). I
hope to have them working for Ascend Maxen within the next couple of
weeks. Livingston doesn't seem to have the RADIUS support for
specifying dynamic per-user filters (not just filter-ids), though I
haven't investigated their ChoiceNet product thoroughly enough to know
for sure. It certainly seems that it would need dynamic filter
creation.
Unfortunately, our RADIUS server has mutated to such an extent that
our changes won't apply to any of the source-available RADIUS servers.
We don't even use attribute/value users files anymore. All our user
information is stored in a more abstract intermediate format. I want
to port the filter code to the most popular versions (Livingston 1.16,
Merit, Ascend), but I don't have much free time. If anybody's
interested in using these filters, or especially if you're interested
in helping to port them to other servers, please let me know.
I plan to deploy anti-spoofing filters throughout our access network
before the end of September. Is anybody else running or planning to
implement similar filters?
regards,
-- Robert