[AfriNIC-rpd] abuse contact information in whois database

Tue Apr 6 11:55:31 UTC 2010

Hello Policy Working Group,

my name is Tobias Knecht. I'm the CEO of abusix UG and I'm new here in
this group.

Nevertheless I wanna propose a new policy to you.
I have done a similar proposal for APNIC already
(http://www.apnic.net/policy/proposals/prop-079)

This proposal found common consensus on the last APNIC meeting and it
looks like as if will be implemented in this way, starting this year.

So please have a look at the proposal and feel free to ask or mention
your ideas or changes.

The proposal is based on the idea that the AfriNIC whois database is the
same as RIPE and APNIC are using. That means IRT-Objects and
abuse-mailbox attributes are already implemented and just need to be
used. That makes things easier and faster.

________________________________________________________________________

Proposal Name: Abuse contact information
________________________________________________________________________

Author:    Tobias Knecht
           <tk at abusix.org>

Version:   1

Date:      06 April 2010

1.  Introduction
----------------

This is a proposal to introduce a mandatory reference to IRT objects
in the inetnum, inet6num and aut-num objects in the AfriNIC Whois Database.
It provides a more accurate and efficient way for abuse reports to reach
the correct network contact.

2.  Summary of current problem
------------------------------

Network owners increasingly operate dedicated abuse
handling departments, distinct from the basic operations department.

More and more network owners and other institutions are also starting
to exchange data about abusive behavior with each other, to more quickly
allow networks to identify internal abuse, external abuse, and other
security problems.

Currently within the AfriNIC region, the growing amount of abuse reports
are sent to e-mail address specified in the e-mail field, as encouraged
on the AfriNIC website.[1] These addresses are used because the AfriNIC
Whois Database currently has no mandatory, specialised contact object
for abuse departments. Instead, all abuse reports are sent to contact
that is has broader responsibilities or different responsibilities.

3.  Situation in other RIRs
---------------------------

APNIC:

    This policy proposal found consensus at APNIC 29 in Kuala Lumpur 	
    March 4th 2010. Further information about the APNIC policy proposal
    can be found at [2]

ARIN:

    An abuse-POC exists for Organizational ID identifiers.[3]

LACNIC:

    An abuse-c exists for aut-num, inetnum and inet6num objects.[4]

RIPE:

    An optional IRT (Incident Response Team) object can be linked to
    inetnum and inet6num objects.[5] If the current proposal is
    successful in the APNIC and AfriNIC region, the author plans to
    submit a similar proposal for the RIPE region.

4.  Details of the proposal
---------------------------

It is proposed that AfriNIC:

4.1 Institute a mandatory reference to an IRT object in inetnum,
    inet6num and aut-num objects.

    In terms of implementing a mandatory IRT reference, it is
    suggested that this be part of two, established actions:

    - The next time an organization attempts to update an existing
      inetnum, inet6num or aut-num object

    - When new inetnum, inet6num or aut-num objects are added to the
      database

4.2 Have a mandatory abuse-mailbox field in the IRT object.

4.3 Delete abuse-mailbox fields in all objects that do not define an
IRT, and delete the trouble field everywhere mid 2011.

5.  Advantages and disadvantages of the proposal
------------------------------------------------

5.1 Advantages

    - Networks will be able to supply their own, direct contact
      information for abuse departments.

    - Abuse complaints will not be sent to the "wrong" contact any
      more.

    - This permits greater administrative and operational flexibility,
      and faster abuse handling will be possible.

5.2 Disadvantages

    - Introducing a mandatory reference to the IRT Object will establish
      a new object. This object, like all other existing objects, will
      face the data accuracy problem. This proposal aims to address the
      issue of a missing place for abuse contact information and will
      not improve data accuracy in the whois database. Data accuracy
      will be part of another proposal that is already being discussed
      on the APNIC and RIPE policy mailing list.

6.  Effect on AfriNIC members
---------------------------

There will be no immediate affect for AfriNIC members with existing
resource registrations already in the AfriNIC Whois Database.

However, members will need to add a reference to the mandatory IRT
object in the following situations:

    - The first time members attempt to update an existing inetnum,
      inet6num or aut-num object

    - When members add new inetnum, inet6num or aut-num objects

7.  References
--------------

[1] Finding contacts for an IP address
    http://www.afrinic.net/Registration/spam.htm

[2] prop-079: Abuse contact information
    http://www.apnic.net/policy/proposals/prop-079

[3] Introduction to ARIN's Database
    https://www.arin.net/knowledge/database.html#abusepoc

[4] There is no formal documentation on abuse-c in inetnum and inet6num
    objects, but for documentation on the abuse-c in ASN records, see
    LACNIC Policy Manual (v1.3 - 07/11/2009)
    http://lacnic.net/en/politicas/manual4.html

[5] IRT Object FAQ
    http://www.ripe.net/db/support/security/irt/faq.html

--
| Tobias Knecht | CEO | abusix UG (haftungsbeschraenkt)
| tk at abusix.com | http://abusix.com
| Postfach 210127 | 76151 Karlsruhe | Germany
| ---
| Register of Companies(Handelsregister): HRB 707959
| District of Court(Amtsgericht) Mannheim/Germany
| Registered Office: Karlsruhe/Germany
| CEO: Tobias Knecht

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 262 bytes
Desc: OpenPGP digital signature
URL: <https://lists.afrinic.net/pipermail/rpd/attachments/20100406/c64443bb/attachment.sig>