Subject: Re: [Asrg] DNSBL and IPv6

From: Hal Murray <[email-masked]>
Date: Wed, 24 Oct 2012 19:00:17 -0700

John Levine said:
> Depends what your intentions are.  If you're trying to do listwashing, you
> may wall see DNSBL listings rather than bounces.  I like VERP just fine and
> my lists use it, but I do get back FBL reports that are munged to the point
> where I can't tell who complained.  But they rarely munge the IP. 

People trying to avoid listwashing will learn to munge the bottom bits of any 
IPv6 address.

Similarly, DNSBLs could mask off the bottom bits of any IPv6 address that 
they expose.

-- 
These are my opinions.  I hate spam.

---

From: "John Levine" <[email-masked]>
Date: 25 Oct 2012 02:48:59 -0000

>People trying to avoid listwashing will learn to munge the bottom bits of any 

Well, maybe.  Personally, I think the threat of listwashing is overstated.
The really slimy senders have lists so dirty that no amount of washing will 
clean them.

But anyway, I'm seeing a lot of assertions about how IPv6 mail will work,
and precious little running core or simulations.  As always, anyone want
to do some, you know, research?

R's,
John

---

From: Steve Atkins <[email-masked]>
Date: Wed, 24 Oct 2012 20:00:03 -0700

> to do some, you know, research?

It's mostly dependent on how IPv6 addresses for mailservers (legitimate and
otherwise) will be allocated, and how much IPv6 will be used for inter-domain
email delivery. Do we have any data, or researched speculation, about that
to work from?

Cheers,
  Steve

---

From: Paul Smith <[email-masked]>
Date: Thu, 25 Oct 2012 11:46:31 +0100

> email delivery. Do we have any data, or researched speculation, about that
I actually think getting any *useful* data about this would be very 
tricky at the moment, if not impossible.

I know that we can't use IPv6 anywhere. We have 4 broadband connections 
with different suppliers, and none support IPv6 yet, and the data centre 
we use for our servers also doesn't support IPv6 yet. I guess lots of 
people are in the same situation, especially smaller companies. This 
probably means that spammers in general won't be using IPv6 yet - would 
it be worth their hassle, given that most of their 'customers' won't 
have it. So, anyone who does have IPv6 MX servers will probably just be 
getting IPv6 mail from people like Google, and no one else.

So, it might be interesting to get data to see how widely IPv6 is used 
for email currently, but it's unlikely to be useful data to give us 
realistic ideas how spam will affect the IPv6 infrastructure in the 
future. eg, there may be virtually no IPv6 spam now, but it won't stay 
that way.

(My personal view is that IPv6 for widespread email use is well in the 
future. There is no huge advantage over IPv4 given that the number of 
MTAs is vastly smaller than the number of other Internet connected 
devices. For interoperability, everyone with an MTA will NEED an IPv4 
address for now. There are complexity issues especially to do with 
security, hacking protection, spam filtering etc. So, I think most mail 
admins will be leaving IPv6 turned off until they need to turn it on - 
which may take a while, since it'll be a catch-22 situation. What may 
trigger it is if someone like Google decides to turn OFF all IPv4 
support in their mail infrastructure, but I think that's unlikely for 
the foreseeable future...

MSAs may support IPv6 a lot sooner to support their IPv6 MUAs, but those 
won't have the spam issues.

I know this isn't an 'IETF approved' viewpoint, but it's mine, based on 
our customers)

-

Paul Smith Computer Services
Tel: 01484 855800
Vat No: GB 685 6987 53

---

From: Martijn Grooten <[email-masked]>
Date: Thu, 25 Oct 2012 12:14:00 +0000

> My personal view is that IPv6 for widespread email use is well in the future.

I think you'll find few experts who think that there's an urgent need for IPv6 for email. But IPv6 is currently being used for email (Google and Comcast are among those currently accepting email over IPv6 - and these are big players) and its use could (and probably will) increase. I think it would be a rather bad idea if spammers got an easy ride if they were to send mail over IPv6.

And personally, I think it would also be bad if we told people to start using IPv6 as soon as possible, except for email because we don't really know how to do spam filtering there.

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.)

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.

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".

Martijn.

________________________________

Virus Bulletin Ltd, The Pentagon, Abingdon, OX14 3YP, England.
Company Reg No: 2388295. VAT Reg No: GB 532 5598 33.

---

From: Matthias Leisi <[email-masked]>
Date: Thu, 25 Oct 2012 14:35:30 +0200

> 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 w…

I'm obviously biased since I run dnswl.org, but an IPv6-based
whitelist may work better than an IPv6-based blacklist. Enumerating
the goodness is generally easier than enumerating the badness.

