[db-wg] Action item 47.2: Proposal for Adding Abuse Contact

On 5 Apr 2004, at 12:41, Wilfried Woeber, UniVie/ACOnet wrote:

>   Our next meeting is scheduled for less than a month from today,
>   so it is time to ask for agenda items for the draft agenda.


Proposal for Adding Abuse Contact for inet*num: Objects in RIPE Database

This proposal responds to action item AP-47.2 arising from the RIPE
Database Working Group Meeting at RIPE 47.


Niall O'Reilly
Randy Bush


Requirement:

Net users who perceive abuse from some net source wish to contact some
service which has officially agreed to deal with the abuse.  Currently,
they seem to scan the inet*num: objects and send mail to any or all
contacts in that object, including strange things such as the email
address in the changed: attribute. One variant or another of this
approach appears also to be the basis on which a number of notification
robots are built. The result is that alerts are too often misdirected,
may never reach an appropriate contact person, and even if they do, are
unnecessarily delayed.

There is an apparent need to provide, document, and promote a means for
clearer advertisement and retrieval of the appropriate abuse contacts.
This need seems to be clearly applicable to the inetnum: and inet6num:
objects.  A new attribute for these objects is defined to address this
apparent need.

Each of these objects must already have person: or role: objects linked
to the admin-c: and tech-c: attributes.  Many of them also use the
mnt-by: attribute to link to a mntner: object.  We propose allowing the
new attribute to be used in these objects as well.  Since a single
person:, role:, or mntner: object may be linked to a large number of
inet*num: objects, this approach allows the abuse contacts to be
advertised for a large number of inet*num: objects simply by specifying
them in a much smaller number of linked objects.  This is expected to
reduce very significantly the effort involved in taking advantage of
our proposal.

Should there be similar needs in other object types, it is anticipated
that the abuse-mailbox: attribute described below would be added to
those objects as appropriate.


Three things are needed:

   - The inetnum:, inet6num:, person:, role: and mntner: objects are
     extended with an optional attribute "abuse-mailbox:".  The value
     of this attribute must be a valid and active RFC-2822 e-mail 
address.

   - The procedure for identifying the appropriate abuse contact for
     a given inet*num: object in the database must be defined and
     instantiated in a reference implementation.

   - This procedure must be documented and promoted as the one and only
     method that should be used to identify the contact address for
     reporting spam and other forms of abuse.  This documentation should
     be made prominently available so that manual seekers and creators of
     automated reporting tools will all clearly know that the 
abuse-mailbox:
     is the one and only place to which abuse should be reported, and 
that
     other contacts in the objects should not be abused.


Extension to database objects:

The objects addressed by this proposal (inetnum:, inet6num:, person:,
role:, mntner:) would be extended by the addition to their templates
of a new attribute definition, as follows.

     abuse-mailbox: [optional]   [multiple]   [inverse key]

The value of the "abuse-mailbox:" attribute must be a valid and active
RFC-2822 address.

Optionally, the value of the "abuse-mailbox:" attribute may be extended
by inserting a hint string before the RFC-2822 address, to indicate the
kinds of abuse which are to be notified to the specified address. This
is expected to be useful to organizations who wish to advertise more
than one abuse contact, and to give guidance as to which of these is
the appropriate notification target in particular circumstances.

In case a hint string is specified, it must be discarded when forming
an inverse key.

The limited vocabulary to be used for the hint string may be reviewed
from time to time.  Initially, the following terms are allowed.  They
are to be treated as case-insensitive, and to have the indicated 
semantics:

	''		Always notify this contact
	'Spam'		Notify this contact for spam abuse ONLY
	'Security'	Notify this contact for DDoS and intrusion abuse ONLY

The syntax for the "abuse-mailbox:" attribute is specified below,
using the notation of RFC-2822. Whitespace between tokens is not
specified, but is implicitly permitted.

	abuse-mailbox-attribute =
     		"abuse-mailbox:"
		[ hint-string ]
		RFC-2822-addr-spec
		[ RFC-2622-comment ]

	hint-string =
		"(" "scope" "=" scope-list ")"

	scope-list =
		scope-keyword
		/ "'" scope-keyword-list "'"

	scope-keyword-list =
		scope-keyword
		/ scope-keyword-list "," scope-keyword

	scope-keyword =
		""
		"Spam"
		/ "Security"

