Re: Yahoo! Lessons Learned

[Daniel Senie <dts () senie com>]

Andrew Brown wrote:
> > The DoS prevention functions (not letting directed bcast in, and not letting
> > forged addresses out) should be done at provider's side.
>
> nope, won't work.  well...it might, but you also might find very irate
> customers jumping up and down screaming about the filtering.  the
> provider simply cannot know what is and what is not a broadcast
> address, simply because the customer gets to set up their own
> networks.
>
> i, for one, am using what is "technically" a broadcast address as a
> unicast address (think point to point).  others may be doing the same.
> just because an address is an one end or another of a cidr block (or c
> or b block), doesn't mean that it's broadcast.

You're correct. Directed broadcast can only be properly identified in
the equipment on the specific subnet. In other words, EVERYONE has to
fix this, from end users to ISPs.

To Vadim's main point, though, where to place protections: the answer I
normally give to clients (whether ISPs or end users) is do it
everywhere. There's no reason NOT to filter the egress from a corporate
network, and then at the provider side filter the ingress from that same
corporate network. There is plenty of router gear which can handle the
needed filtering.

Dialup pools should also be protected. No sense in permitting problems
to originate on a dialup modem or ISDN line. I know the Lucent/Ascend
MAX product accepts an attribute Ascend-Source-IP-Check, which can be
applied as a part of the RADIUS authentication. Have the large dialup
wholesalers implemented this? 

There'll be no magic cure for this issue. It will take a lot of measures
from everyone.

-- 
-----------------------------------------------------------------
Daniel Senie                                        dts () senie com
Amaranth Networks Inc.            http://www.amaranthnetworks.com