[arin-ppml] Draft Policy ARIN-2019-5: Validation of Abuse-mailbox
JORDI PALET MARTINEZ
jordi.palet at consulintel.es
Wed Apr 3 17:20:31 EDT 2019
Hi Marilson,
El 27/3/19 19:38, "Marilson Mapa" <marilson.mapa at gmail.com> escribió:
Hola Jordi
> I think the validation should be more exhaustive, this is one of the aspects of my proposal.
I agree, but then why do you care only about the resource-holders? What about the victims of the end users? And the victims of the LIRs?
I’m not sure to understand what you will be proposing here.
> The most important goal is to ensure that an abuse complain is really taken in consideration... ...especially for small ISPs...
In favor of whom? Why only in favour of resource-holders? What about the victims of LIRs and end-users? When an end-user practices a crime or acts in disagreement with the AUP and ToS contractual, the victim of abuse is not the ISP/LIR. The victim is the citizen because he simply has an email.
Both are victims. The end-user getting the abuse (example, spam), and the LIR connecting that customer. However, the RIRs can’t act to compensate for that to any of those, it will be up to the courts if the end-user or RIR want to get a compensation. The RIR is only able to look into the policies being followed.
I will agree that the laws say, if you allow your customers to send spam to other users, then you’re in part guilty and should compensate them *automatically*, but laws only allow you to claim for that, and then you may get a compensation. To get that, we need to ask our politicians to change laws for that. For example, now Data Protection Agencies can fine the spammer, but you still need to go to the courts to get a compensation. Law needs to evolve so once DPA fines the spammer, there is an automatic compensation for all the victims.
Again, this is nice to have, but out of the scope for the RIRs.
> Which is not right!
Wrong answer. When I wrote that most ISPs protects and hides their customers spammers and scammers, and even doesn't prohibit the customer from continuing to use the email of those who reported him with evidence, I also wrote: easy to prove. I have 1.2 GB of documents, put together over the last five years, which prove what I am claiming.
The correct answer would be: Prove! Two years as a member of the Anti-Abuse Working Group at RIPE: Every time I tried to prove, I was persecuted, insulted and blocked. The same behavior has happened in the IGF/UN at Best Practice Forum on Cybersecurity of which I am a member.
I don’t really understand how is possible that you have been persecuted, insulted and blocked in the anti-abuse WG in RIPE.
> Se before we go into a massive fatal situation, let’s work on ensure that we are all respected.
I can not see in your proposal how everyone will be respected.
By ensuring that people follow policies. If they repeatedly fail to follow them, they should be liable for that from the perspective of our community and not be able to keep using our resources.
> What do you intend to include in this policy to force ISPs to have ethical behavior as described in their AUPs and ToSs?
I'm not an IT professional. I'm an architect. I'm here to charge you an ethical attitude and respect for human beings. Is it too much to ask?
But I know that the most sensitive part of the human being is the pocket. AUPs and ToSs establish penalties and fines for end-users if they fail to comply with the contract. I then ask: Are you charging fines from reported customers without requiring behavior change to continue to collect fines? If the answer is no and there is no illicit intent to bill with the increase in Internet traffic (400 to 500 billion spam per day), then why does the denounced customer continue with the same activity?
The contractual rules established in the AUPs and ToSs are not exclusive to the person under contract. It has the same weight to the contractor. However, if the contractor does not obey his contract why not be punished. Please do not be hypocritical by suggesting hiring law firms, as ICANN, RIRs and LIRs always do: borders do not exist only for the internet.
Again, I will agree on that, but the RIR hasn’t the power to fine the end-users. We can only ask the policies to be followed.
> I just intend to make sure that abuse cases are actually processed, not ignored...
Your policy proposal regarding abuse is selective because it cares exclusively about facilitating and exonerate the LIRs. The real victims of abuse are not included in its proposal. LIRs are not the victims of the customers themselves.
All policies, called of "security", put in place (GDPR the latest) and in study (BPF-Cybersecurity IGF/UN) do not address the lack of ethics and excessive greed of ISPs. It seems that governments prefer to issue billion euros fines to tech giants who are called BAADD by The Economist than to moralize those I call GGM21C - the Great Global Mafia of the 21st Century.
Marilson
Em qua, 27 de mar de 2019 às 05:41, JORDI PALET MARTINEZ via ARIN-PPML <arin-ppml at arin.net> escreveu:
Hi Marilson,
El 27/3/19 1:34, "ARIN-PPML en nombre de Marilson Mapa" <arin-ppml-bounces at arin.net en nombre de marilson.mapa at gmail.com> escribió:
If 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, a standard abuse-c/abuse-mailbox as a pointer to the actual abuse POC, also won't solve the problem of the abuse victim.
I think the validation should be more exhaustive, this is one of the aspects of my proposal.
If the goal is to reduce costs for resource-holders (LIRs and end-users) without worrying about the victims of abuse, go ahead but you will have to listen to criticism.
The most important goal is to ensure that an abuse complain is really taken in consideration, and not automated or re-directed to a web form that is different for every ISP, which makes impossible, especially for small ISPs to develop an automated mechanism to fill-in hundreds (if not thousands) of different forms. Ideally, we should have an IETF standard to do that, and the policy should be so simple as “you must use this standard” to send/receive abuse cases, but we don’t have that. If the standard come later, we can then accommodate the policy proposal.
The reason is obvious and widely known and easy to prove. The AUPs, ToSs and ASPs, widely exposed on provider sites, are not obeyed. Most ISPs protect, hide, and make no demands on customers denounced with evidence.
Which is not right!
I am talking about an exaggerated laissez faire, total lack of ethics and disrespect to the population of the planet. Imagine IoT in the hands of such people I can only glimpse a black future. A future in which everyone loses because the internet will cease to be free.
Se before we go into a massive fatal situation, let’s work on ensure that we are all respected.
What do you intend to include in this policy to force ISPs to have ethical behavior as described in their AUPs and ToSs?
I just intend to make sure that abuse cases are actually processed, not ignored, which means that the abuse mail-box is functional and not an “always full mail-box”.
Marilson
Em ter, 26 de mar de 2019 às 16:53, ARIN <info at arin.net> escreveu:
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.
_______________________________________________ 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.
**********************************************
IPv4 is over
Are you ready for the new Internet ?
http://www.theipv6company.com
The IPv6 Company
This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it.
_______________________________________________
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.
**********************************************
IPv4 is over
Are you ready for the new Internet ?
http://www.theipv6company.com
The IPv6 Company
This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20190403/1c99c672/attachment.htm>
More information about the ARIN-PPML
mailing list