dsl providers that will route /24

Thu Mar 29 00:34:26 UTC 2001

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

David -

I will start off by saying this was the most intelligent reply I have read
from you.  Thank you.

Now...

> 	I'll go one further -- if you're not going to investigate
> suspicious traffic (because it's too expensive or you're too lazy or
> whatever), it's probably better that you filter than not. At least
> that way you might minimize the damage done to others, and that's
> certainly a good thing.

Yes, I agree with that.  From what I have seen, this is the problem.  Many
ISPs/Corporations/Whoever that do not do egress blocking, also do not do
any type of log analysis or even logging of suspicious traffic to be
analyzed.

I am willing to back down on my militant stance and say that if you are
willing to take the time and energy to log, analyze, and track down
questionable traffic, then you could be exempt from egress blocking.

> 	I don't have a problem with filtering traffic that can't
> possibly be legitimate. If you're one of those people who agrees that
> packets with RFC1918 source IPs have no place on the Internet, then
> filter that. You can even advocate that others filter it, because it
> has no possibility of blocking legitimate traffic.

I'm glad you agree with that.  There are many others who do not.  I agree
that core routers have no business filtering/blocking.  That function
belongs on the edge.  But, I do believe edge routers should have ingress
and egress filtering to help minimize security threats.  (Unless you are
willing to track it down as above).

> 	What I also oppose is advocacy of filtering that claims that
> filtering fixes the problem. It doesn't, it just minimizes the damage.
> Hiding the fact that a misconfigured firewall is leaking packets with
> inside IPs or the fact that a machine has been root compromised (or
> worse, that the actual admin likes to launch DoS attacks) ultimately
> harms everyone.

This is true.  However, I err on the side of caution, blocking that
traffic and following up why it was there in the first place.  As I have
the policies in place that prohibit such traffic, there is nothing
legitimate in the first place.  Again, as long as you followup on the
problem, I can see where not having an egress filter would be OK.

> 	Another problem with the belief that ingress source address
> filtering is the ultimate solution to the problem of spoofed packets
> is that it makes it too easy to ignore the fact that there really is a
> problem. After all, if filtering solves the problem perfectly, there's
> no need to work on a solution, all you have to do is militantly insist
> that everyone filter. On the other hand, if there's a general
> understanding that filtering is only one possible solution that has
> problems of its own, perhaps they'll continue to work on much better
> solutions.

The solution is for everyone to log/analyze/inspect the traffic on their
network.  Unfortunately, that's just not done.

I do have ingress/egress filtering.  I used to log all the RFC1918 crap
coming into my network.  Unfortunately, when talking with upstream
providers who are "leaking" these, I would always get: "not from us", or
"can't track it, sorry", or "you are filtering it, why do you care?".  So,
I gave up logging and tracking it down.

I also have ingress filtering to block my own addresses from coming into
my network.  I rarely see these type of packets coming into my network,
but when I do, I try to track them down.  Unfortunately, I usually get the
same type responses as above.  No one seems to care.

Because of my experience in trying to track down problems, I have come to
be militant about egress filtering.

=== Tim

     **********************************************
        Tim Winders, MCSE, CNE, CCNA
        Associate Dean of Information Technology
        South Plains College
        Levelland, TX  79336

        Phone:	806-894-9611 x 2369
        FAX:	806-894-1549
        Email:	TWinders at SPC.cc.tx.us
     **********************************************

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.4 (OSF1)
Comment: Made with pgp4pine 1.75-6

iEYEARECAAYFAjrCgxUACgkQTPuHnIooYbxsCgCggoLqZJUASl9fsV3LTsaQKbYQ
0wsAmQFtRrzH9DNGjW7Z1l/nu9RmehGy
=4EHh
-----END PGP SIGNATURE-----