> not just the bad people. all the people. a network with 2 or 3 in place
> is useless. there is no way to make 2 or 3 happen.
As part of their anti-spam efforts, several providers block SMTP port
25, and force their subscribers to only use that provider's SMTP
relay/proxy to send mail. Why not extend those same restrictions to
other (all) protocols?
each protocol that becomes as widely abused as smtp has been, will be
blocked, since blocking will save the ISP money. you also mentioned
proxying of web traffic, which due to banner ads often makes the ISP
money. this whole thing is really about money. but "1" isn't getting
done because the money that could be saved is by ISP "B" whereas the
money which must be spent is by ISP "A". so, the nondeployment of BCP38
is all about money, too.
the thing i'm trying to work my way back to is that "2" and "3" can be
argued to restrict desireable freedoms (like reaching SMTP or WWW servers
without being forced to use a local proxies) whereas "1" has no arguments
against it, or at least no arguers here on nanog today. why lump them
all three together?
PS. you mentioned AOL, which uses IP framing in order to leverage off of
the IP stack already present in their customer's computers, but other
than that it's a captive application. what addresses are used doesn't
really matter there in any global sense, nor proxies or nats or whatever.
money. this whole thing is really about money. but "1" isn't getting
done because the money that could be saved is by ISP "B" whereas the
money which must be spent is by ISP "A". so, the nondeployment of BCP38
is all about money, too.
As the other Sean (Doran) likes to say, write a check. But that is too
simplistic. It presumes only B saves money and only A spends money. On
any particular day either A or B may be losing money due to attacks. I
suspect on most days, both A and B are losing money.
Money is probably 4 or 5 on the list of reasons why source address
validation doesn't get implemented.
the thing i'm trying to work my way back to is that "2" and "3" can be
argued to restrict desireable freedoms (like reaching SMTP or WWW servers
without being forced to use a local proxies) whereas "1" has no arguments
against it, or at least no arguers here on nanog today. why lump them
all three together?
Source address validation, or more generally anti-spoofing filters, do
not require providers maintain logs, perform content inspection or
install firewalls. But source address validation won't stop attacks,
viruses, child porn, terrorists, gambling, music sharing or any other
evil that exists in the world. So the proposal "1" gets extended to
include other stuff. It gives better ROI when more than SAV is included.
"1" is install provider managed firewalls to perform
a. validate source addresses
b. perform virus checking
c. maintain forensic logs
d. other "policy enforcement" to be determined
e. anything else someone can think of
What worries me is "scope creep." All sorts of stuff is getting thrown
into the security pot.
Anyone noticing an increase in the amount of port 137 scans?
I've seen just just over 100 in the last 1 hour. When I probe the offender
I see them as MS items with their Harddrives shared wide open.
Only thing in common is they all appear to have some file called put.ini in
their root directory with a line that looks to be from a win.ini and states
brasil.pif or exe. Maybe some new virus?
Well heads up.
We've seen a lot! of this, thousands of matches per hour when we put in an
acl. We were under Ddos some time ago and all the requests were on port
137. A simple filter on netbios-ns on my upstream fixed it but its uggly.