[acm-tf] Abuse Contact Information - Policy Proposal

Hi Tobias!

Thanks for casting the set of ideas into a draft text, and my apologies
for being off-line for a while in the TF. There were some sound reasons
for that, unfortunately.

Before I go into details, let me double-check that I am not completely
off-track:

Does this draft assume that we will (eventually) build an implementation
along the lines of Denis' idea to use an extended "role" approach[1]?

As a side-line, I may want to offer some word-smithing later on to make
it (imho) easier to digest and to accept for some parties. I presume we
want to have an implementation asap :-)

For a technical aspect: do we (for hierarchically managed address space)
intend to preserve the current irt: relevance/coverage and the associated
lookup mechanics for the proposed policy and implementation?

Regards,
Wilfried.

[1] which I pretty much like, btw. Thanks, Denis!


Tobias Knecht wrote:

> Hello,
> 
> as we decided yesterday in the conference call we will start working on
> a policy proposal from now on to have our new proposal ready for
> discussion at RIPE 63.
> 
> 
> I suggest going through a typical policy text step by step and as warm
> up starting with the "Summary of Proposal", the "Summary of a current
> problem" and the situation on other RIRs.
> 
> #####
> 
> Summary of the proposal:
> 
> This is a proposal to introduce a new contact attribute named abuse-c,
> which can be references by inetnum, inet6num and aut-num objects. It
> provides a more accurate and efficient way for abuse reports to reach
> the correct network contact and helps reporting institutions to find the
> correct abuse contact information more easily.
> 
> #####
> 
> Summary of the 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 RIPE region, the biggest problem for network
> operators is to know the best place to publish abuse contact information
> (irt, "abuse-mailbox:", "remark-fields:", and in addition to that, in
> which object they should publish them?). On the other hand abuse
> reporting parties having a huge problem with finding a correct abuse
> contact in the variety of possibilities.
> 
> This proposal will help to stop uncontrolled growth and solves the above
> mentioned problems.
> 
> #####
> 
> Situation in other RIRs
> 
> AfriNIC:
> Policy Proposal AFPUB-2010-GEN-006 is awaiting implementation.
> http://www.afrinic.net/docs/policies/AFPUB-2010-GEN-006-draft-02.htm
> 
> APNIC
> Policy Proposal "prop-079: Abuse contact information" was implemented in
> November 2010.
> http://www.apnic.net/policy/proposals/prop-079
> 
> ARIN:
> An abuse-POC exists for Organisational ID identifiers.
> https://www.arin.net/knowledge/database.html#abusepoc
> ARIN decided to make abuse-c mandatory.
> https://www.arin.net/announcements/2011/20110718.html
> 
> LACNIC:
> An "abuse-c:" exists for aut-num, inetnum and inet6num objects.
> http://lacnic.net/en/politicas/manual4.html
> 
> #####
> 
> I copied some of the text parts from my former proposal to have an easy
> kick-off. I guess this will be enough for a warm-up, so please feel free
> to change, comment and discuss the parts above and as soon as we have a
> rough consensus here we can start talking "Policy Text".
> 
> Thanks,
> 
> Tobias
> 
> 
> --
> | 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
> 
> Follow abusix on Twitter! http://twitter.com/abusix
> 
> 
> 
> ------------------------------------------------------------------------
> 
> Subject:
> [acm-tf] some thoughts on issues raised today
> From:
> Denis Walker <denis at ripe.net>
> Date:
> Wed, 15 Jun 2011 21:49:36 +0200
> To:
> acm-tf at ripe.net
> 
> To:
> acm-tf at ripe.net
> 
> 
> Dear Colleagues,
> 
> I was thinking about a couple of points made during the discussion today
> while on the train home (yes I know I should get a life but I just had
> to write it down). In particular the points about (not) introducing a
> new NIC hdl suffix (-abuse) and the need to create multiple ROLE objects
> with duplicated data for small organisations. An idea came to mind that
> addresses both these issues, fits even better within our current data
> model and is extensible.
> 
> Suppose we introduce a new attribute to the ROLE object:
> role-type:      [mandatory]  [multiple]     []
> 
> and allow this initially to take one of three values:
> 
> STANDARD    All the current ROLE objects would fit with this type
> ABUSE       For ROLE objects holding abuse contact data
> IRT         For ROLE objects holding IRT contact data
> 
> We then add two new contact attributes "abuse-c:" and "irt-c:"
> (replacing "mnt-irt:"). These can only reference ABUSE and IRT ROLE
> object types respectively. All role based contact information is now
> held in the one object type, ROLE. All references to contact details are
> from the same type of attribute, "xxx-c:". There is no need for a new
> NIC hdl suffix. Existing ROLE objects with their current NIC hdls can be
> used for any of these roles. There is no need for a separate IRT object
> referenced by a maintainer like attribute. The ROLE object with
> "role-type: IRT" and referenced by an "irt-c:" replaces it.
> 
> The syntax for the ROLE object then becomes a superset of all the
> attributes needed for each of these roles. All these attributes can be
> defined as OPTIONAL by syntax. Their use in each type can be defined by
> business rules as one of:
> 
> REQUIRED    - must have
> ALLOWED     - can have
> NOT ALLOWED - can't have
> 
> Suppose we have the following superset of optional attributes for all
> role types:
> 
> abuse-mailbox:
> e-mail:
> phone:
> irc:
> url:
> im:
> signature:
> encryption:
> irt-nfy:
> 
> One example set of business rules could be:
> 
> STANDARD ROLE
> 
> REQUIRED
>  e-mail:
> ALLOWED
>  phone:
> NOT ALLOWED
>  abuse-mailbox:
>  irc:
>  url:
>  im:
>  signature:
>  encryption:
>  irt-nfy:
> 
> ABUSE ROLE
> 
> REQUIRED
>  abuse-mailbox:
> ALLOWED
>  phone:
>  e-mail:
>  irc:
>  url:
>  im:
> NOT ALLOWED
>  signature:
>  encryption:
>  irt-nfy:
> 
> IRT ROLE
> 
> REQUIRED
>  e-mail:
>  signature:
>  encryption:
> ALLOWED
>  phone:
>  irt-nfy:
> NOT ALLOWED
>  abuse-mailbox:
>  irc:
>  url:
>  im:
> 
> Filtering and access control limits (ACL) could also apply differently
> to the different role types. For STANDARD and IRT ROLE objects query
> filtering (negated with the -B flag) could apply to all attributes
> containing an email address (as it does now). ACL will apply to the
> number of these role types a user queries. For the ABUSE ROLE objects
> filtering should only apply to database management attributes like
> "notify:" and "changed:". The operational specific attributes like
> "abuse-mailbox:" and "e-mail:" will not be filtered. Also no ACL will
> apply to queries for these role types.
> 
> By allowing "role-type:" to be a multiple attribute, one ROLE object can
> take on more than one role. But with the caveat that the least
> restrictive rules for a role type will apply. So for a small company
> with only one set of people who do everything, one ROLE object can be
> defined as both STANDARD and ABUSE. The business rules will be a
> composite of these two role types. No ACL will apply to queries for this
> ROLE object as it is an ABUSE role type, even though it is also a
> STANDARD role type. It becomes a user choice between convenience and
> control.
> 
> To summarise, one object type can be used to define any type of contact
> role. We currently have a need for three types. Any new type can be
> added in the future by defining a new type value. Business rules can
> define the arrangement of attributes per type from a superset of
> attributes, including any new ones added later. All contacts should be
> referenced by attributes of the format "xxx-c:" and again business rules
> can restrict the type of role these attributes can reference.
> 
> I hope this provides some helpful thoughts on these two issues and also
> takes another step in the direction of simplifying the data model.
> 
> cheers
> denis
>