Search RPD Archives
[rpd] New proposal: Abuse Contact Policy Update
Amreesh Phokeer
amreesh.phokeer at gmail.com
Wed Oct 10 19:20:06 UTC 2018
Hi Jordi,
Currently there is the "mnt-irt" attribute (IRT object) which is optional
in inet(6)num and aut-num objects, which I suppose was intended to have the
similar purpose as the "abuse-c" you are proposing.
Indeed, the use of the IRT objects in the WHOIS database is almost nil [1],
mainly due to the fact that it is optional.
That's the IRT object:
$ whois -hwhois.afrinic.net -t irt
% This is the AfriNIC Whois server.
irt: [mandatory] [single] [primary/lookup key]
address: [mandatory] [multiple] [ ]
phone: [optional] [multiple] [ ]
fax-no: [optional] [multiple] [ ]
e-mail: [mandatory] [multiple] [lookup key]
abuse-mailbox: [mandatory] [multiple] [inverse key]
signature: [optional] [multiple] [ ]
encryption: [optional] [multiple] [ ]
org: [optional] [multiple] [inverse key]
admin-c: [mandatory] [multiple] [inverse key]
tech-c: [mandatory] [multiple] [inverse key]
auth: [mandatory] [multiple] [inverse key]
remarks: [optional] [multiple] [ ]
irt-nfy: [optional] [multiple] [inverse key]
notify: [optional] [multiple] [inverse key]
mnt-by: [mandatory] [multiple] [inverse key]
changed: [mandatory] [multiple] [ ]
source: [mandatory] [single] [ ]
Would making the "mnt-irt" mandatory solve parts referring to “abuse-c” and
“abuse-mailbox” in your proposal?
+1 for the two-factor verification mechanism proposed
Cheers,
Amreesh
[1]
https://afrinic.net/blog/6-afrinic-publishes-an-article-on-spam-from-an-rir-perspective
[views are my own]
On Thu, Aug 23, 2018 at 12:54 PM Ernest Byaruhanga <ernest at afrinic.net>
wrote:
> Colleagues,
>
> A new policy proposal has been received as follows, for which the
> community is encouraged to study and constructively discuss, as it touches
> a sensitive and important aspect of whois data accuracy:
>
> URL:
> https://afrinic.net/fr/community/policy-development/policy-proposals/2467-abuse-contact-policy-update
>
> ------------------------------------------------------------------
>
> Proposal: Abuse Contact Policy Update
> Amends: CPM article 8.0 (“Abuse” contact information)
> Author: Jordi Palet Martinez
>
>
> 1.0 Summary of the problem being addressed by this proposal
>
>
> The current policy doesn’t imply the obligation to register an abuse
> contact and specifies a format for personal communication and for
> “automatic reporting”, which - compared to other RIRs, becomes confusing,
> as a single email will be more efficient, as at the end, reports get copied
> to both emails.
>
> As a result, some LIRs may not have this contact information registered
> for their resources. In fact, there are even cases of LIRs that use a
> non-existent mailbox or one that is not actively monitored.
>
> In practice, this contact becomes ineffective to report abuses and
> generally gives rise to security issues and costs for the victims.
>
> This proposal aims to solve the problem and ensure the existence of a
> proper abuse-c contact and the process for its utilization, which is more
> uniform across all the RIRs, in order to facilitate cross-region abuse
> reporting.
>
>
> 2.0 Summary of how this proposal addresses the problem
>
>
> The Internet community is based on collaboration. In many cases, however,
> this is not enough and we all need to be able to contact those LIRs which
> may be experiencing a problem in their networks and may not be aware of the
> situation.
>
> This proposal creates a new section in the Policy Manual to solve this
> problem by means of a simple, periodic verification, and establishes the
> basic rules for performing such verification and thus avoids unnecessary
> costs to third parties who need to contact the persons responsible for
> solving the abuses of a specific network.
>
> The proposal guarantees that the cost of processing the abuse falls on the
> LIR whose client is causing the abuse (and from whom they receive financial
> compensation for the service), instead of falling on the victim, as would
> be the case if they had to resort to the courts, thus avoiding costs
> (lawyers, solicitors, etc.) and saving time for both parties.
>
> For this, the abuse-c attribute becomes mandatory in the “aut-num”,
> "inetnum" and "inet6num" objects, as well as in any others that may be used
> in the future. This attribute is an abuse contact, which must contain at
> least the "abuse-mailbox" attribute.
>
> The proposal is expected to be implemented in 90 days, to be confirmed by
> AfriNIC, a reasonable time frame to allow both the staff to develop the
> tool and the LIRs to update their abuse-c contacts.
>
>
> 3. Proposal
>
>
> Amending 8.0 of the CPM, as follows:
> (Side by side of current vs proposed content at
> https://afrinic.net/fr/community/policy-development/policy-proposals/2467-abuse-contact-policy-update
>
> +++++++++++++++++++++++++++++++++++++++
> 8.1 Introduction
>
> This policy specifies a mandatory object that must be used to publish
> abuse public contact information within the AFRINIC service region.
>
> The mentioned object must be referenced 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 contact.
>
> 8.2 Description of “abuse-c” and “abuse-mailbox”
>
> All resources allocated by AFRINIC must include a mandatory "abuse-c"
> contact attribute (abuse contact) in their corresponding WHOIS entry, with
> at least one valid, monitored and actively managed email inbox
> (abuse-mailbox) intended for receiving manual or automatic reports
> regarding abusive behavior, security issues, and the like.
>
> The "abuse-mailbox" attribute must be available in an unrestricted way via
> whois, APIs and future techniques.
>
> Considering the hierarchical nature of IP address objects, child objects
> of those directly distributed by AFRINIC may be covered by parent objects
> or they may have their own "abuse-c" attribute.
>
> Following usual practices, other "e-mail" attributes may be included for
> other purposes.
>
> 8.3 About the "abuse-mailbox"
>
> Emails sent to "abuse-mailbox" must require manual intervention by the
> recipient at some time, and may not be filtered, as in certain cases this
> might prevent the reception of the abuse reports, for example – in the case
> of spam, as it would include the spam message itself or URLs or content
> usually classified as spam.
>
> The "abuse-mailbox" may initially send an automatic reply, for example,
> assigning a ticket number, applying classification procedures, requesting
> further information, etc. However, it may not require the use of a form, as
> this would imply that each company that needs to report cases of abuse (a
> task that is typically automated) would be forced to develop a specific
> interface for each case, which is neither feasible nor logical, as it would
> place the cost of processing the abuse on those who submit the claim and
> are therefore victims of the abuse, instead of being paid by those whose
> client causes the abuse (and from whom they obtain income).
>
> By way of information, it is worth noting that it is reasonable for the
> person reporting the abuse to do so from the start and in that first
> report, sending the logs, or a copy of the spam message (attaching an
> example of the spam email or its full headers) or similar evidence proving
> the abuse. Likewise, it is reasonable to expect that the initial auto-reply
> email will specify that the claim will not be processed unless such
> evidence has been submitted, thus allowing the sender the opportunity to
> repeat the submission and include the pertinent evidence. This allows
> automatic reporting, for example, via fail2ban, SpamCop or others, keeping
> costs at a minimum for both parties involved.
>
> 8.4 Objectives of "abuse-c"/"abuse-mailbox" validation
>
> The procedure, which is to be developed by AFRINIC, must meet the
> following objectives:
>
> a) A simple process that guarantees its functionality and allows the
> helpdesks that deal with abuse reports to verify that validation requests
> actually come from AFRINIC and not from third parties (which might involve
> security risks), avoiding, for example, a single "direct" URL for
> validation.
>
> b) Avoid automated processing.
>
> c) Confirm that the person performing the validation understands the
> procedure and the policy, that they regularly monitor the "abuse-mailbox",
> that measures are taken, and that the abuse report receives a response.
>
> d) Validation period should be no longer than two (2) business days.
>
> e) If validation fails, escalate to the LIR and set a new validation
> period not to exceed three (3) business days.
>
> (By way of example, a detailed procedure is included in this policy
> proposal under "Additional Information").
>
> 8.5 Validation of "abuse-c"/"abuse-mailbox"
>
> AFRINIC will validate compliance with the items above, both when the
> "abuse-c" and/or "abuse-mailbox" attributes are created or updated, as well
> as periodically, not less than once every three months, and whenever
> AFRINIC sees fit.
>
> At the discretion of AFRINIC, in general or in specific cases (for
> example, for confirmation in cases of escalation under 8.6), AFRINIC may
> use domains other than afrinic.*, and even modify the subject and body of
> the message, in order to perform said validations more effectively.
>
> Lack of compliance will imply a more exhaustive follow-up, in accordance
> with the relevant AFRINIC policies / procedures, especially those related
> to revocation of resources.
>
> 8.6 Escalation to AFRINIC
>
> To avoid fraudulent behavior (for example, an "abuse-mailbox" that only
> replies to AFRINIC’s emails, or to messages with a specific subject or
> content), or failure to comply with the remaining aspects of this policy
> (incorrect or lack of response to cases of abuse) and, therefore, to
> guarantee the quality of the services in the region with the resources
> allocated by AFRINIC, a mailbox will be available (for example, "
> abuse-escalation at afrinic.net"), to escalate such situations, thus
> allowing for a re-validation (according to section 8.5 above) and even the
> intermediation by AFRINIC and, where appropriate, the application of the
> relevant policies/procedures, especially those related to revocation of
> resources.
>
> 8.7 Additional Information
>
> Example of the validation procedure.
>
> a) AFRINIC initiates the validation automatically, sending TWO consecutive
> emails to the "abuse-mailbox".
> b) These emails will be sent containing plain text only.
> c) The first email will contain the URL where the validation is to be
> performed ("validation.afrinic.net") and may contain information about
> the procedure, a brief summary of this policy, etc.
> d) The second email will contain a unique alphanumeric validation code.
> e) The person in charge of the "abuse-mailbox" must go to the URL and
> paste the code received in the second email in the form.
> f) This URL must be designed in such a way that it prevents the use of an
> automated process (for example, "captcha"). In addition, it must contain a
> text that confirms that the person performing the validation understands
> the procedure and the policy, that they regularly monitor the
> "abuse-mailbox", that measures are taken to solve reported cases of abuse,
> and that the abuse report receives a response, with a "checkbox" that must
> be accepted in order to proceed.
> g) The alphanumeric code will only be valid for a maximum of two working
> days.
> h) If the code is not entered within that time, the system will mark the
> "abuse-c" as "temporarily invalid” and will alert AFRINIC staff so that
> they can initiate a personalized follow-up with the LIR.
> i) If no reply is received confirming that the situation has been
> corrected, after an additional period of three business days, the "abuse-c"
> will be permanently marked as "invalid".
> j) The validation process will be repeated automatically (items ‘a’ to ‘g’
> above). If satisfactory, the "abuse-c" will be marked as "valid"; otherwise
> it will be considered in breach of the policy.
> +++++++++++++++++++++++++++++++++++++++
>
>
> 4. Revision History
>
>
> Date 12 March 2018 | Version 1: AFPUB-2018-V6-005-DRAFT01
> Details :Initial Draft Posted to rpd
>
>
> 5. References
>
> A similar proposal has been discussed in the RIPE region and is waiting
> for co-chairs to declare consensus.
>
>
>
>
>
>
>
>
> _______________________________________________
> RPD mailing list
> RPD at afrinic.net
> https://lists.afrinic.net/mailman/listinfo/rpd
>
--
Amreesh Phokeer
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.afrinic.net/pipermail/rpd/attachments/20181010/eebf1b31/attachment-0001.html>
More information about the RPD
mailing list