Re: Sufficient email authentication requirements for IPv6

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




On Mar 30, 2013, at 11:26 PM, Christian Huitema <huitema@xxxxxxxxxxxxx> 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

[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]