Carrier Trick To Save IPv4 Could Help Spammers

Julie188 writes "As public IPv4 addresses dwindle and carriers roll out IPv6, a new problem has surfaced. We have to move through a gray phase where the only new globally routable addresses we can get are IPv6, but most public content we want to reach is still IPv4. Multiple-layers of NAT will be required to sustain the Internet for that time, perhaps for years. But use of Large Scale NAT (LSN) systems by service providers will cause problems for many applications and one of them is reputation filtering. Many security filtering systems use lists of public IPv4 addresses to identify 'undesirable' hosts on the Internet. As more ISPs deploy LSN systems, the effectiveness of these IPv4 filtering systems will be hurt."

Comments

The Only Real Solution

[windcask]

Welcome back, Gopher.

Re:Figures

[Ironchew]

remember apps both client and server have to support v6, not just the OS

Really badly written programs.
Seriously. I've written stuff in C with the sockets API that is IPv4/v6 agnostic. It's easy to do; there is no excuse for not implementing it.

Trivial if you want to go the extra mile

[Khopesh]

I work for an IP reputation company (and am not representing it in this post).

This is not a complicated issue. The LSN portals will merely have to add a tracking header to all mail they process (and block anonymous direct mail if they want to escape DNSBLs' wrath). This is already an issue with webmail (e.g. Google doesn't add the tracking header, so it's MUCH harder to trap spam originating through GMail than it is through providers like Hotmail who do provide this extra tracker).

Re:Trivial if you want to go the extra mile

[Khopesh]

How much spam actually is originating through gmail?

Sorry, I can't give you data. Suffice it to say it's a problem.

How does one prevent a spammer from spoofing these headers?

The headers aren't spoofed. When you use Hotmail or Yahoo, your IP is added to a tracking header by the webmail server so that IP reputation systems can pass along the blame as if it were a Received: header (there's more to it than that, but this should give you the principle). Since GMail doesn't do that, there's nothing to be done; the tracking can't go beyond Google's servers.

If a spammer spoofs headers so as to pretend to pass blame on, the trust doesn't extend far enough; the relay used by the spammer to add those fake headers isn't trusted and so the buck stops there. When dealing with real webmail providers, the trust can be extended to the established webmail relays and then followed into the IP tracking header.

We have meandered a bit off topic here ... my point is that this is possible for the nearly identical problem of webmail, so somebody merely needs to figure out how to do it for the IPv6->IPv4 routing process. The simplest solution is the one I outlined above; require a mail relay that speaks both protocols so it can properly record the conversion with a Received header. Modern IP reputation systems (and the clients that poll them) are fully IPv6-ready and will process this perfectly.

Not just spammers

[Todd Knarr]

It's not just spammers. A lot of on-line games, for instance, record the IP address used to log in to a game in the account's history. Customer Support then uses that to help determine eg. whether a claim of a hacked account is valid or bogus. Large-scale NAT is going to mess with that by confusing the record: one computer may appear to be using a different IP address for each login, and multiple unrelated computers can appear to have the same IP address. And with a lot of games moving towards RMT, a hacked account can mean the loss of real money for the player. When CS tells that player "Sorry, the login where the items were sold/transferred came from one of the IP addresses you normally log in from, the problem's on your end." and the player learns that that's because his ISP is NATing their entire network, he's not going to be happy.

Re:Not just spammers

[jamesh]

and the player learns that that's because his ISP is NATing their entire network, he's not going to be happy.

</reality>... and he goes to forums where such things are discussed and finds out that other users are using IPv6 and don't have problems like that and asks his ISP why they don't support IPv6. The ISP listens to their customers and makes rolling out IPv6 their #1 priority. IPv6 gets everywhere, world peace is finally achieved, and we enter a golden age of the internet.<reality>

Re:Not just spammers

[mewsenews]

When CS tells that player "Sorry, the login where the items were sold/transferred came from one of the IP addresses you normally log in from, the problem's on your end." and the player learns that that's because his ISP is NATing their entire network, he's not going to be happy.

I understand the point you are trying to make, and I agree with you. I just have to be pedantic and point out that currently, for WoW accounts that have been tampered with, it doesn't matter that the activity was on the same IP address.

If it did matter, there would be a lot of guys with neglected girlfriends that would be unable to get their characters restored.

Re:Really?

[icebike]

More to the point, SMTP hosts will be pretty much forced to do something more productive than blocking via IP, which amounts to group punishment. (Something apparently only tolerated on the internet).

Its sad that the most broken of protocols has this much sway over the net. SMTP needs a ground up re-write, and it will need it just as much (if not more) after IPV6 is deployed.

Can we just stop using IPv4?

[asm2750]

Seriously, IPv6 is there to replace IPv4. Tell everyone who whines 'tough shit' switch over already. If I have to pay an extra 5 dollars a month for a year to my ISP for that to happen then I would. Just stop trying to extend the life of IPv4 when there is a suitable replacement already available.

Re:Figures

[JSG]

My ISP (AAISP) actively encourage IPv4 address exhaustion AFAICT.

They gave me a /29 + a /32 for my router for home use and probably would have given me more if I'd asked. At work I asked for a /28 and got a /27.

