[acm-tf] Abuse Contact Information - Policy Proposal

On 18/Oct/11 13:21, Denis Walker wrote:
> On 17/10/11:43 8:29 PM, Alessandro Vesely wrote:
>> 
>>    The "abuse-c:" reference to an abuse handler should make use of
>>    the hierarchical nature of the resource data, so that a given
>>    abuse team retains its relationship with the relevant resources
>>    until a different "abuse-c:" reference explicitly overrides it for
>>    a given assignment.  Such transfers of abuse handling to less
>>    specific assignments are not meant to be automated, yet they
>>    minimize the workload on resource holders and facilitate good
>>    database design.
> 
> Brian mentioned the issue of responsibility. With the IRT object we
> assumed responsibility in a network hierarchy as recorded in the RIPE
> Database? So for any IP address an IRT object referenced by the most
> specific encompassing object held the relevant contact details (if any
> IRT object was found). Can you assume the same responsibility structure
> for abuse handling?

Well, that's the idea the text is meant to convey.

> Will an LIR, by default, be responsible for all abuse complaints
> for their (PA assignments and sub allocations) customers who don't
> manage it themselves? That is the practical reality of using this
> network hierarchy in this way, especially if you make it mandatory
> that an "abuse-c:" is referenced at some point in all hierarchies.

Yes, as soon as a LIR sets an abuse-c, it becomes "responsible".  As
far as the proposal goes, it can just set, say, noreply at LIR and boast
of being fully compliant with it.  BitBucket at LIR would be a slightly
better choice.  Piping complaints to a tool that is able to extract
some information, e.g. the IP numbers of both the spammer and the
complainant, allows to collect interesting data.  I would call the
latter a passably decent solution, assuming such data will be used.

Obviously, running a full blown abuse team involves costs that
competitive providers may want to shun.

> You said above "a different abuse-c: reference explicitly overrides it
> for a given assignment". This is the case now for IRT. For abuse
> handling do you want this to 'override' or 'take precedence over' a less
> specific reference?

I don't have direct experience of IRTs, but my understanding is that
network providers are much more in touch with one another than mailbox
providers --except possibly for huge ones.  Hence, although mnt-irt
and abuse-c are formally similar, trust may be more of a problem for
the latter than the former.

> The Abuse Finder tool should be promoted as the preferred way for
> anyone to find abuse contact details in the RIPE Database.

Yes.

> There is a web form for 'the public' to use for one off enquires
> and we have an API for 'power users' to use for doing many queries.
> The logic of the Abuse Finder can be made to do whatever you want.
> So if you want the 'override' option in the hierarchical lookups we
> can stop searching at the first encompassing object with an 
> "abuse-c:". If you want the 'take precedence over' option we can 
> continue up the hierarchy until we get to an allocation and select
> all "abuse-c:" attributes found.

Yes.

For the public, the abuse handler does not produce results widely
different from regular web-whois queries, albeit it "knows" the
history of how abuse contacts came into being and may thus help
inexperienced users.

For the power users, which I imagine consist of scripts running on
various MTAs with minimal user intervention, a single target address
should be the default behavior.  An interesting idea is described in
http://tools.ietf.org/html/draft-newton-et-al-weirds-rir-query

For both uses, the major difficulty is to work out what RIR should be
queried and take into account any different semantics in the response.

> As the Abuse Finder is a tool that interprets raw whois queries we can
> structure the output any way you want. So with a precedence option we
> could clearly show which addresses should be used first for any
> complaint. But also list alternatives to use if the primary option does
> not respond.

Good point.  For feedback-loop, which seems to be the only documented
practice right now, any human interaction is done beforehand, and no
response is expected after filing a complaint.  On the opposite, some
acknowledgment from an abuse-c can be useful in some cases.

Abuse reporters may want to keep track of the reports they send, and
estimate the reactions of abuse teams.  In case they decide they don't
trust a team, they will want to use the alternative addresses only.

By always giving a list of addresses, we may encourage reporters to
send reports to all of them.  I'd try to avoid such situation, see
http://www.rhyolite.com/anti-spam/you-might-be.html#spam-fighter-3

If the reporters have to query the (first, second, ...) alternative
contact, the query-log can be used to gauge the average trust that an
abuse team scores --we'd better use authenticated queries if we want
reliable data.  IOW, we may force power users to evaluate abuse teams
by providing a tool taking suitable parameters.

> There was some talk earlier about best practices. If you have (or write)
> such a document this could be referenced in the Abuse Finder output.

I try and push for having these practices documented.  I trust we'll
get to know it when some reliable source publishes something relevant.

Conversely, by publishing the experience we'll obtain with the tool,
we can stimulate interest in standardizing such practices.

> I know the TF was set up to decide where to 'put' abuse contact details.
> But in order to finalise where to put the data, some thought must also
> be given into how the data will be found and what interpretation can be
> applied to the data.
> 
> Maybe the answers to these questions are obvious. But at least you will
> have thought about it and have a clear answer ready if these questions
> are asked when you present your policy to the community.

I don't think they're obvious at all.  In particular, I don't know how
users perceive the responsibility of network providers.  Polls come to
mind, as a way of asking.  What if we engage the Anti-Abuse attendants
in refining a questionnaire, Tuesday afternoon?  We might propose them
a set of basic questions, such as

* Are ISPs responsible for spam sent by their customers?

* Spammer supporters are less/equally/more culpable than spammers?

* Should ISPs terminate support to a customer as soon as they become
  aware that it is a spammer?

* How should ISPs become aware that a customer of theirs is a spammer?

* ...

>>> 1.) Which one would be the correct domain-name?
>> 
> 
> You are suggesting adding a mandatory attribute, but are you sure all
> resource holders will have valid data to put in this mandatory
> attribute? Your assumption here is that all IP and AS resource holders
> have a domain name. Is that true?

Hm... most people has a domain name nowadays, it would be interesting
to allow "none" (rather than null) for resource holders that actually
don't have one.  Do they need an abuse-c in that case?

It shouldn't be mandatory, since it's the domain owner's interest to
set it.