ietf-asrg
[Top] [All Lists]

Re: [Asrg] New draft draft-irtf-asrg-bcp-blacklists-01.txt

2008-03-28 15:23:20
On 27-Mar-08, at 5:05 PM, Douglas Otis wrote:

On Mar 26, 2008, at 8:18 AM, Matt Sergeant wrote:

OK, so let me just clarify this - when you are listing a netblock
(and communicating with the owner or whatever you do), you NEVER
periodically re-check that netblock to make sure it hasn't changed
hands or gone quiet or anything? It's just listed permanently until
the heat death of the universe?
[snip]

Or is it temporary after all?

There is no pre-ordained maximums in terms of time (or CIDRs), as
suggested by this draft.

I'll take that as a "yes, it can be listed permanently until the heat  
death of the universe", reading between your dancing around the  
question. But see below for further input.

This draft shifts resolving abuse to individual senders and third-
party blocking lists, and away from network providers.

Utter tripe. It does no such thing. The draft makes no assumptions  
about the contents of the DNSBL, nor the listing criteria. It only  
asks that these things be clear and documented.

And if you have reason to remove the netblock, do you not do so
promptly? Are you holding the owner hostage for some particular
purpose?

How many legal fees will be expended by black-hole list operators
arguing over whether blocking removal should be automatic on a per IP
address basis in so many days, or that all IP addresses may not be
handled separately as a result of this draft's recommendations.  This
draft appears to be part of an ongoing effort to declare network
providers innocent of abuse sourced from their networks.  On the
contrary, only network providers are able to know the entity
involved.  As a result, _only_ network providers are able to be
effective at curbing abuse, and as such, must be held responsible when
they fail to act in curbing abuse.

OK, clearly we do need a clafification of what a "Listing" may  
consist of. The draft is not meant to suggest that listing == 1 IP  
address. A listing could just mean one entry in your database, with  
whatever mapping that implies to entries in your DNSBL.

The BCP of listings being temporary is to prevent situations like  
SPEWS (and clearly MAPS/Trends too according to other replies on this  
thread) abusive acts of keeping IPs/Ranges/ASNs/whatever listed long  
after the abuse has stopped. Simple as that.

Justifying a listing and de-listing policy should consider all
factors involved.  This draft concludes de-listing interval of 180
days is sensible without a basis to support the claim.

You've beat this drum before Doug. Please suggest a different figure
with justification for YOUR figure. The 180 days figure is a maximum
period which we suggest you list between doing a re-check on your
listing criteria. It does NOT mean you have to remove the entry
after 180 days, simply that you update the listing within that
timeframe as IPs do change hands and change purposes.

This misses points made about the roles network providers MUST play.
When abuse is resolved to the AS, the concern of "changing hands" is
completely misplaced.

Not really. Just a confusion about what an entry in the DNSBL means.  
If the entry is an ASN (even if the DNSBL lists IPs ultimately) then  
you still need to periodically check that ASN for continued abuse. If  
the abuse stops, delist it.

Despite all of this, these items are SHOULDs so that if your DNSBL
doesn't meet these criteria it is still ok by the BCP.

This still assumes blocking is always based upon the IP address and
not the AS.  This is wrong.

It doesn't assume that. But clearly clarification is required.

Besides, automatic delisting can be implemented with human
intervention- notify your administrators that a range is about to be
delisted and should therefore be re-checked for it's listing
criteria, and the
expiration date moved back if required.

Did you say a range of IP addresses?

See above - we need to clarify what an entry/listing is.

Shouldn't the draft indicate how
to determine the boundaries separating different network providers?

Way out of scope.

Should this draft dare to discuss the detection of spoofed BGP
announcements?

Umm, no. Way out of scope.

As a separate matter, should this draft mention the recognition of
RFC3464 in conjunction with content removal?

Not even slightly near being in scope.

Matt.

______________________________________________________________________
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email 
______________________________________________________________________
_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/asrg

<Prev in Thread] Current Thread [Next in Thread>