They also give out a /48 IPv6 subnet to all customers and instructions for use. They can do IPv6 over PPPoA (this is the UKoGB) natively and provide a IPv6 to 4 tunnel broker for those that need it.

Have a look at your Spam Assassin headers and see that quite a lot of marks are not related to IP address. I have found DNSBLs handy up to now but I think I'll accept that as these lose their efficiency during IP version handover my spamds and MTAs will get a bit more of a battering for a while.

Never mind processing power is pretty cheap.

I have a customer with around 16 million unique IPs trying to get in each week - a spambot net of some sort (Russian and Chinese IP feature a lot). An Exim process is being spawned for each connection along with a spamd and possibly clamd session. The box is a dinky Dell single processor server and it barely breaks a sweat.

Cheers
Jon

Re:Figures

[petermgreen]

Really badly written programs.
Or just old programs.

Afaict windows didn't have getaddrinfo until XP (unless you count the version in the IPV6 technology preview for 2K). It's predecessor gethostbyname only supports IPV4. MS does offer a wrapper to help with this but afaict that only helps if you are coding with MSVC[++] (I ended up writing my own wrappers for fpc/delphi, not too hard but definitely extra effort)

Further it seems while windows has wsaasyncgethostbyname there is no wsaasyncgetaddrinfo. So if you want to do a v6 capable name lookup without blocking the rest of your app you have to do it on another thread.

P.S. yes I HAVE implemented code (in delphi style pascal) directly on the low level apis that supported both v4 and v6 and async lookups (by using a thread) and supported older operating systems (by using getprocaddress and my own "v4onlygetaddrinfo" if the getprocaddress fails). I wouldn't exactly call it trivial though.

Re:Figures

[petermgreen]

My ISP (AAISP) actively encourage IPv4 address exhaustion AFAICT.
It's really not in ISPs interests to conserve IPs at this point. The more IPs they can get out of the RIRs now the more IPs they will have to reuse for more lucrative customers later.

Doesn't follow

[Spazmania]

As more ISPs deploy LSN systems, the effectiveness of these IPv4 filtering systems will be hurt.

That doesn't follow. The folks in dynamic space (the same space that will be served by LSNs) are already considered spammers when they connect to a non-local SMTP server. The only reason they're scored instead of outright blocked is that there's no rigorous list of what is and isn't a dynamic space. It makes no difference to the server whether it filters a range of IPs or a single IP.

Identifying the individual spammer from an abuse report is slightly more difficult, but only slightly. And if you're behaving like a good net citizen, you probably blocked outbound 25 at the LSN box to begin with so you're not getting any reports because your virus-laden customers aren't able to successfully spam.

+1 funny

[reiisi]

The last time I contacted my ISP about this they told me (again) that they have no plans to implement IPv6.

This was just a few months ago.

Re:Really?

[afidel]

Actually, we will just ban or greatly increase the spam score of anything coming from these NAT pools just like we do today with dialup and consumer broadband IP pools today. People with real servers will continue to have dedicated IP addresses that aren't behind these NAT pools and so we will judge them individually based on reputation (or lack thereof).

Re:Why not just use longer names?

[hairyfeet]

While what you say is true, what you and the other "just switch to IPV6 already" folks seem to be missing out on is if everyone was to switch at noon tomorrow in all likelihood you would be looking at MASSIVE outages, which would go on for weeks if not months. Why? Multiple reasons:

One, thanks to offshoring IT has been a dying field for quite awhile now, with fewer and fewer new blood coming in. What that means is in the flyover states you have most if not all the backbones being run by old guys who haven't kept up on the tech, and from the ones I've talked to most are looking to get out of IT if at all possible. That means the experience just isn't there, it isn't gonna be there, and many will take early retirement or just get out rather than deal with the IPV6 mess. That in turn means things that take minutes to fix in IPV4 will take days in IPV6 simply because nobody knows how to use the new tools.

Two: Infrastructure. There is a hell of a lot of VERY expensive equipment out there that either cannot be upgraded to IPV4, or could be but is no longer "supported" by the OEM, which means a MASSIVE amount of money will have to be spent in a dead economy. Now considering these cableco/teleco duopoly sure as hell ain't gonna take a CEO pay cut, that either means pay for it by gouging the customers even deeper, which in most flyover areas Internet usage is declining thanks to price gouging, or make it up by screwing the workers even harder, which results in number one above. Then add in the fact a good 90%+ of the routers and firewalls and other network devices in consumer homes WILL NOT support IPV6, and in fact most of the routers sold today STILL DON'T support IPv6 and the ones that do are triple price compared to the others, means you are talking MASSIVE amount of eWaste is about to be hitting the environment. You are talking truckloads of routers, modems, all having to be shitcanned. Again this will raise cost that the consumer WILL get stuck with in a dead economy.

So you see, there is a damned good reason that they are gonna string along IPV4 for every last second they can. They will do so because it is gonna be a massive clusterfuck when the switchover comes, with complaining customers because NOTHING in their house works, no IT guys with experience enough to fix even the simplest of problems, and warehouses worth of gear, both dirt cheap and ridiculously expensive, all having to be taken straight to the dump. Frankly it is NOT gonna be pretty, not at all.