Re: Last Call: draft-irtf-asrg-dnsbl (DNS Blacklists and Whitelists)

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

 




On Nov 10, 2008, at 7:18 AM, Keith Moore wrote:

John Levine wrote:

As I said a few messages up in this string, although the structure of IPv4 DNSxLs has long since been cast in concrete, IPv6 DNSxLs aren't that mature yet and one of my goals was to make them interoperate equally well so, for example, if you find you're using cruddy ones you can easily switch to better ones.

I suspect it will be very difficult to make IPv6 DNSxLs work anywhere nearly as well as IPv4 DNSxLs, because in IPv6 it is fairly easy to use a different address for every SMTP conversation.

Agreed. One might hope that the future will use DKIM domains and "on- behalf-of" tuples as an alternative to that of an IP address blocking list. Ideally, the "on-behalf-of" would be an opaque value assigned by the provider, that is changed whenever a problem is corrected. This would eliminate the need for coordination between those that run reputation services and the senders. Those that abuse this freedom would be at risk of finding their entire domain blocked instead. The problem that needs solved is how to block compromised systems, more than blocking individuals. Frankly, it would be best not to have any personably identifiable values used.

Unfortunately, being able to detect misbehavior at a sufficient level to safely conclude whether an outbound MTA is poorly managed requires rather extensive infrastructure. This infrastructure is often several times larger than the typical infrastructure of a client being protected. These services address the problem of scaling email defenses. Assessments are fairly difficult when the MTA being judged has little volume, since even an occasional misidentification of NDN as spam might create a profile fairly similar to those created by bot- nets. Bot-nets represent a sizable portion of today's spam sources.

IMHO, the goal of the black-hole list should be to inform ISPs and have them remove bad actors from their network and hopefully to encourage them to better monitor their own traffic. ISPs will not agree with this. Even the largest decoy infrastructure sees only a tiny fraction of the overall traffic. A desire to rapidly block any IP address that appears to be actively spamming provides bad actors a simple way to locate decoys and render the system less effective. While there are ways to deal with this problem, it both increases the infrastructure required, and the duration of a listing applied to problematic addresses.

While there may be some concern that DNSxLs use A records as a flag, normally these records are limited to an address range of 127.255.255.255 - 127.0.0.2 (only 23 bits worth of data). It seems unlikely that the use of these IP addresses will lead to any problem. The reason for suggesting that the document be published as Informational has to do with there not being _any_ real experience yet in attempting to block IPv6 addresses. Routers will only be handling a faction of the total IP address space that IPv6 makes available. IPv6 DNSxL entries will not represent the same number of routes managed by routers. This would suggest that entire networks are to be blocked whenever a significant level of abuse is detected that warrants blocking. This would be a rather bunt tool.

There are a few points that this draft attempts to answer in a reasonable way. The software used by the DNS servers is not going to change to support the IPv6 address space. The servers will continue in the same fashion as before. Instead of a query address of 127.0.0.2, this draft suggest the value ::FFFF:7F00:2 to test the existence of the list. Until there is some greater experience in handling IPv6 address space, do not get ahead of the problem by concluding how this service is to resolve the practical challenges ahead. When a network handles a mixture of legitimate and abusive traffic, it may be impossible to cope with the volume of tracking data that will be required.

After all, evidence MUST BE retained for everything blocked to squelch erroneous customer complaints and the occasional law suit threat. While SANs are getting bigger, to scale these systems for tracking addresses within an IPv6 network is unlikely to be economically all that practical. This might be wrong, but it should be less expensive for reputation services to use DKIM domains and an opaque "on-behalf- of" value instead. DKIM would also create less danger with respect to collateral blocking. MTAs may need to be equipped with crypto hardware to deal with foo signature abuse. At least MTAs should be able to rate limit any IP address sending foo signatures.

-Doug




_______________________________________________

Ietf@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf

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