(Of course, all IPv6-DNSxLs have the same risk of caches blowing up if
not done right, and the "done right" thing has not been defined yet).

-- Matthias

---

From: "John Levine" <[email-masked]>
Date: 25 Oct 2012 14:11:58 -0000

>email delivery. Do we have any data, or researched speculation, about that

Well, I'm at a meeting where I can ask around.

I did a little greppage this morning and found that in the year that
I've had incoming v6 mail, I've gotten connections from a total of
2300 addresses.  The vast majority of mail is from a handful of known
senders such as the IETF, and NANOG.

The real answer is that nobody knows what the IP address patterns will
be, but I think we can come up with some plausible scenarios.  The
number of legitimate mail servers doesn't seem to be growing very
fast, so I expect the real mail will continue to come from a
relatively small set of IPs.  Bot spam might just use whatever address
the host already has or might hop around.  At breakfast this morning,
someone pointed out that Windows uses IPv6 anonymous addresses, and
they'd seen their users hop around somewhat.

http://www.microsoft.com/resources/documentation/windows/xp/all/proddocs/en-us/sag_ip_v6_imp_addr7.mspx?mfr=true

R's,
John

Here's the IPs that have connected more than 1000 times in the past
year:

34084 2001:1890:123a::1:1e
12971 2001:1838::cc5d:d48a
12113 2001:4f8:fff6::35
7611 2001:1890:1112:1::1e
5810 2001:1890:126c::1:1e
4810 2a02:2658:1011:1::2:2013
3747 2001:500:13::107
3298 2604:8d00:0:1::3
3259 2604:8d00:0:1::4
2309 2001:1890:123a::1:2f
2239 2604:8d00:0:1::9
2074 2001:48a8:6880:68::116:162
1635 2620:0:2d0:1::100
1281 2001:1868:4:1::25
1251 2a01:4f8:120:9382::145
1058 2001:1838:2001:8::4

---

From: Rob McEwen <[email-masked]>
Date: Thu, 25 Oct 2012 10:24:33 -0400

On 10/25/2012 10:11 AM, John Levine wrote:
> but I think we can come up with some plausible scenarios.

One thing that is harmless and which should be promoted now is the
exclusive use of IPv6 addresses for authenticated e-mail headed to the
mail server.  That way, IPv6 can be dynamically assigned IPs for things
like residential customers where that end user's IPv6 would never sent
mail directly to the recipient. Then, such a mail server could, for now,
ONLY accept mail for THOSE smtp-authenticated/IPv6 sessions, and
actually refuse non-authenticated IPv6 traffic. Such a server would then
relay out such mail via IPv4. 99.9% of the argument about hurrying up
IPv6 implementation for mail servers due to running out of IPv4 IPs are
solved by this scenario since there are thousands of dynamically
assigned IPs delegated to end users for every one legitimate mail server IP.

Not saying this is the answer for 100 years from now, but this scenario
scales well, too. When EVERYTHING is assigned an IPv6 IP (your car, your
refrigerator, etc)... those IPv6 IPs won't be prevented from sending
e-mail in the scenario I described above, even if mail servers haven't
yet moved into the IPv6 world.

-- 
Rob McEwen
http://dnsbl.invaluement.com/
[email-masked]
+1 (478) 475-9032

---

From: "Emanuele Balla (aka Skull)" <[email-masked]>
Date: Thu, 25 Oct 2012 16:37:47 +0200

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/

---

From: "Emanuele Balla (aka Skull)" <[email-masked]>
Date: Thu, 25 Oct 2012 16:48:05 +0200

On 10/25/12 4:24 PM, Rob McEwen wrote:

Hi Rob!

> yet moved into the IPv6 world.

So you're basically suggesting that MXs should not allow any IPv6 SMTP
connection unless it's coming from a trusted entity, and only MSAs
should speak IPv6.

This will allow to work in the upcoming IPv4 shortage scenario, as you
say. But I think you underestimate how hard could be switching from this
scenario to the "all IPv6" one in the future...

In other words, you're basically suggesting something like "do not
publish any AAAA record for your MXs and just rely on IPv4, unless you
found a solution to the IPv6 spam problem".

But this is not suggesting a solution anyway... ;-)

---

From: Paul Smith <[email-masked]>
Date: Thu, 25 Oct 2012 15:37:51 +0100

On 25/10/2012 13:14, Martijn Grooten wrote:
> 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
Is it even possible to tell an IPv6 sender to retry over IPv4? I know 
I've seen discussion about whether it should be possible, but I'm fairly 
sure it wasn't at that time (I think it should be possible)

