Re: [Asrg] DNSBL and IPv6

Mikael Abrahamsson <swmike@swm.pp.se> Fri, 19 October 2012 07:25 UTC

Return-Path: <swmike@swm.pp.se>
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 9E63721F86D1 for <asrg@ietfa.amsl.com>; Fri, 19 Oct 2012 00:25:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.249
X-Spam-Level:
X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[AWL=-0.250, BAYES_00=-2.599, J_CHICKENPOX_45=0.6]
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 xaIggzo77FoP for <asrg@ietfa.amsl.com>; Fri, 19 Oct 2012 00:25:18 -0700 (PDT)
Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) by ietfa.amsl.com (Postfix) with ESMTP id 00B4121F8641 for <asrg@irtf.org>; Fri, 19 Oct 2012 00:25:16 -0700 (PDT)
Received: by uplift.swm.pp.se (Postfix, from userid 501) id E832B9C; Fri, 19 Oct 2012 09:25:12 +0200 (CEST)
Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id E0E689A for <asrg@irtf.org>; Fri, 19 Oct 2012 09:25:12 +0200 (CEST)
Date: Fri, 19 Oct 2012 09:25:12 +0200 (CEST)
From: Mikael Abrahamsson <swmike@swm.pp.se>
To: Anti-Spam Research Group - IRTF <asrg@irtf.org>
In-Reply-To: <CALgnk9rEPZwR5UHqeqSWQOPLYMOdLCF=hP1u+oeFatoVoavv3w@mail.gmail.com>
Message-ID: <alpine.DEB.2.00.1210190922310.28593@uplift.swm.pp.se>
References: <alpine.DEB.2.00.1210190822090.28593@uplift.swm.pp.se> <CALgnk9rEPZwR5UHqeqSWQOPLYMOdLCF=hP1u+oeFatoVoavv3w@mail.gmail.com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
Organization: People's Front Against WWW
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
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: Fri, 19 Oct 2012 07:25:18 -0000

On Fri, 19 Oct 2012, Matthias Leisi wrote:

> On Fri, Oct 19, 2012 at 8:22 AM, Mikael Abrahamsson <swmike@swm.pp.se> wrote:
>
>> Fundamentally in IPv6, a "customer" (or entity or whatever) will in a lot of
>> cases not a single IP address, but a network.
>
> At the beginning of an SMTP transaction, all you have is a single IP.

Yes.

>> Households will get /64s, or get a /56 via DHCPv6-PD. Phones get a /64 or a
>> network via DHCPv6-PD. Companies get /48 (or something else, but a bunch of
>
> As a spam filter (software developer), you may want to know more about
> the reputation of the IP address connecting to you.

Yes, and that reputation is derived from what subnet it's a subset of.

> You need an algorithm where you start from a single IP address and then 
> potentially "move up" until you get a meaningful result. That's more or 
> less what the B-tree algorithm suggested by John Levine some months ago 
> would offer: variable "depth" and "density" of data controlled by the 
> DNSxL operator optimized for the (on average) lowest number of lookups 
> needed.

Sounds good to me.

> At the same time, having a standardised and light-weight protocol to
> determine the allocation policy by the ISP would be hugely helpful
> (this will likely then be mirrored by the DNSxL operator). Absent such
> data,third parties have to fall back to some default /64 etc.

Yes, which will be less than effective when customers are handed /48s and 
can send from anything within that /48.

>> What I feel needs to happen is that policy needs to put in place to 
>> RIRs (via ISPs) can present "what is a customer" on a network level, 
>> and then this information can be put into DNS somehow, and used for 
>> DNSBL.
>
> I don't know whether RIRs can mandate the publication of this data
> through policy.

RIPE already does (basically), as in "this /42 contains customers where 
each customer has a /56". I don't know about other RIRs.

-- 
Mikael Abrahamsson    email: swmike@swm.pp.se