On 1/18/2011 3:45 PM, John Leslie wrote:
Douglas Otis<dotis(_at_)mail-abuse(_dot_)org> wrote:
On 1/18/11 7:46 AM, John Levine wrote:
https://datatracker.ietf.org/doc/draft-irtf-asrg-bcp-blacklists/
C. This draft continues the delusion of IP address listings for IPv6.
An important feature of IPv6 is the ability to rapidly renumber. Any
scheme that attempts to apply policy against IPv6 addresses removes this
important feature.
I'm afraid Doug is a bit in the rough here: most of us seem hell-bent
on _making_ IPv6 DNSBLs work.
(I do, however, share Doug's doubt that we'll succeed.)
This draft should caution against assumptions that suggest IPv4
practices can be extended for use with IPv6!
+1
(I didn't stumble upon any exactly contrary statement; but I think we
need an explicit explanation that IPv6 DNSBLs are a work-in-progress at
best, and this documents cannot make recommendations specific to IPv6.)
This is suggestive of a disclaimer to that effect up in the introduction.
I'm, however, hesitant in doing so. My reasoning is as follows:
a) If IPv6 DNSBLs are impractical as some suggest, no useful ones will
exist, the issue is moot, and no disclaimers are necessary.
b) If IPv6 DNSBLs are practical, then most of the policies are entirely
IPvX neutral (and are in fact extensible to non-DNSBLs at that), and a
disclaimer of that type would unnecessarily deprecate the useful
policies that _should_ still apply to IPv6.
c) If IPv6 DNSBLs are practical, but some of the policies don't make
technical sense, again the issue is moot, and no disclaimers are
necessary. Eg: rescan intervals: there's nothing that implies that
rescans are necessary. Hence, comments about rescanning of IPv6 entries
being impractical or impossible doesn't invalidate a "minimum rescan
interval" policy. If you can't rescan, then, the minimum rescan
interval policy is moot - by not rescanning at all, you still meet the BCP.
So, I don't see a hard conflict nor a necessity for such a disclaimer -
at least not a blanket one. Is there any MUST/SHOULD that _cannot_ be
met by a plausible IPv6 DNSBL implementation and needs a specific
disclaimer?
Other than that, I stumbled upon some of the MUSTard.
In general, we cannot enforce any behavior on list maintainers.
No, but we can encourage, and note/discourage what behaviours cause
problems in the real world.
Specifically, the "MUST NOT charge" in Section 2.5 is inappropriate.
DNSBLs that do not charge for access will necessarily need to recover
costs for manual actions that exceed de-minimis, or simply not do them.
There are DNSBLs that do not charge for access and do not charge for
manual actions. In fact, there's only one DNSBL that I know of that
still imposes financial costs surrounding delistings. It ain't SORBS...
Michelle _herself_ suggested "MUST NOT".
But charging for removals demonstrably causes problems, such as people
who refuse to bother with perhaps mistaken DNSBL listings because they
view it as extortion. Thus increasing the FP rate and impairing the
accuracy for everyone else.
Not to mention the harm to the reputation of the mechanism as a whole.
A strong statement that this isn't acceptable behaviour can do nothing
but good.
A strong "SHOULD NOT charge" is appropriate.
We could probably even get away with a "MUST NOT use" such DNSBLs
in that paragraph, although personally I'd prefer "SHOULD NOT charge"
and "SHOULD NOT use".
The goal of the BCP is to strongly encourage the best practises on the
DNSBL admin side, but at the same time recognize that receivers can do
anything they feel like as long as they know what they're doing.
IOW: a receiver can be in compliance even while using a DNSBL that's out
of compliance. Splitting between strong prohibition aimed at DNSBL
admins and mild discouragement aimed at receivers was quite deliberate
here.
Given that the "MUST NOT" only puts one known DNSBL out of compliance
that I'm aware of, I'm comfortable with it.
In Section 2.2.2, the "MUST NOT use..." such that removal requests
would be blocked is a bit strong for my taste. DDoS attacks are very
real, and defensive action _is_ needed from time to time. I think a
strong SHOULD NOT is appropriate, and I'd suggest adding text to the
effect that the website "SHOULD list short-lived alternatives"
whenever the usual removal-request path may be blocked.
Remember that DDoS attacks are generally temporary, and there's nothing
in the BCP that precludes changing the removal request process if/when
it becomes necessary - see section 3.2.
The section is meant to mean that the DNSBL is privately contactable and
not subject to the obvious screwup that the listee cannot contact the
lister due to the listing or other routine spam filtering, not that it
cannot be changed as circumstances necessitate.
In Section 3.4, the "MUST NOT list the entire Internet" is a bit
strong as well. While I think you have given plenty of suggested
alternatives to this, folks _do_ paint themselves into corners where
such a doomsday-weapon becomes needed. (Listing the entire Internet
_does_ mean they're outside the specification we're writing; but it
comes across as an attempt to control a behavior we can't control.
Perhaps we could suggest alternatives, not use the MUSTard, and say
that listing the entire Internet puts a DNSBL list out of conformance
with this set of practices.)
Isn't that exactly what the section means? Besides, heretofore, any
DNSBL utilizing such a doomsday weapon was heralding their own doom -
compliance becomes moot.
We have to really really _really_ discourage the practise so that
receivers will know that listing-world is something they should not need
to worry about. But in the end, a DNSBL having to resort to it ain't
going to care about compliance, and some of the provisioning
recommendations are about making sure that list-the-world scenarios are
not necessary.
Whatever, we should make sure that language about testing for
list-the-entire-Internet SHOULD be done is found within this Section.
It's the next section ... isn't that enough?
Overall, very good work!
Thanks!
_______________________________________________
Asrg mailing list
Asrg(_at_)irtf(_dot_)org
http://www.irtf.org/mailman/listinfo/asrg