Having a 'retry over IPv4' option would help a lot, especially if we had 
a mechanism to link an IPv6 and an IPv4 attempt - could be a good way of 
bootstrapping an IPv6 reputation system (or whitelist). But, I'm not 
sure the IETF would approve, and it may be too late anyway...

I do think that (with hindsight) IPv6 support for MTAs could have done 
with more thought before it was standardised. Things like requiring DKIM 
(or SPF or some new equivalent) and mechanisms to fallback to IPv4 may 
have been good things to enforce in an IPv6 world so being a mandatory 
part of 'SMTPv6' rather than options as we'd have to do now. MTA SMTP is 
a totally different world from pretty much everything else IP because 
although deployment is very widespread the actual number of legitimate 
MTAs is tiny compared to the rest of the Internet connected stuff, and 
SMTP is also quite vulnerable to 'legitimate attacks' unlike other 
protocols (eg most spam is sent by doing everything according to the 
standards, not by trying to find loopholes in it). IPv6 could have been 
the place to build a 'safe new SMTP world', but that opportunity is 
pretty much gone now :-(

-

---

From: Rob McEwen <[email-masked]>
Date: Thu, 25 Oct 2012 11:19:04 -0400

> connection unless it's coming from a trusted entity, and only MSAs

No. I'm talking about AUTHENTICATED e-mail that is, by design, NOT
considered the "sending IP" for that message. Maybe the "originate
IP"... but not the "sending IP". I'm not sure what you mean by "only
MSAs", this wouldn't prevent the use of IPv6 for OTHER uses. My answers
below should clear this up...

> found a solution to the IPv6 spam problem".

I think you must be greatly misunderstanding me. When millions of end
user customers for a large set up their outlook programs (or
thunderbird, or whatever)... their connection to their ISP's mail server
does NOT use MX records!!!! Instead, that connection goes DIRECTLY to
the "a" record of the server host name that the end user puts in the
"smtp server" box in their mail client. Furthermore, since this is all
happening within an ISP's IP space and to their own customers.. the ISP
has MUCH granularity of control... so, if needed, directing of traffic
can be manipulated somewhat by the ISP (again, if needed).

> But this is not suggesting a solution anyway...

yes, this is a solution. Obviously NOT the final solution long term
solution... but this solves MANY problems in the meantime.

---

From: "Emanuele Balla (aka Skull)" <[email-masked]>
Date: Thu, 25 Oct 2012 17:38:26 +0200

On 10/25/12 5:19 PM, Rob McEwen wrote:
> does NOT use MX records!!!!

I think we're speaking of the same thing here... :-)

MSA == Mail Submission Agent, the SMTP server your MUA (Outlook,
Thunderbird, pine) will connect to in order to send email.

MX in my notation was intended as "the MTA on the receiving end" or, in
other words, a mailserver that expects to be contacted by others MTAs
only, not by MUAs.

So, to rephrase the whole thing as I understood it:

- allow end customers to use IPv6 to *send* email through their ISP's
(not necessarily the connection one) IPv6-enabled authenticated mailserver

- do not allow the receiving mailserver (aka "the one published as MX
record for the domain") to receive email from strangers through IPv6

Did I get it right?

---

From: Rob McEwen <[email-masked]>
Date: Thu, 25 Oct 2012 11:47:59 -0400

> record for the domain") to receive email from strangers through IPv6

yes. Except that, again, the authenticated mail being sent by end users
to be relayed out by their ISPs mail server doesn't require that any
domains having "two-faced" MX records.

---

From: Paul Smith <[email-masked]>
Date: Thu, 25 Oct 2012 16:37:26 +0100

> Truth is we don't know for sure...
Hmm - I've heard talk about this problem of saturating the router 
neighbour table. To be honest, I'm not entirely sure what a 'neighbour 
table' is... But, why would people have a /64 block if the router can't 
cope with it?

> Could be. We just need to find out a good X then
Rather than using DKIM, why not use client certificates keyed off the 
sender domain. That way you don't need to get the message content.

It would require TLS for all IPv6 MTA-MTA connections, but given that 
'old' servers won't support IPv6, and new ones 'should' support TLS, 
that shouldn't be an insurmountable problem. It would also mean that a 
sending MTA couldn't send to the same target MTA using the same 
connection for different sender domains. This wouldn't be a problem for 
small->moderate sized MTAs.

I suppose it's only the big MTAs (google et al) who would suffer a bit 
because of something like this, but then, if it cut down on the spam, 
they'd probably gain more than they lost.

The problem is that certificates on their own (like DKIM) won't 
necessarily reduce spam, just spoofing. So, there'd need to be some way 
of linking reputation to domain, but that would be the same with DKIM.

-

---

From: "Emanuele Balla (aka Skull)" <[email-masked]>
Date: Thu, 25 Oct 2012 18:10:52 +0200

> table' is...

Basically, the ARP table, except for IPv6 not using ARP at all...

> But, why would people have a /64 block if the router can't
> cope with it?

The point is a /64 allows basically an infinite number of devices in one
single network (2^64 being big enough to be considered infinite for our
purpose).

This doesn't mean a router should be able to manage an infinite amount
of devices: no router could accomplish this requirement... :-)

The router basically needs to cope with a given number of devices inside
the /64. Maybe 10, maybe 100, maybe 1000, but a limited amount, compared
to 2^64. The neighbor table must be able to keep track of IPv6-MAC
associations for each device.

But if one of these devices starts changing address quickly enough, it's
going to saturate the router memory (or only the neighbor table) at some
point...

What happens next depends on how the router will manage the issue...

---

From: Paul Smith <[email-masked]>
Date: Thu, 25 Oct 2012 17:28:49 +0100

> Basically, the ARP table, except for IPv6 not using ARP at all...
OK. I know what an ARP table is :-)

