On Mar 30, 2013, at 11:26 PM, Christian Huitema
<huitema(_at_)microsoft(_dot_)com> wrote:
IPv6 makes publishing IP address reputations impractical. Since IP address
reputation has been a primary method for identifying abusive sources with
IPv4, imposing ineffective and flaky > replacement strategies has an effect
of deterring IPv6 use.
In practice, the /64 prefix of the IPv6 address has very much the same
"administrative" properties as the /32 value of the IPv4 address. It should
be fairly straightforward to update a reputation system to manage the /64
prefixes of IPv6. This seems somewhat more practical than trying to change
the behavior of mail agent if their connectivity happens to use IPv6.
Dear Christian,
The announced prefix space currently represents more than 4 million times the
entire IPv4 address space. This means the /64 prefix space can not be
considered comparable to IPv4 address space. Go to
http://bgp.potaroo.net/v6/as2.0/ and look for Total address space advertised
(/64 equiv). The number of announced prefixes over /64s currently shows
18,206,079,529,779,202.
Much of the IPv4 has already had Reverse DNS PTR records traversed scanning for
hints about whether any specific address appears to represent dynamically
assigned access. This guesswork allows about 1/3 of the IPv4 space to be
ignored by blocking them from sending public (port 25) SMTP messages.
Reverse DNS PTR records offers a costly means to differentiate residential and
non-residential access when done on a realtime basis. A significant benefit of
a comprehensive reputation mapping of the entire IPv4 address space is that any
reverse naming exceptions are incorporated into the reputation values which
also eliminates dependence on reverse DNS performance.
In IPv6, there can not be any pre-mapping. This places reverse PTR review at
the mercy of the even more broken IPv6 reverse zone provisioning. Any
mis-configuration of the reverse name space, which is common for IPv4 from
residential systems, greatly increases the resources consumed by the growing
proportion of sessions emitted by compromised systems. Few expect reverse PTRs
and hostnames to match, but to offer names not hinting at being for a dynamic
assignment. Greatly increased delays caused by DNS misconfiguration, along
with a need to handle a larger number of sessions, will make testing reverse
PTR records highly resource prohibitive and problematic for IPv6.
In the end, Reverse PTRs can be assigned any name and thus can not serve as a
basis to assess accountability. Once a conclusion is reached that only
AUTHENTICATED initiating domains offer a means to fairly establish a basis for
acceptance, use of reverse PTR records becomes far far less attractive. The
ability to authenticate forward domains initiating messages improves security
and is better suited for a future of more mobile and dynamic infrastructure.
Many email domains will find themselves obligated to authorize IPv4 outbound
servers using SPF. Return-Path mail parameters locating authorization reduces
backscatter abuse at the cost of reduced delivery integrity. However this
parameter's relationship over mail's entire path is too fragile to serve as a
basis for acceptance. Since DKIM allows any message to be relayed by design,
it can not offer a means to mitigate abuse when any marginal domain must be
accepted, as for domains considered too big to block.
In addition, problems related to DKIM header field spoofing permitted when
signatures are still considered valid, along with a growing range of dangerous
email content that references compromised i-frames, makes responding to new
threats a growing problem. IPv6 pushes this problem further over the edge
without the introduction of the initiating domains having been authenticated.
IPv6 addresses can not serve this function, and there is progress being made in
respect to use of DANE and the like.
Regards,
Douglas Otis