Yeah, but the original post said something along the lines of
"any packets to or from my network to a broadcast address". It's not the
"to" part of that which is a problem, but the "from" - as you know, x.y.z.3
can be a host or a broadcast address (if it's a /30 mask).
In other words, I can't prevent my customers from sending packets to
a broadcast address, esp. on a subnet smaller than /24. You might be
able to block outgoing packets for destination x.y.z.255, but if you've got
a mask >/24 (/23, etc..), couldn't .255 be a valid host address?
Just being picky, I suppose....
eric
Yes, it could be, actually. I tried to use it as WAN pool address once
though and it horrendously confused the RAS, as well as several UNIX boxen
on the network.
Yes, it could be, but let's remember; isn't the smurf attack the one
that _depends_ on a forged _source_ IP address in order to "work"?
Cheers,
-- jra
And, as an aside, the draft-ferguson-ingress-filtering-03.txt draft
has been advanced by the IESG to published as an Informational RFC.
Please go beat people over the head with it, when it is published.
Thank you for your attention,
- paul
We already do source filtering for the majority of our connection customers;
the exceptions are those on full DS1s who have announcement capability
(even if they're not using it).
This *includes*, by the way, our dial customers..... Its not impossible,
but does require a bit of work.
So this means that you filter anyone who writes you small checks but not
people who write you large checks? Funny, we just filter everyone.
we just filter everyone.
cool. btw, how are you filtering sprintlink announcements?
randy
Sorry, I meant we just filter all of our customers. Still working on peer
and transit filters.