On 2012-10-19 17:38:16 -0700, Steve Atkins wrote:
On Oct 19, 2012, at 5:25 PM, Dave Warren <lists(_at_)hireahit(_dot_)com>
wrote:
I'm less worried about those that lie outright than those that just
don't care either by not bothering to specify a policy at all
(unless it becomes mandatory somehow), or have more granularity than
can be clearly specified in a single policy.
For example, their policy might be to allocate at the /64 level, but
unless they also prohibit customers from obtaining more than one
/64...
The ability for customers to obtain more than one IPv4 /32 hasn't been
too complex an issue for blacklist operators to deal with. Any
blacklist operator who's successfully running an IPv4 blacklist can
surely come up with reasonable (or unreasonable, I won't judge…)
policies for IPv6.
The only relevant difference between v4 and v6 DNS based blacklisting
is that the ability to easily hop around *within* your /64 makes it
possible (easy) to blow the cache of a traditional caching DNS
resolver if you do naive "look up a record based on the IPv6 address".
A simple (maybe naive) idea to reduce cache poisoning would be to do
some kind of greylisting before doing the lookup: If you haven't seen
the address before, simply return a temporary error. If you have seen
it (within some time window), do the lookup.
Is there a reason why a legitimate MTA (talking to MXs, not submission
servers) would want to hop around in its net?
* IPv6 privacy extensions might be turned on by default and the admin
might not bother to turn them off, but I think they are too slow to
prevent delivery (although it will slow down most mails)
* An admin of an MTA serving many customers might want to use a
different IP address for each customer. But from the outside that
would just look like one MTA per customer, not a single MTA hopping
around
That doesn't affect the viability of source address based
blacklisting. It doesn't affect the viability of distributing that
data as DNS zone files (they suck for both v4 and v6, but they're
usable).
There are many more IPv6 addresses and even /64 nets than IPv4
addresses. It's theoretically possible to ship around a zone file with
/all/ IPv4 addresses (that would be less than 100GB). This isn't remotely
possible for IPv6 space. It might be possible for allocated /64 nets
depending on how they are allocated (if every cell phone gets a /48 ...).
If you go down to the /128 level, a spammer doing the hopping maneuvre
could blow up your zone file beyond any reasonable limit.
And it doesn't affect the viability of using DNS as the
communication channel between an MX and a local authoritative
blacklist server.
[...]
Right.
hp
--
_ | Peter J. Holzer | Der eigene Verstand bleibt gefühlt messer-
|_|_) | Sysadmin WSR | scharf. Aber die restliche Welt blickt's
| | | hjp(_at_)hjp(_dot_)at | immer weniger.
__/ | http://www.hjp.at/ | -- Matthias Kohrs in desd
signature.asc
Description: Digital signature
_______________________________________________
Asrg mailing list
Asrg(_at_)irtf(_dot_)org
http://www.irtf.org/mailman/listinfo/asrg