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