This policy proposal has been accepted and has been implemented
The new RIPE Document is: ripe-705
In 2012, the RIPE community developed a policy (ripe-563) that introduced a mandatory "abuse-c:” contact attribute, which holds contact information intended for automatic and manual reports of abusive behaviour originating in resource holders’ networks. Since then, this “abuse-c:” information has become an essential part of the accountability of the RIPE community.
However, ripe-563 didn’t provide for the validation of “abuse-c:” contact information. This undermines the effectiveness of the policy, as “abuse-c:” information can often be out of date or inaccurate (with no valid contact); the RIPE NCC receives several hundred reports of invalid contact information each year. Further problems with abuse contacts are discussed regularly on the Anti-Abuse WG mailing list.
Improving the trust and safety of the IP address space is a priority for the RIPE community. It has therefore established the Assisted Registry Check (ARC) in order to help its members strengthen registry data by explaining the risks of outdated information and the benefits of ensuring their data is correct. ARC reviews are carried out for approximately 25%-30% of the membership every year and cover four subject areas: registry consistency, resource consistency, route/rDNS consistency and resource certification usage/consistency (RPKI). However, the ARC was not designed for the validation of the “abuse-c:” contact.
This proposal aims to give the RIPE NCC a mandate to validate “abuse-c:” information, at least once a year, and to follow up in cases where contact information is found to be invalid. The objective of this proposal is not to devise a detailed validation procedure. The RIPE NCC is best placed to assess the technical challenges and the financial and human resources necessary to conduct validation tests in the most efficient manner. The RIPE NCC is expected to propose an implementation method (including the criteria to consider a contact point invalid, how to address auto-answers, how often the validation process should be carried out, etc.) in its impact analysis.
Although Legacy Resource Holders are not impacted by this policy proposal, they also share the common objective of improving the trust and safety of the IP address space.
[…]
The role objects used for abuse contact information will be required to contain a single “abuse-mailbox:” attribute which is intended for receiving automatic and manual reports about abusive behavior originating in the resource holders’ networks.
The “abuse-mailbox:” attribute must be available in an unrestricted way via whois, APIs and future techniques.
[…]
The role objects used for abuse contact information will be required to contain a single “abuse-mailbox:” attribute which is intended for receiving automatic and manual reports about abusive behaviour originating in the resource holders’ networks.
The “abuse-mailbox:” attribute must be available in an unrestricted way via whois, APIs and future techniques.
The RIPE NCC will validate the “abuse-mailbox:” attribute at least annually. Where the attribute is deemed incorrect, it will follow up in compliance with relevant RIPE Policies and RIPE NCC procedures.
Note: In order to provide additional information related to the proposal, details of an impact analysis carried out by the RIPE NCC are documented below. The projections presented in this analysis are based on existing data and should be viewed only as an indication of the possible impact that the policy might have if the proposal is accepted and implemented.
In the context of “Abuse Contact Management in the RIPE Database” and this impact analysis, the term ““abuse-mailbox:” attribute” refers to an email address that is entered in role objects in the RIPE Database. These role objects are referenced as “abuse-c:” attributes directly or indirectly to Internet Number resource objects (such as inetnum, inet6num, aut-num).
It is the RIPE NCC’s understanding that this policy change aims to identify and fix invalid “abuse-mailbox:” attributes, making them more current and correct.
If this proposal reaches consensus, it would require the RIPE NCC to annually validate whether “abuse-mailbox:” attributes are correctly configured. Currently there are about 70,000 such attributes in the RIPE Database.
Not in scope are “abuse-mailbox:” attributes that are solely referenced in Internet number resources with the status LEGACY. The RIPE Policy “RIPE NCC Services to Legacy Internet Resource Holders” requires other RIPE policies to mention legacy resources explicitly in their scope if they are to apply to legacy resources. This is not the case with the proposed policy change.
Also not in scope for this validation are scenarios where the “abuse-mailbox:” attribute is correctly configured but reports are not followed up in a way that the reporter would like. The RIPE NCC has no mandate to interfere with the internal abuse handling procedures of resource holders.
The RIPE NCC already has a procedure to fix “abuse-mailbox:” attributes that are reported as being incorrect. Building on this procedure, the RIPE NCC will develop a process to proactively validate “abuse-mailbox:” attributes on a yearly basis.
To increase efficiency, this process will use an automated solution that will allow the validation of “abuse-mailbox:” attributes without sending an email. No action will be needed by resource holders that have configured their “abuse-mailbox:” attribute correctly.
The RIPE NCC will validate the technical parameters of an “abuse-mailbox:” attribute, such as syntax, domain and mail server configuration, to determine if it is correctly configured to receive messages.
This automated validation will be performed whenever an “abuse-mailbox:” attribute gets created or updated. During implementation, this validation will also be run in batches on all current “abuse-mailbox:” attributes. Attributes that pass this check will be considered as validated and will be checked again one year later.
“Abuse-mailbox:” attributes that don’t pass this check will be followed up with. The RIPE NCC will ask the responsible LIR to review the “abuse-mailbox:” attribute referenced in resources directly registered to them. For independent Internet number resources, the RIPE NCC will ask the sponsoring LIR to follow up with the resource holder to have the “abuse-mailbox:” attribute reviewed.
If required, the RIPE NCC can provide support in updating the “abuse-mailbox:” attribute.
Once the “abuse-mailbox:” attribute is confirmed to be working, it will be considered validated and checked again after one year.
While the automated validation will identify most invalid “abuse-mailbox:” attributes, there may be false negatives or false positives. If a flagged “abuse-mailbox:” attribute is in fact working, this will be clarified when contacting the LIR. An “abuse-mailbox:” attribute that has passed the check but turns out to be not working can be always reported to the RIPE NCC with the report form.
The proposed policy text defines that where the attribute is deemed incorrect, the RIPE NCC will follow up in compliance with relevant RIPE Policies and RIPE NCC procedures.
The goal of correct registration is the foundation of almost all RIPE policies. More specifically, this can be seen in section 4.0 of “IPv4 Address Allocation and Assignment Policies for the RIPE NCC Service Region”, which describes the registration requirements and says: “Registration data (range, contact information, status etc.) must be correct at all times (i.e. they have to be maintained).”
There were concerns raised during initial discussions on the proposal that the RIPE NCC might close LIRs and de-register Internet Number resources because of an incorrect “abuse-mailbox:” attribute. As mentioned before, the RIPE NCC understands the mandate of this policy change as primarily about identifying and fixing invalid “abuse-mailbox:” attributes.
While the RIPE NCC will aim to have “abuse-mailbox:” attributes corrected as soon as possible, the RIPE NCC will be sympathetic to the specific situation of the resource holder (for example if the database administrator is temporary unavailable or if guidance is needed to update RIPE Database objects).
If a resource holder remains unresponsive or refuses to change incorrect contact information, existing RIPE policies allow the RIPE NCC to close LIRs for unresponsiveness or repeated policy violations, as well to de-register independent resources. Based on these policy requirements, the RIPE NCC has developed the procedure “Closure of Members, Deregistration of Internet Resources and Legacy Internet Resources”.
The following should be noted:
If this proposed policy change reaches consensus, an improvement of the registry data is expected, as more “abuse-mailbox:” attributes will be current and correct.
The proposal does not have an impact on fragmentation and the routing system.
The RIPE Database contains around 70,000 distinct abuse-mailbox attributes. A preliminary test with a batch of random “abuse-mailbox:” attributes indicated that 10%-25% of these attributes might be incorrect or inactive. Therefore, the RIPE NCC expects a significant amount of work to fix incorrect “abuse-mailbox:” attributes during the initial validation.
While the process will be automated as much as possible, a considerable number of these attributes will need to be checked manually by Registration Services.
At this point, the RIPE NCC cannot reliably estimate the amount of work that will be needed to fix a set of incorrect “abuse-mailbox:” attributes. If this policy change is accepted, the RIPE NCC will start the verification with a representative batch of “abuse-mailbox:” attributes. The experiences gathered during this trial will be used to prepare different implementation options to the RIPE NCC Executive Board, which will decide on the option with the best balance between fast implementation and responsible use of RIPE NCC resources.
These options will contain variations in the automated validation, variations in the balance between automated and manual steps, as well as how many staff will work simultaneously on the manual follow-up.
Once the 70,000 “abuse-mailbox:” attributes have been validated for the first time, a much lower workload is expected for the next rounds of annual re-validation, as only those attributes that have become invalid within that period will need to be followed up with.
The main process to fix incorrect “abuse-mailbox:” attributes will be the existing process that is already followed when the RIPE NCC receives external reports.
The ARC process can play a supporting role, especially if there are indications that the incorrect “abuse-mailbox:” attributes are part of a bigger issue of incorrect contact information for an LIR. In such situations, an ARC can be scheduled immediately. However, full coverage via the ARC process is not possible due to the differing scope and frequency of the processes. This policy change would require the annual validation of all abuse contact email addresses (for allocated and independent resources), while the ARC process aims to verify the registration details of LIRs only.
If this policy change reaches consensus, the RIPE NCC will make sure that all email validation checks are performed in accordance with the data protection legislation in the EU.
Also the RIPE NCC may need to update the relevant procedural documents, including the RIPE NCC procedural document “Closure of Members, Deregistration of Internet Resources and Legacy Internet Resources”.
With the information currently available, it is expected that implementation of the proposal would have a medium impact (about three months) in terms of the software development needed to facilitate the policy change. Once our systems are ready to perform the automated validation, a trial phase will be performed. Using the experience gained from this trial, all current “abuse-mailbox:” attributes will then be validated in batches. The RIPE NCC can’t reliably estimate how long this phase will take, it will depend on the option selected by the RIPE NCC Executive Board (as outlined in section C).
The implementation will be considered completed after every “abuse-mailbox:” attribute has been validated for the first time.