The name 'neighbour table' made me think it was trying to track which 
other routers were around (ie 'neighbours' of this router), which was 
strange if that got upset by the number of internal addresses being 
used. My mental visualisation sees the router as a 'gatekeeper', so the 
internal devices would be 'occupants' or something, not 'neighbours'. 
So, I visualised that 'neighbours' would be things on the same 'level' 
as the router - ie other routers.

I've done a bit more reading around on the subject, and am getting there 
- I think :-)

It's tricky since we have no access to any IPv6 stuff unless I use a 
tunnel or an internal test network, which has always been an 
"artificial" environment AFAIAC (no local router involved), so doing 
full scale real-world tests isn't possible yet.

> associations for each device.
OK

-

---

From: Scott Howard <[email-masked]>
Date: Thu, 25 Oct 2012 09:50:27 -0700

On Thu, Oct 25, 2012 at 9:28 AM, Paul Smith <[email-masked]> wrote:

> tunnel or an internal test network, which has always been an "artificial"
> environment AFAIAC (no local router involved), so doing full scale
> real-world tests isn't possible yet.
>

A tunnel doesn't need to be "artifical". Hurricane Electric will give you a
free IPv6 tunnel, including a routable range (/56 from memory).  Setup the
tunnel on one machine, and then configure it to be a router for your local
network (using one of the networks from the /56).  All of the hosts on that
network will now have "native" IPv6.  Sure, to get out of your network it
has to go via a tunnel, but that's completely transparent to the end hosts.

Keep in mind the security implications though - if you don't setup a
firewall on your IPv6 tunnel endpoint/router, then you're basically putting
any of the systems it routing traffic for directly onto the Internet, with
a public IP address.

  Scott

---

From: Mikael Abrahamsson <[email-masked]>
Date: Fri, 26 Oct 2012 15:27:35 +0200 (CEST)

> 3) from one ISP to another, particularly where showshoe-like schemes are

I believe it's going to be common enough that legitimate MTAs will move 
around within their /64 quite frequently (privacy extensions that are 
default on in Windows for instance), means outgoing IPv6 address will move 
to a new outgoing address every N hours (where N is somewhere between 
1-48, I don't know exactly).

-- 
Mikael Abrahamsson    email: [email-masked]

---

From: Matthias Leisi <[email-masked]>
Date: Fri, 26 Oct 2012 15:32:14 +0200

> around within their /64 quite frequently (privacy extensions that are

Using a /64 as a default seems reasonable, but a new standard for
DNSxL lookups should provide some flexibility, either for a full list
("default prefix length = /56") or on a more granular level (using
John L.'s original proposal, or some other useful method).

-- Matthias

---

From: Paul Smith <[email-masked]>
Date: Fri, 26 Oct 2012 15:08:58 +0100

> John L.'s original proposal, or some other useful method).

The problem with a /64 for black/white listing is that it's not quite 
the same as an IPv4 /32. So, at the moment we may have a /25 or /26 
block, but we'd still have a single IPv6 /64

We may run 50 customer dedicated  mail servers on our /64 block, and 
ideally we'd want each to have their own reputation. So, we couldn't do 
this if DNSBL/WL filtering is on a /64 block. With our current IPv4 /26 
each customer's server would have it's own reputation on an IPv4 DNSBL/WL.

Obviously we couldn't say what level of granularity we'd want, or 
spammers would just say 'we want /128 granularity', to overload everything.

We could (theoretically) get a /48 block, but that would be a waste (I 
know there are LOTS of /48's out there, but still), since we wouldn't 
need it for routing, just for making it work with /64 based 
black/whitelisting.

I can't think of a good answer to this, but our case is a use case which 
isn't going to be that unusual.

-