Re: [Asrg] DNSBL and IPv6

"Emanuele Balla (aka Skull)" <skull@bofhland.org> Thu, 25 October 2012 14:37 UTC

Return-Path: <skull@bofhland.org>
X-Original-To: asrg@ietfa.amsl.com
Delivered-To: asrg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 99BEF21F8A28 for <asrg@ietfa.amsl.com>; Thu, 25 Oct 2012 07:37:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5eNMSniAmQEJ for <asrg@ietfa.amsl.com>; Thu, 25 Oct 2012 07:37:53 -0700 (PDT)
Received: from mithrandir.bofhland.org (mithrandir.bofhland.org [IPv6:2a02:9a8:94::b]) by ietfa.amsl.com (Postfix) with ESMTP id A5D5F21F8A18 for <asrg@irtf.org>; Thu, 25 Oct 2012 07:37:51 -0700 (PDT)
Received: from zarathustra.local (zarathustra.spin.it [147.123.15.60]) by mithrandir.bofhland.org (Postfix) with ESMTPSA id F0D4F6C0A1 for <asrg@irtf.org>; Thu, 25 Oct 2012 16:37:48 +0200 (CEST)
Message-ID: <50894EBB.5090907@bofhland.org>
Date: Thu, 25 Oct 2012 16:37:47 +0200
From: "Emanuele Balla (aka Skull)" <skull@bofhland.org>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:16.0) Gecko/20121010 Thunderbird/16.0.1
MIME-Version: 1.0
To: Anti-Spam Research Group - IRTF <asrg@irtf.org>
References: <20121025024859.3176.qmail@joyce.lan> <A6AF6224-421E-4483-834B-A1F658BEC7C6@blighty.com> <50891887.50103@pscs.co.uk> <0D79787962F6AE4B84B2CC41FC957D0B0D22655F@abn-exch1b.green.sophos>
In-Reply-To: <0D79787962F6AE4B84B2CC41FC957D0B0D22655F@abn-exch1b.green.sophos>
X-Enigmail-Version: 1.4.5
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Subject: Re: [Asrg] DNSBL and IPv6
X-BeenThere: asrg@irtf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: Anti-Spam Research Group - IRTF <asrg@irtf.org>
List-Id: Anti-Spam Research Group - IRTF <asrg.irtf.org>
List-Unsubscribe: <http://www.irtf.org/mailman/options/asrg>, <mailto:asrg-request@irtf.org?subject=unsubscribe>
List-Archive: <http://www.irtf.org/mail-archive/web/asrg>
List-Post: <mailto:asrg@irtf.org>
List-Help: <mailto:asrg-request@irtf.org?subject=help>
List-Subscribe: <http://www.irtf.org/mailman/listinfo/asrg>, <mailto:asrg-request@irtf.org?subject=subscribe>
X-List-Received-Date: Thu, 25 Oct 2012 14:37:54 -0000

On 10/25/12 2:14 PM, Martijn Grooten wrote:

> Anyway, back on topic: I'm still not convinced we'd be talking about
> IPv6-based blacklists if we didn't have a long and successful history
> of IPv4-based blacklists.
> 
> IP-blacklists work well on IPv4 because the IP-space is small enough
> to keep the lists small and large enough so that different IPs really
> mean different senders.
> 
> I haven't really seen a suggestion on how to run IPv6-based
> blacklists that convinced me. (That's a rather unscientific claim, I
> know. I'd love for people to help John with his simulation so that we
> get a better idea; note that he doesn't need IPv6 data. I'm afraid I
> don't have the required data myself.)

The point, IMHO, is that *nobody* has those data yet...

The number of available IPs will explode with IPv6. The number of
"legit" distinct emitters is (probably) not.


At the end, everything will be about how fast abusive/infected machines
will move around the address space:

1) from one IP to another inside their own /64
2) from one /64 to another
3) from one ISP to another, particularly where showshoe-like schemes are
in place


For point 1, there will be a limit to this change rate, at least when we
speak about bots, and it's even been cited here already: a single
machine can't use too many addresses without saturating its router
neighbor table.
Which is a valid esteem for the number of different IPs the
IPv6-address-change-mechanism will be able to use effectively, then?
Truth is we don't know for sure...


For point 2, then. The ability of a bot to move from a /64 to another
will depend on its ISP policies and implementation (like the ability of
a bot to change its IP in IPv4 depends mostly on how the ISP implemented
its dynamic allocation). Which is a valid esteem for that?
Again, we don't know for sure: too few examples for having consistent
statistics.

For number 3, the number of different allocations will only depend on
the number of different machines owned by the spammer, while there may
be no "neighbor limit" here, if the ISP did it right, so he/she could
make full use of the entire allocation.
But again, we lack a lot of statistics here as well...


So, at the moment, the only thing you can simulate is what we already
have in IPv4.


But the real IPv6 scenario will depend mostly on policies and
implementations that are not in place yet... :-\




> Can't we do something entirely different for IPv6? Like, use
> domain-based filtering by making it mandatory to DKIM-sign a message
> you send over IPv6 outside of your network? As long as IPv4 and IPv6
> are running in parallel it should be possible for IPv6 MTA to refuse
> messages that aren't DKIM-signed - and tell the sender to retry over
> IPv4.

Theoretically this could be an option, but DKIM requiring the receiving
end to receive the message DATA before choosing a policy may prove to be
a limit.



> I know this isn't an ideal solution either (one weakness is that it
> allows you to DDoS an MTA by sending large numbers of messages with
> an invalid signature), but perhaps it's better than trying to make
> IP-blacklists work over IPv6? Or perhaps someone can come with a
> better X now that MTAs can still afford to tell IPv6-senders "do X or
> retry over IPv4".

Could be. We just need to find out a good X then ;-)




My personal opinion, FWIW, is that the DNSxL mechanism will still be
useful in the future if we can limit the lookup to the first 64 bits
instead of the full address.
This reduces the problem to something comparable to the current state of
IPv4: it's true that default user allocations are larger than IPv4 ones
(say a /56, AKA 256 "listing units", instead of a single one like in
IPv4), but it's something we can still work with, probably...

It it true that there are (and there will be) entities out there
assigning stuff like a /112 per-user instead of a /64.
But maybe it's not too late to come out with "an X" trying to disallow
this setup for wannabe-mailservers...

-- 
Paranoia is a disease unto itself. And may I add: the person standing
next to you may not be who they appear to be, so take precaution.
-----------------------------------------------------------------------------
http://bofhskull.wordpress.com/