[anti-abuse-wg] 2010-08 New Policy Proposal (Abuse contact information)

Dear Colleagues,

I have followed the whole of this thread. There have been several
questions put to the RIPE NCC about what we may or may not be able to
do. Also many technical and implementation details have been touched on.
I think it may be helpful if I try to address some of these issues, in
no particular order. Apologies for the length of the email.

There have been many assumption that this issue only concerns members
who have an LIR Portal account. This is not the case for end user
assignments. Any solution has to cover all resource Holders who may not
have access to announcements, tools or features of the LIR Portal. There
have also been a few references to making judgements based on the
resource Holder using a ticketing system. Again many end users with a
single PI prefix may be unlikely to use ticketing systems, but may be
very active to resolve any complaints about their address space.

The RIPE NCC puts a lot of effort into cooperation with Law Enforcement
Agencies (LEA) and other official organisations. Many LEAs in the RIPE
region and also worldwide have specialist cyber crime units who are
becoming very knowledgeable about Internet resource policies and
procedures. I don't think these are the people you need to worry about
as far as getting information out about new policies. In many cases it
is some of the resource Holders who maintain data that has not changed
for years that need advising of new policies. Also the public are
increasingly finding the RIPE Database and these people will still grab
every email address they see and do a blanket mailing to all addresses.
Even if the information was clear they are usually angry and still think
sending more emails is good.

The RIPE NCC only knows the IP addresses where queries to the RIPE
Database come from and what they queried for. We have no information
about what type of network it is (fixed, dynamic or whatever) so there
is no point trying to guess any numbers. We do know we average 80
queries per second and the IP addresses making the queries are global,
not only RIPE region addresses. Other than that we can say nothing about
who is making these queries or why.

There is an assumption that making a policy will force resource Holders
to change data in a short period of time (2 or 3 years). There have been
many policy, business rule, security and syntax changes over the last 10
years. Some of the earliest are still not complete. We dropped reference
by name in 2001. Some objects still reference the dummy NIC Handles we
created to replace the person names. Many objects created in 2004/5 for
the Early Registration Transfer were 'locked' with auto-generated MNTNER
objects and are still locked. Last year we added MNTNER objects to
un-maintained DOMAIN objects. We had to create dummy MNTNER objects for
some and they still reference the dummy maintainers. Resource Holder's
data does not change quickly. But that does not mean the operational
data is wrong or not used. It may be that the networks were set up many
years ago, everything still works fine and no one needs to change this data.

For the same reasons as above, making a mandatory reference to an IRT
object will not affect data that the resource Holder never changes. At
some point the RIPE NCC may have to auto generate dummy IRT objects with
an abuse-mailbox email address like <unread at ripe.net> to ensure all data
in the database complies with current syntax rules.

The RIPE NCC can not delete any information currently stored in
"remarks:" attributes. This is for the same reason the Abuse Finder tool
cannot return any information from "remarks:" and we cannot do any bulk
updates to transfer abuse contacts from remarks into IRT objects. We
cannot write software to 'understand' remarks. We don't even know what
language the remark may be in. Then we can't distinguish between:
remarks: use this address for spam reports helpdesk at lir.net
remarks: don't send abuse reports to helpdesk at lir.net use admin at lir.net
remarks: any complaints sent to helpdesk at lir.net will be ignored

At some point the RIPE NCC can auto generate IRT objects and add the
email address from existing "abuse-mailbox:" attributes in other
objects. Then make the appropriate references to this IRT object and
delete the old "abuse-mailbox:" attributes. No data will be lost doing
this and the new IRT object will cover the same address space covered by
the old "abuse-mailbox:" attribute. Then syntax changes can be applied
to only allow "abuse-mailbox:" attribute in IRT object.

It has been suggested the RIPE NCC can regularly check/verify abuse
contact email addresses. It is very easy to set a filter on incoming
emails to allow any mail @ripe.net to pass and block all others. So the
fact that a resource Holder receives our email is no guarantee they will
receive yours.

For those not familiar with the database structure, note that address
space is hierarchical. There are just over 3 million INETNUM objects for
PA assignments. These all relate to the allocations made to about 7000
members. Each member may have several allocations. From the point of
view of administrative work load, adding IRT references to the few
thousand members allocation objects achieves the same result as adding a
reference to each of the 3 million objects, but is much easier to
manage. The default query for any address already searches up the
hierarchy for the IRT reference and this object is returned as part of
the query result. Queries returning IRT objects are not limited in any
way. If this is to be mandatory, any update to one of the INETNUM
objects lower down in the hierarchy can be rejected if the allocation
object does not have the mandatory reference. If you want it to be
advisory, the update can generate warnings if the reference is not
there. The overall result is the same as having 3 million references,
but the work required to implement and maintain is much less.

Calculations of address space coverage by IRT objects is complex because
of the hierarchical nature. It is not just a count of the number of
INET(6)NUM objects that it is referenced in directly. Those objects have
more specifics which may or may not fully utilise that address range.
The last time we attempted this calculation was about two years ago.
Then there were about 100 IRT objects, not all of which contained the
optional "abuse-mailbox:" attribute. The address space covered by those
IRT objects with an "abuse-mailbox:" attribute was about 2% of the total
assigned address space from members allocations (PA) and direct end user
assignments (PI).

If abuse emails are located in one place the RIPE NCC Abuse Finder tool
can do direct database lookups at SQL level, bypassing the normal query
interface. This is much faster and provides real time responses. With a
published API you can write your own scripts to use this tool.
Downloadable lists are yesterdays data, but we can look at providing
such lists if required.

Regards
Denis Walker
Business Analyst
RIPE NCC Database Group