Carrier Trick To Save IPv4 Could Help Spammers 124
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."
Trivial if you want to go the extra mile (Score:4, Interesting)
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).
Not just spammers (Score:5, Interesting)
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:Figures (Score:5, Interesting)
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 (Score:5, Interesting)
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.
Comment removed (Score:4, Interesting)