On 12/30/2010 5:43 PM, John Levine wrote:
Ah, I see the problem. You're assuming that spammers will follow the
rules. That's a poor assumption.
No, I am assuming the spammers will do as they have always done in the
past - attempt to use other people's computers for free. Other
computers that are NOT cycling through lots of IP number in the
normal case.
The IPv6 address space is big. Very, very big. Even if you chop it
in half to /64s, it is still four billion times bigger than the v4
address space. Bad guys hopping around /64s will blow out your DNS
cache just as badly as hopping around /128s.
No, since the number of total host numbers in a /64 is vastly larger
than in a /128, if you hold to single number queries then it will blow
it out far far faster.
I suppose that's technically correct, in the sense that blowing out in
a millisecond is faster than blowing it out in a minute, but that hardly
matters to people running DNS caches. Let's do a thought experiment:
imagine you have a big honking DNS cache with 100 billion slots. If we
had a BL with one potential entry per /64 (keeping in mind that a cache
remembers both successful and failed queries), how much of the address
space can you query before your cache fills up?
Answer 0.00000054% Kaboom!
Which is precisely why the querying app, -SA-, needs to get smarter
about doing this and limit their queries.
Don't you realize that the same thing could be done TODAY to limit
queries? SA's developers could make a very (IMHO) legitimate assumption
that any IPv4 address that comes up as a positive hit on a
BL automatically marks the entire /24 that the IPv4 address is
in, based on the idea that a spammer is going to obtain a /24 subnet
and cycle through the IP numbers in that subnet. Or it could get
smarter and when a BL hit comes though, it could query the RIR's
whois database, parse out the subnet that the IPv4 address is in,
and blacklist that subnet.
The only reason nobody has done this is because there has been no
interest in limiting DNS queries from most SA users.
The other thing is that if a spammer blows out a client's DNS cache
(or a client's ISP's dns cache) then the MTA is going to start
hanging, while it waits for DNS queries that never return (since
the server is overloaded) and mail receiving will get very, very
slow - hardly the situation the spammer wants when their intent
is to deliver e-mail spam!!!
Any attempt to roll through adjacent IPv6 numbers from a /64 or
even from adjacent /64's is a condition that the RBL can easily check
for with just a little bit of logic added, and this kind of behavior
should instantly mark the e-mail sender as malevolent and a
likely spammer.
The spammers intent is to camouflage itself, to appear as
similar as possible to other legitimate mail senders. Legitimate
mail senders will not be rolling through all IPv6 addresses in a
/64 so if a spammer wants to stay below the radar and not get noticed
then they won't be doing it either.
I live in a neighborhood in a house with a large window that faces
the street. While it is in theory possible that a gang banger may
come through the neighborhood indiscriminately shooting at homes,
I am not going to be replacing that window with bulletproof glass.
Just because it is possible for the window to be shot out doesn't
mean it is ever going to happen.
And just because a spammer may be able to roll through individual
/128's in a /64 does not mean that any of them ever is going to do
it. After all, just because a spammer can get a real job and quit
living in their mothers basement doesn't mean that any of them
are ever going to do that, either.
Well for starters it almost sounds to me like your not that familiar
with IPv6 to even say this. The lower 64 bits of the address is the
interface identifier, and the upper 64 bits is the sub-network
prefix.
If you use SAA, sure. If you use DHCP, the address layout is whatever
it is.
Huh? You do realize there's 2 different DHCP's under IPv6, right?
awww screw it, I'm talking to a wall, here.
It is extremely abnormal for a host to change it's MAC address every
few milliseconds, so the idea that a spammer could cycle through the
lower /64 using 1 address per message is in the realm of extreme
improbability.
Like I said, you're making the poor assumption that spammers will
follow your rules. In reality, they'll do whatever they think will
get their spam through.
and doing this cycling just makes them much more visible as a spammer
a lot quicker, thus making it a lot easier to smack 'em down faster.
The only reason to run around saying the sky is falling is if your
coming at this from the point of view that it would be a normal thing
to see packets from the same /64 that have many different interface
identifiers, which there is no logical need for this to ever happen.
Like I said, you're making the poor assumption that spammers will
follow your rules. In reality, they'll do whatever they think will
get their spam through.
And your using emotionally laden language like "my rules" when the
concept of interface identifier is straight from IETF not from me.
Probably because your not interested in discussing the simple and
obvious alternative of modifying SA and the RBLs to be a bit smarter in
their queries. You dismiss it out of hand in your draft with the
comment:
"...it is not helpful for DNS whitelists, which by their nature list
individual IP addresses..."
even though whitelisting is nothing more than a sellout for ISPs and
helps make spammers rich.
You would be better off starting with the assumption that the
existing design is fine, but that it needs adjusting for the new
circumstances for IPv6.
I did that. It doesn't work.
I am not saying your solution will not work. I am saying that it is
over engineered and introduces a vast amount of unneeded complexity
all for the sake of - as you say in your draft:
for DNS
whitelists, which by their nature list individual IP addresses, and
are likely to be far more popular with IPv6 mail than they have been
with IPv4 mail.
There is no evidence that whitelists will be embraced by the Internet
user community under IPv6 anymore than they have been under IPv4 - which
is to say, not at all. So far the only orgs who have wanted whitelists
around have been the largest ISP's like AOL Comcast, etc. And they only
want them so they can decrease the amount of CPU they spend on
processing inbound mail. Their users by contrast, hate them, since all
the whitelisting does is give spammers a direct unfiltered route
straight into the users mailbox.
And you want to INCREASE this nonsense on the Internet?
It's far better for the RBL's to just blacklist the entire /48 that
a spamming IPv6 address appears in. Sure that sounds draconian but
that's because your thinking in IPv4 address-scarcity terms. The
RBLs can always offer 3 different query servers, one for /48's, one
for /56's and one for /64s but a /48 is what we need to be shooting for.
The MINIMUM allocation make by an RIR for IPv6 to an ISP is a /32 -
that means THE SMALLEST ISP OUT THERE THAT QUALIFIES FOR AN RIR-ASSIGNED
IPv6 GETS A /32.
That allows the ISP to assign 65 THOUSAND /48's. Most ISP's do not
have that many customers. The idea that a legitimate mail-sending
customer out there - ie: a business running it's own mailserver -
isn't going to have a /48 from it's upstream - is ludicrous.
Ted
R's,
John
