[arin-ppml] Draft Policy ARIN-2019-5: Validation of Abuse-mailbox

[Jo Rhett]

Running a ticketing system could involve significant resources. However
simply accepting, aggregating, and providing public information on contacts
that are non-functional, ideally via an API so we can use it for ... :D

On Thu, Mar 28, 2019 at 7:38 AM Michael Peddemors <michael at linuxmagic.com>
wrote:

> Still would like to see that idea I put forth about ARIN actually having
> a public ticketing system, for when the public reports inaccurate data.
>
> This way a public record can be seen to how long tickets remain
> unresolved, and a bit of public shaming on this.
>
> I think this would do more than most policies.
>
> Just tried to email an large carrier (noPTR issues) so emailed the
> contact on record..
>
> OrgTechHandle: IPMAN-ARIN
> OrgTechName:   IP MANAGE
> OrgTechPhone:  +1-647-747-3294
> OrgTechEmail:  ipmanage at rogers.wave.ca
> OrgTechRef:    https://rdap.arin.net/registry/entity/IPMAN-ARIN
>
> <ipmanage at rogers.wave.ca>:
> Remote host 66.185.87.233 does not like recipient ipmanage at rogers.wave.ca
> Remote host said: 550 5.1.1 <ipmanage at rogers.wave.ca>: Recipient address
> rejected: User unknown in virtual mailbox table
>
>
>
> On 2019-03-26 12:52 p.m., ARIN wrote:
> > On 21 March 2019, the ARIN Advisory Council (AC) accepted
> > "ARIN-prop-264: Validation of Abuse-mailbox" as a Draft Policy.
> >
> > The Draft Policy text is below and can be found at:
> > https://www.arin.net/participate/policy/drafts/2019_5/
> >
> > You are encouraged to discuss all Draft Policies on PPML. The AC will
> > evaluate the discussion in order to assess the conformance of this draft
> > policy with ARIN's Principles of Internet number resource policy as
> > stated in the Policy Development Process (PDP). Specifically, these
> > principles are:
> >
> > * Enabling Fair and Impartial Number Resource Administration
> > * Technically Sound
> > * Supported by the Community
> >
> > The PDP can be found at:
> > https://www.arin.net/participate/policy/pdp/
> >
> > Draft Policies and Proposals under discussion can be found at:
> > https://www.arin.net/participate/policy/drafts/
> >
> > Regards,
> >
> > Sean Hopkins
> > Policy Analyst
> > American Registry for Internet Numbers (ARIN)
> >
> >
> >
> > Draft Policy ARIN-2019-5: Validation of Abuse-mailbox
> >
> > Problem Statement:
> >
> > The current policy, “3.6. Annual Validation of ARIN’s Public Whois Point
> > of Contact Data” does not provide sufficient validation of the actual
> > availability of the abuse mailbox.
> >
> > As a result, some resource-holders (LIRs and end-users) might not keep
> > this contact information up to date, or might use a non-responsive
> > mailbox, which could be full or not actively monitored, or even
> > responding only to ARIN emails.
> >
> > In practice, this contact becomes ineffective to report abuse and
> > generally gives rise to security issues and costs for the victims.
> >
> > Furthermore, POCs are verified only every year and provides a too much
> > relaxed response time (60 days).
> >
> > Finally, the proposal is aiming to have a standard abuse-c/abuse-mailbox
> > as a pointer to the actual abuse POC, in order to facilitate tools
> > across regions.
> >
> > This proposal aims to solve those issues and ensure the existence of a
> > proper abuse-c POC and the process for its utilisation.
> >
> > a. Arguments Supporting the Proposal
> >
> > The Internet community is based on collaboration. However, in many cases
> > this is not enough and we need to be able to contact those
> > resource-holders (LIRs or end-users) that may be experiencing a problem
> > in their networks and are unaware of the situation.
> >
> > This proposal solves 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 that
> > 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 resource-holder causing the abuse (or its customers, 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 a legal claim
> > in an extreme case, thus avoiding costs (investigation and in the
> > worst-case lawyers, solicitors, etc.) and saving time for both parties.
> >
> > Having an equivalent policy in different regions, has the advantage of
> > improving overall response to abuse cases, reduces the cost for handling
> > them, and facilitates the work for all the people involved in the
> > operation of Internet.
> >
> > b. Arguments Opposing the Proposal
> >
> > ARIN members have to verify and update (if required) their abuse-c
> > objects periodically.
> >
> > Policy Statement:
> >
> > Proposed
> >
> > 1.0 Abuse Contact Information
> >
> > The “abuse-c:” will reference a role object holding abuse contact
> > information. The positioning of the “abuse-c:” attributes will make use
> > of the hierarchical nature of the resource data to minimize the workload
> > on resource holders. Internet number resources need to have an
> > “abuse-c:” attribute. The “abuse-c:” will be mandatory for all aut-nums.
> > Due the hierarchical nature of IP address objects, at least every direct
> > allocated inetnum and inet6num needs to have an “abuse-c:”. Inherited
> > objects might have their own “abuse-c:” attribute or they will be
> > covered by the higher-level objects. 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. ARIN will
> > validate the “abuse-mailbox:” attribute at least every six months, as
> > per the procedure stated in this policy. Where the attribute is deemed
> > incorrect, it will follow up in compliance with relevant ARIN policies
> > and procedures. As per current practice, other “e-mail:” attributes can
> > be included for any other purposes.
> >
> > 2.0 About the “abuse-mailbox”
> >
> > Emails sent to “abuse-mailbox” must require manual intervention by the
> > recipient at some point, and may not be filtered, because in certain
> > cases this might prevent receiving abuse reports, for example in a spam
> > case where the abuse report could 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 should not require that the abuse reporter
> > fills a form, as this will imply that each entity that needs to report
> > abuse cases (a task that is typically automated), would be forced to
> > develop a specific interface for each resource-holder in the world that
> > mandates filling forms, 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 for
> > by those whose clients cause the abuse (and from whom they obtain
> > income). By way of information, it is worth noting that it is reasonable
> > to expect that the abuse reporting procedure sends, with the initial
> > abuse report, the logs, a copy of the spam message (attaching an example
> > of the spam email or its full headers), or equivalent evidence
> > (depending on the abuse type). Likewise, it is reasonable to expect that
> > the initial auto-reply email could specify that the claim will not be
> > processed unless such evidence has been submitted, thus allowing the
> > sender an opportunity to repeat the submission and include relevant
> > evidence. This allows automatic reporting, for example, via fail2ban,
> > SpamCop or others, keeping costs at a minimum for both parties involved.
> >
> > 3.0 Objectives of “abuse-mailbox” validation
> >
> > The procedure, which will be developed by the ARIN, must meet the
> > following objectives: 1. A simple process that guarantees its
> > functionality and allows the helpdesks that deal with abuse reports to
> > verify that validation requests actually come from the ARIN and not from
> > third parties (which might involve security risks), avoiding, for
> > example, a single “direct” URL for validation. 2. Avoid exclusively
> > automated processing. 3. 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. 4. Validation period of no longer than 15
> > days. 5. If validation fails, escalate to the LIR and set a new
> > validation period not to exceed 15 days. The “initial” and “escalation”
> > validation periods may be modified by the ARIN, if deemed appropriate,
> > informing the community about the motivation. For example, it could be
> > longer for the first validation, once this policy is implemented, and
> > shortened afterwards once the percentage of failures decreases, so the
> > quality of the contacts increases and consequently a decrease in the
> > average abuse response times could be expected. (By way of example, a
> > detailed procedure is included in this policy proposal under
> > “Comments/Example of the validation procedure”) 4.0 Validation of
> > “abuse-mailbox”
> >
> > ARIN 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 six months, and whenever
> > ARIN sees fit. At the discretion of ARIN, in general or in specific
> > cases (for example, for confirmation in cases of escalation under 5.),
> > ARIN may use domains other than arin., and even modify the subject and
> > body of the message, in order to perform said validations more
> > effectively. Lack of compliance will initially lead to the blocking of
> > that account’s access to the invalid resources at ARIN Online, except
> > for the abuse-c/abuse-mailbox update and payments. The account blocking
> > will be released upon re-validation of the abuse-c/ abuse-mailbox,
> > triggered automatically by the update of the abuse-c/abuse-mailbox.
> > During the blocking of that account to the invalid resources, each time
> > is accessed, will show a warning message including this policy text, and
> > to continue it will be necessary to confirm by means of a check-box,
> > that the message has been read in full. ARIN will do a more exhaustive
> > follow-up, in accordance with the relevant ARIN policies, procedures or
> > contractual requirements. The frequency of the periodic validation could
> > be modified if ARIN deems this appropriate and informs the community of
> > its reasons. For example, a single validation could be done in the first
> > year, to facilitate adherence to the policy, and then the number of
> > annual validations could progressively increase, reaching even quarterly
> > ones, with the aim of improving the quality of the contacts.
> >
> > 5.0 Escalation to ARIN
> >
> > To avoid fraudulent behavior (for example, an “abuse-mailbox” that only
> > replies to ARIN 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), a mailbox will be
> > available (for example, “escalation-abuse at arin.net”), to escalate such
> > situations. This would allow for a re-validation (according to section
> > 4. above) and even intervention by ARIN and, where appropriate, the
> > application of the relevant policies, procedures or contractual
> > requirements.
> >
> > Comments:
> >
> > Timetable for implementation: Immediate
> >
> > Anything Else
> >
> > Situation in other regions:
> >
> > A similar proposal has been accepted in APNIC (being implemented) and is
> > under discussion in the LACNIC and AFRINIC regions. It has also been
> > submitted to RIPE (still not published).
> >
> > Example of the validation procedure.
> >
> > 1. ARIN initiates the validation automatically, sending TWO consecutive
> > emails to the “abuse-mailbox”.
> >
> > 2. These emails will be sent containing plain text only.
> >
> > 3. The first email will contain the URL where the validation is to be
> > performed (“validation.arin.net”) and may contain information about the
> > procedure, a brief summary of this policy, etc.
> >
> > 4. The second email will contain a unique alphanumeric validation code.
> >
> > 5. 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.
> >
> > 6. 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.
> >
> > 7. The alphanumeric code will only be valid for a maximum of 15 working
> > days.
> >
> > 8. If the code is not entered within that time, the system will mark the
> > “abuse-c” as “temporarily invalid” and will alert ARIN staff so that
> > they can initiate a personalized follow-up with the LIR.
> >
> > 9. 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”.
> >
> > 10. Once the issue has been resolved, the validation process will be
> > repeated automatically (items 1 to 7 above). If satisfactory, the
> > “abuse-c” will be marked as “valid”; otherwise it will be considered in
> > breach of the policy.
> > _______________________________________________
> > ARIN-PPML
> > You are receiving this message because you are subscribed to
> > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> > Unsubscribe or manage your mailing list subscription at:
> > https://lists.arin.net/mailman/listinfo/arin-ppml
> > Please contact info at arin.net if you experience any issues.
>
>
>
> --
> "Catch the Magic of Linux..."
> ------------------------------------------------------------------------
> Michael Peddemors, President/CEO LinuxMagic Inc.
> Visit us at http://www.linuxmagic.com @linuxmagic
> A Wizard IT Company - For More Info http://www.wizard.ca
> "LinuxMagic" a Registered TradeMark of Wizard Tower TechnoServices Ltd.
> ------------------------------------------------------------------------
> 604-682-0300 Beautiful British Columbia, Canada
>
> This email and any electronic data contained are confidential and intended
> solely for the use of the individual or entity to which they are addressed.
> Please note that any views or opinions presented in this email are solely
> those of the author and are not intended to represent those of the company.
> _______________________________________________
> ARIN-PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> https://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.
>


-- 
Jo Rhett
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20190328/899bc073/attachment.htm>