Federal organizations are aiming for September 2012 mandate to IPv6-enable their Internet perimeter applications. This not only includes IPv6-enabling web servers, but also IPv6-enabling e-mail servers. Therefore e-mail servers would be allowing inbound SMTP (TCP port 25) connections over IPv4 and IPv6. However, most e-mail content filtering companies only have defensive capabilities for IPv4. Do organizations really want to allow IPv6 e-mail if it is less secure than IPv4?
How Block Lists Work
DNS-based BlackLists (DNSBLs), historically called Realtime Blackhole List (RBLs), are lists of public IP addresses that are performing malicious activities like spamming. These lists are distributed via DNS (RBLs were distributed with BGP). These lists can be used by Message Transfer Agents (MTAs) to block e-mail from the sender's IP addresses that appear on the list. This helps cut down on the amount of spam that an organization receives. Over time there have been other adaptations of "Reputation Lists" of IP addresses that are used for hosting malware or are part of a botnet command and control infrastructure. These lists are used by various security appliances to help block malicious e-mail and web content.
Even though reputation filters are responsible for 80% or more of the blocked spam, these DNSBLs are not a fool-proof solution. For example, spammers change their source IP addresses rapidly to avoid getting on the list. There could be individual broadband Internet subscriber computers behind a Carrier Grade NAT (CGN)/Large Scale NAT (LSN) system infected with malware that are sourcing malicious e-mail messages. That infected subscriber's public address comes from the LSN public IP pool. We have also known for many years that reputation filters are not a long-term solution as more service providers deploy Large Scale NAT (LSN) systems.
Problem Statement
If you do not have an IPv6-capable DNSBLs or an IPv6-capable SPAM filter then you may not want to allow inbound Simple Mail Transfer Protocol (SMTP) over IPv6. You may not want to operate an IPv6-enabled network in a less secure manner than you do today with IPv4. We should strive to establish the same security protections for IPv6 as we use today for IPv4. Furthermore, we should be keenly aware of where we lack IPv6 feature parity and avoid enabling IPv6 when it creates a security exposure.
There is concern now that enabling inbound e-mail over IPv6 will give the spammers an advantage if the spam filters are not IPv6-capable. Although some organizations with IPv6-enabled e-mail servers have not witnessed large amounts of spam using IPv6, it does not mean that there isn't any spam over IPv6. There is in fact spam over IPv6, the question that we cannot answer accurately today is how much there is. The fear is that the spammers can change their tactics very rapidly and start using IPv6, which may not have all the defensive capabilities of our IPv4 e-mail servers.
RIPE published a report almost 2 years ago in an attempt to quantify the amount of "Spam over IPv6". This report showed that the amount of spam sent over IPv6 was proportionally less than the spam sent over IPv4. However, it did confirm that there is spam sent over IPv6 transport.
Many Internet Service Providers (ISPs) are wary of IPv6-enabling their e-mail servers and enabling inbound IPv6 e-mail without any protections. This IETF draft discusses this problem and prescribes a phased approach for service providers.
We are aware of one DNSBL that uses IPv6 (Virbl-project). Last year, the reputation filter service Spamhaus released their "IPv6 Blocklists Strategy Statement" but does not yet have any IPv6 capabilities in production. Other reputation services like Phishtank and Google Safe Browsing API do not have any IPv6 capabilities. Cisco Security Intelligence Operations (SIO) which is used by their IronPort appliances and Global Correlation for their IPSs is not IPv6-capable.
IPv6-Capable E-Mail Security Products
We are curious about what e-mail security products support IPv6. We can take a look at the Gartner MQ for e-mail security and see who the major players are in this market. The Gartner Magic Quadrant for Secure E-Mail Gateways (SEGs) (August 10, 2011) does mention that IPv6 is a feature that enterprises need. However, it does not discuss which vendor's solutions are IPv6-capable.
Cisco IronPort does now support IPv6 in their AsyncOS 7.6 which was just released. However, the Cisco ScanSafe system is not IPv6 capable.
Proofpoint issued a press release indicating that they have IPv6 support.
Barracuda's e-mail appliances, Microsoft Forefront Protection 2010 for Exchange Server (FPE), and Sophos do not seem to have any IPv6 capabilities.
Trend Micro has claimed that they have come up with a solution for spammers who use many unique IPv6 addresses to send unsolicited e-mails. In 2005 Trend Micro acquired Kelkea (which inherited the Dave Rand and Paul Vixie created Mail Abuse Prevention System (MAPS) (RFC 5782)). Trend Micro Anti-Spam Engine (TMASE) 7.0 Beta is supposed to have IPv6 capabilities. Trend Micro offers a nice page that lists a variety of mail systems and configuration guidance.
UTM devices like Fortinet's Fortigate are fully IPv6-capable. Their FortiMail system, which is a purpose-build appliance based system, says that it can perform greylisting for IPv6 addresses.
EdgeWave (Powered by Red Condor) Messaging Security Suite version 8.X has the ability to add an IPv6 address to the bounce suspension list. EdgeWave also published an article about the issues with IPv6 and e-mail filters.
CanIt-PRO by Roaring Penguin says that they are IPv6-enabled but they do not mention using IPv6 RBLs in their literature.
Open Source Solutions
There are a few popular open source solutions that many organizations use for filtering spam. SpamAssassin version 3.2.5 significantly improved its IPv6 support (the current version is 3.3.2). This was probably due to improvements in IPv6 support in Perl. SpamAssassin did have a bug when doing DNS lookups over IPv6 so you can disable that feature and perform DNS queries of IPv4-only. MailScanner, which leverages SpamAssassin, has IPv6 capabilities and can perform SMTP communications over IPv4 and IPv6. It has been mentioned on mailing lists that SpamCop plans to have IPv6 capability sometime soon.
Cloud-based Spam Services
Security as a Service (SecaaS) solutions are now very common and there have always been a variety of "cloud-based" e-mail filtering solutions available. The widely popular Google/Postini does not seem to support IPv6 today. However, there was a rumor that IPv6 would be supported in their next-generation system. We can check the Internet BGP routing tables and see that these cloud vendors are not yet advertising IPv6 prefixes. That is an indication that they are not IPv6-capable. Webroot and Postini are not IPv6 capable and are not advertising any IPv6 prefixes from their ASNs. Cloudmark's AS (AS19506) does announce a single IPv6 prefix. At the end of last year it was reported that Cloudmark now has IPv6 capabilities in their messaging servers.
There are new SecaaS services from many of the spam-filtering appliance-based vendors. These vendors realize the "cloud" trend and see evidence that more enterprises are moving toward SaaS solutions. This list includes: Symantec.cloud (formerly MessageLabs), Trend Micro Hosted Email Security (TMHES), Barracuda Email Security Service (BESS), Websense Email Security Gateway Anywhere (ESGA), McAfee (formerly MXLogic), Microsoft Forefront Online Protection for Exchange (FOPE), Proofpoint, SonicWALL. However, none of these seem to have any IPv6 capabilities.
Granularity of IPv6 RBLs
Granularity of DNSBLs and reputation filters are also a concern. Today, DNSBLs have 32-bit IPv4 addresses in their lists. However, what should the size of an IPv6 address be within a DNSBL? Some say that the full 128 bit IPv6 address should be listed in the DNSBL. One concern is that if there are many IPv6 addresses in the list that the list size would grow dramatically. Furthermore, an attacker could use many unique addresses within a /64 every couple of minutes to avoid detection. There are roughly 18 quintillion IPv6 addresses within a /64 prefix so that would give the attacker lots of addresses to source the attacks from. That could quickly fill up the DNSBL and possibly cause problems for the service. If the granularity of the DNSBL was set to a specific prefix size then there could be collateral damage by inadvertently blocking other hosts not even involved in the sending of e-mail. For example, if the granularity of the reputation filters was set at the /64 level, then other systems on the same segment as the attacker would be inadvertently blocked from sending e-mail. Section 2.4 of RFC 5782, " DNS Blacklists and Whitelists" shows how the 128-bit IPv6 address is formatted for the DNSBL.
Preventing Spoofed E-Mail
SMTP does not validate that the sender of an e-mail message is the legitimate mail server for that domain name. The IETF has developed solutions that help with the security of e-mail. These standards are: Sender ID, Sender Policy Framework (SPF) (RFC 4408), and Domain Keys Identified Mail (DKIM). These standards allow a domain administrator to specify the legitimate source addresses that e-mail should be coming from (using DNS record SPF, type 99). E-mail servers should reject messages from spoofed e-mail source addresses that are not on that domain's specified list. DKIM takes this approach further by using a digital signature to validate e-mail sources and secure the message header. SPF allows the sender to specify an IPv6 address range. IronPort and Proofpoint's solution are a few of the products that supports DKIM verification today and McAfee supports SPF. DKIM is also supported by Yahoo, Gmail, FastMail.FM, among others.
IPv6 White List Approach
Some experts have suggested that a better approach for IPv6 e-mail deployment is to create a white list of IPv6-enabled mail servers. Your mail servers will be configured to only allow e-mail from those known good sources of e-mail. Some large broadband ISPs are currently allowing IPv6-enable inbound e-mail. However, they set up filtering to allow IPv6 inbound e-mail only from individual IPv6-address basis. Since the deployment of IPv6-enabled e-mail servers is smaller than the potential size of the IPv6 addresses a spammer may use then this would be a more efficient method. This sounds similar to the "Google over IPv6" white list concept that we have heard about for years. In the long term, the administrative burden for this type of a white list grows as the worldwide deployment grows to the point that maintaining the white list becomes prohibitive.
Spam-Catching Algorithms
Spam filters are now very effective and can catch up to 99% of all spam. Fortunately, it is a good thing that spam systems do not completely rely on lists of IP addresses of known systems that are sourcing spam. There are a wide variety of other methods to detecting and preventing spam. Spam filters may matching on keywords using heuristic algorithms and rule-based filtering, use statistical or Bayesian filtering or looking for typical characteristics of fake e-mail. Spam filter systems may look for e-mails containing pharmaceutical terms, product names, blank subject lines, message subjects that are known to be malicious. These techniques are also not fool-proof and can have many false positives. End-users prefer to have an occasional spam message slip through than to have the "ham" get blocked by accident because it contained a bad keyword.
Other methods of preventing spam include authenticating and encrypting e-mail. Techniques such as S/MIME and PGP/OpenPGP (RFC 4880 & RFC 5581) or Cisco Registered Envelope Service (CRES) also help prevent against spam. E-mail servers can use Transport Layer Security (TLS) session-level encryption between themselves or SSL/TLS link encryption between domains. These techniques work regardless of the IP version used for the mail server connection.
Outbound E-mail
Organizations may not have as much of a problem allowing outbound IPv6 e-mail. Organizations may want their e-mail servers to be able to communicate with other mail servers that have IPv6-addresses for their MX records. Organizations should allow outbound POP, IMAP, and SMTP from their e-mail servers over IPv4 or IPv6 transport. This way, they are prepared as the rest of the world starts to migration to IPv6.
Conclusions
We may never see the end of spam, and the introduction of IPv6 will not make spam a thing of the past. In fact, there is potential that the introduction of IPv6 may make spam more prolific for companies with IPv6-enabled e-mail servers that rely on DNSBLs that don't have any IPv6 capabilities. On World IPv6 Day (June 8, 2011), when some organizations IPv6-enabled their mail servers, they received their first IPv6 spam.
It is about time that organizations start to demand that IPv6 capabilities be included in the networking products they purchase. This IPv6 capability needs to be integrated far in advance of when it will really be needed. However, many vendors have failed to prioritized IPv6 in their list of committed features. Now, in 2012 Federal enterprises who are striving to meet their IPv6 mandate will not have the products they require. Let's hope that in 2012, e-mail filtering vendors realize that if they are developing Internet products and services they think about the Internet using both IP versions.
Scott