The "RFC-2822-addr-spec" rule is specified (as "addr-spec") in RFC-2822.
The "RFC-2622-comment" rule is specified in RFC-2622.


Procedure

The procedure for advertising abuse contacts is complementary to that
for discovering the contacts:  the "abuse-mailbox:" attribute must be
added to one or more database objects so that the result of the
discovery procedure matches the intent of the advertiser.

The procedure for discovering the appropriate abuse contact for a
given network object (inetnum:, inet6num:, asnum:) in particular
circumstances of abuse (spam, intrusion, ...) is defined below.
The procedure provides for traversing the database to find the "best"
(or "nearest") "abuse-mailbox:" attribute.  It also provides a fallback
mechanism in case the optional "abuse-mailbox:" attribute is not found.

Given a database object (inet*num, asnum, ...) and a keyword (spam,
security, ...) representing the circumstances of the abuse, the
following four-stage procedure is used.

   - First find the best abuse-contact-set for the given object.

   - Then discard any members of the abuse-contact-set which do not match
     the circumstances of abuse.

   - Next, if the set is empty, apply the fallback procedure to add 
members
     to the abuse-contact-set.

   - Finally, consider all surviving distinct members of the
     abuse-contact-set as the list of mailboxes to be notified.

These stages are to be implemented as follows.


Finding the best abuse-contact-set:

     Initially, the abuse-contact-set and the fallback-contact-set
     are empty.  The list of database objects to be visited contains only
     the given database object.

     Repeat the following steps until either the abuse-contact-set
     is no longer empty or the list of database objects to be visited
     is exhausted.

     Select the first object from the list of database objects to be
     visited, and discard this object from the list.

     Add the "abuse-mailbox:" value(s), if any, found in the selected
     object to the abuse-contact-set.

     If the abuse-contact-set is still empty, add the following objects,
     in the given order, to the list of database objects to be visited:

       - the object indicated by each "mnt-by:" attribute of the
       	selected object;
       - the object indicated by each "tech-c:" attribute of the
       	selected object;
       - the object indicated by each "admin-c:" attribute of the
       	selected object;
       - the next containing database object.

     It is assumed that existing database procedures are sufficient to
     identify the next containing database object.


Adding "abuse-mailbox:" values to the abuse-contact-set:

     Expand any "abuse-mailbox:" value which contains a
     "scope-keyword-list" to a list of values, each containing
     a single "scope-keyword".  Then add each value in the list
     to the abuse-contact-set.

     The expansion operation is illustrated by the following
     example.

     The attribute specified as

	abuse-mailbox: (scope='tea,coffee') coffee-bar at ripe.net

     becomes, on expansion:

	abuse-mailbox: (scope=tea) coffee-bar at ripe.net
	abuse-mailbox: (scope=coffee) coffee-bar at ripe.net

     For completeness, we note that the syntax defined above allows
     redundant information to be specified in the "abuse-mailbox:"
     attribute, as illustrated in the following examples.

     1.	(scope='tea','tea') is equivalent to (scope='tea').

     2.  (scope='') is equivalent to omitting the hint string.

     3.  (scope=',tea') is also equivalent to omitting the hint string.

     More elaborate examples are easily constructed.  This is not
     recommended by the authors.


Discarding members of the abuse-contact-set:

     For each member of the abuse-contact-set for which a non-empty
     hint-string is specified which differs from the given keyword
     representing the circumstances of the abuse, remove that member
     from the abuse-contact-set.

     Matching of hint-strings to the keyword is to be performed as
     follows.

       - The distinction between upper and lower case is not significant.

       - Leading or trailing white space is not significant.

       - Embedded white space is significant, provided that any run of
         adjacent white-space characters is to be considered as a single
	white-space character. This provision is not relevant to the
	initial vocabulary allowed for hint-strings.


Fallback procedure:

     Select all database objects indicated by a "tech-c:" attribute of
     the originally given database object and add each "e-mail:" value
     found in this set of objects to the abuse-contact-set.


References:

     [1] [Draft] Minutes, Database Working Group, RIPE 47
     	Nigel Titley, 2 March 2004

     [2] RFC-2822: Internet Message Format
     	P. Resnick, April 2001

     [3] RFC-2622: Routing Policy Specification Language (RPSL)
     	C. Alaettinoglu et al., June 1999


-- Ends --