Many service providers, network providers, and corporations plan to launch additional IPv6 networks and on-line services during this year’s World IPv6 Day, which falls on June 6th, 2012.
IPv6 promises to enable deployment of a seemingly endless number of networks and devices. IPv6 provides 128-bits of addressable space, while IPv4 only provides 32-bits. This means that both home users and corporations will have control over publicly addressable IPv6 networks, each of which can be orders of magnitude larger than the entire IPv4 space.
There are potential pitfalls with the much greater address space in IPv6 as compared to the address space available with IPv4. In SMTP in particular, many presently deployed anti-abuse reputation tracking systems would be overwhelmed as the same reputation tracking methods that worked on IPv4 sending addresses are no longer feasible with IPv6 IP addresses. Long term reputation tracking, IP blacklisting, and traffic shaping have all relied on the ability to track the quality of traffic emanating from a tangible number of IPv4 IP addresses associated with message-sending MTA clients and spammer controlled botnet clients alike. Due to the much larger address space in IPv6, brute force reputation tracking of individual IPv6 addresses associated with client behavior presents data storage and processing challenges.
Cloudmark has published a white paper on the best practices associated with handling protocol-level SMTP anti-abuse protection in an IPv6 network.
Rather than searching for individual bad actors, of which there will be too many to track at the single IP address level, Cloudmark is proposing a different approach: one where legitimate senders must first prove themselves eligible to be tracked based on several possible authentication methods.
The proposed methodology takes advantage of the fact that there will be far fewer legitimate senders versus bad senders. Presented below are general features of this approach:
- By default, all unknown senders are assigned to a default class of service (CoS) that permits access to a very narrow slice of a shared resource pool within a receiving MTA.
- This prevents bad actors from impacting the messaging system even if all messages were classified as spam.
- Senders with an established identity graduate to a per-identity CoS and the system will track the sender’s behavior.
- Initially, the per-identity CoS will have low limits on throughput.
- With continued good behavior, the limits are increased quickly.
- In the steady state, a good sender’s limits will be proportional to the expected sending volumes while bad senders’ limits will remain very low.
- The ability to establish sender identity is based on the ability to authenticate sender identity via one of the following methods: Sender Policy Framework (SPF) or DomainKeys Identified Mail (DKIM).
- Both of these domain-based identity methods can be leveraged to develop knowledge of sending SMTP client IP ranges over time.
- In cases where a domain-based identity cannot be established, the use of “known sender lists” or lookups in WHOIS, or similar protocols, such as those being developed in the IETF’s WEIRDS working group can yield IP address ranges that can be attributed to specific legitimate messaging systems.
This approach evolves beyond the current IP address blacklisting model often used in IPv4 networks. Rather than attempting to continue tracking reputation of bad senders, of which there are potentially vast quantities, this method seeks to track reputation of the comparatively small number of legitimate senders.
Additionally, we’ve already received feedback from customers who have enabled IPv6 that some of their first messages were spam. Jason Livingood with Comcast noted the following, “We are proud to have been one of the first large email domains to enable IPv6 for inbound email, and to be on the leading edge of native IPv6 deployment more generally. While our first message after going live was spam, Cloudmark immediately blocked it.”
Additional information on this topic is included in a white paper, which can be found at: http://www.cloudmark.com/en/whitepapers/smtp-abuse-prevention-in-ipv6-networks.
