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@ripe.net becomes, on expansion: abuse-mailbox: (scope=tea) coffee-bar@ripe.net abuse-mailbox: (scope=coffee) coffee-bar@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 --