-------------------------------------------------------

prop-172-v002: Defining Internet Abuse through IP Addresses
-------------------------------------------------------

Proposer: Alban Kwan
alban.kwan@trustednotifier.network


Summary of changes from v001
-------------------------------------------------------
This version responds to feedback received on the sig-policy mailing
list following the initial posting of prop-172-v001. In particular:
• "Unlawful" has been removed entirely from the operative definition
(Jonathan Brewer, Terry Sweetser). The definition no longer depends on
the legal status of conduct in any jurisdiction.
• The opening clause has been revised to the wording proposed by
Jonathan Brewer, extending the definition to attempted harm and
material risk of harm, not only completed harm.
• A new category has been added covering unauthorised or malicious
scanning, probing, intrusion, and exploitation (Jonathan Brewer).
• The "Note for further discussion" section has been expanded to
address various related issues, but not within the direct scope of
this proposal.
• The good-faith safe harbor is now explicit that it operates only
within APNIC policy and does not override or replace any liability or
protection that exists under national law.
• Supporting technical references (RFC 4084, RFC 4732, RFC 4778, RFC
4948) suggested by Jonathan Brewer and Terry Sweetser, and the Manila
Principles referenced in list discussion, have been added to the
References section.

The core, unresolved questions raised by Aftab Siddiqui and by the
Japan Open Policy Forum -- particularly how APNIC's accountability
role can be assessed without an indirect determination on the
underlying conduct, and the risk that a formal definition could narrow
attention away from abuse that falls outside it -- are acknowledged in
this version rather than resolved. They remain open items for the
proposed community working group and, where relevant, future PDPs.


1. Problem statement
-------------------------------------------------------
APNIC is a "steward" of Internet number resources in the Asia Pacific.
That role is widely recognised: it was referenced during the 2016 IANA
stewardship transition, and NTIA, ICANN, RIPE, and LACNIC all use
similar language to describe their own role. But "stewardship" only
describes what we do — coordinating the allocation of Internet number
resources. It doesn't define what a good steward actually looks like.

That raises a real question: what is a good steward? Are we a good
steward just by distributing resources correctly? Are we still a good
steward if those resources are later misused and cause harm to
Internet users?

This is a conundrum the community needs to confront as we carry out
that stewardship — especially now, as national governments regulate
the Internet more actively. The multistakeholder model needs to strike
that balance, without APNIC overreaching its role.

This is where "Internet Abuse through IP Addresses" comes in. APNIC
requires resource holders to maintain an abuse-mailbox, monitor it,
and respond to complaints. But APNIC policy never defines what "abuse"
actually means. That gap makes enforcement almost impossible, and it
is part of why practices like bulletproof hosting persist. Left
unaddressed, it also invites more government regulation — the
opposite of what the multistakeholder model is meant to achieve.

Without agreeing on what "Internet Abuse through IP Addresses" means,
the community has no shared vocabulary to even discuss the gap. This
proposal is limited to closing that definitional gap. It does not
propose new obligations, enforcement powers, or compliance mechanisms
— those are left for separate, future proposals.


2. Objective of policy change
-------------------------------------------------------
This proposal introduces a clear and explicit definition of "Internet
Abuse through IP Addresses" (or "IP address abuse") into APNIC policy
documents.
If adopted, APNIC policy would, for the first time, contain an agreed
definition of this term. That definition would:
• identify categories of conduct that constitute IP address abuse, by
way of non-exhaustive example, without limiting the definition to
only those categories;
• state how such conduct is adjudicated in the first instance, and
clarify APNIC's own role in that process; and
• be precise enough to serve as a stable foundation for any future
policy proposal on resource holder obligations.
This proposal does not aim to create any new obligation, reporting
requirement, or compliance mechanism. Section 4 does describe a
resource holder's responsibility to respond to abuse, and APNIC's role
in holding them accountable for doing so — but that responsibility
already exists under APNIC's current policy requiring resource holders
to monitor and respond to abuse reports. Whether any further
obligations should attach to this definition is left for future policy
discussion.


3. Situation in other regions
-------------------------------------------------------
All other Regional Internet Registries (RIRs) have adopted policy
requiring resource holders to maintain a registered abuse contact
(commonly "abuse-c") for their address space. None of them, however,
has defined IP address abuse at the policy level, or required resource
holders to act once they receive an abuse report.


4. Proposed policy solution
-------------------------------------------------------
The following definition is proposed for adoption into the relevant
APNIC policy document. The specific document and section would be
confirmed through community discussion; the IRT object provisions in
the APNIC Whois Database documentation are one likely location.

"Internet Abuse through IP Addresses" means the use of an IP address,
or set of IP addresses, registered to or held by an APNIC account
holder, to conduct or facilitate activity that causes, attempts to
cause, or creates a material risk of technical harm to the security,
stability, or trust of the Internet, that the resource holder has the
practical and operational ability to address. This includes, but is
not limited to:
• distributing or hosting malware, including botnet
command-and-control infrastructure;
• originating, amplifying, or reflecting Distributed Denial of Service
(DDoS) traffic;
• conducting or facilitating unauthorised or malicious scanning,
probing, intrusion, exploitation, or attempted exploitation of
networks, systems, services, or applications, including vulnerability
scanning, credential attacks, and attempts to gain unauthorised access
or execute unauthorised commands;
• deliberate or grossly negligent routing-layer abuse, including BGP
hijacking, and the use of unallocated, reserved, or squatted address
space;
• fraudulently acquiring, transferring, or sub-allocating IP address
resources to facilitate the above;
• hosting infrastructure used for phishing, fraud, scam, or the
impersonation of a legitimate entity for deceptive purposes.

Good-faith operational errors that are identified and promptly
corrected — including inadvertent routing misconfigurations — do not
constitute abuse under this definition. Nor does it constitute abuse
for conduct described above to occur on a resource holder's network at
the hands of a third party — such as a customer, user, or employee —
where the resource holder addresses that conduct promptly on being
notified of it, consistent with this definition.

Adjudication of whether reported conduct constitutes abuse rests, in
the first instance, with the resource holder. This applies where the
resource holder has been notified by a party with a legitimate basis
to report it, and has the practical ability to act. An isolated
instance of delayed or imperfect response does not, on its own,
constitute abuse under this definition; this definition is directed at
conduct and patterns of non-response, not individual lapses.

Acting in good faith to address reported conduct of this kind —
including reasonable reliance on a substantiated notice — does not
itself constitute abuse, even where the resource holder and a
complainant ultimately disagree about the conduct in question. It also
does not, on its own, create a broader monitoring obligation, or
amount to an admission of liability beyond what this definition
establishes. Resource holders are encouraged, but not required, to
retain a record of any notice received and the action taken in
response, so that good-faith reliance under this section can be
demonstrated if later disputed.

For the avoidance of doubt, APNIC does not have the power to
adjudicate abuse. As steward of Internet number resources, APNIC's
role is limited to ensuring resource holders do not neglect their
stewardship responsibility — for example, by ignoring legitimate abuse
reports in bad faith — not to determining whether any particular case
is or is not abuse.

Note for further discussion (not operative policy text):

This proposal does not aim to resolve all issues related to abuse, but
rather to come up with an agreeable definition as a foundation for
further discussion. While it is out of scope, it is important that we
also outline possible next steps as reference, so that the community
has a clear view of whether this policy would create an unintended
outcome, and how further discussion could be conducted to resolve
remaining issues.

Issues best addressed by "best practice guidelines" through a
"working group / SIG":
• Specific terminology — such as hosting, phishing, fraud, scam — is
used across other Internet policies. As these definitions may change
according to local understanding and new types of attack, it is best
that policy uses commonly understood terms, with APNIC best-practice
guidelines addressing more specific definitions.
• Responsibility and types of resource holders — responsibility for
the conduct above may reasonably differ depending on a resource
holder's registered or predominant use of its IP addresses (e.g.,
access/transit network, hosting/content provider, enterprise/
internal-use network) — consistent with existing cross-industry
practice, such as M3AAWG's separate best-practice guidance for hosting
providers versus network operators. This proposal does not resolve
how, or whether, such differentiation should be built into policy.
• Cross-jurisdiction issues — this proposal places the decision-making
power squarely with the resource holder, but to resolve practical
harm, the community may want to consider a best-practice guideline to
assist resource holders in making such decisions.
• Narrowing effect — observe whether the definition creates any
"narrowing effect" or "scope creep".
• Other cooperation to enhance abuse mitigation without placing a
policy compliance burden on the community — this proposal does not
seek to create an adjudication and APNIC policy enforcement framework.
Within the wider community, other concepts and cooperative models are
being built, and APNIC can draw on models used elsewhere in Internet
governance for bottom-up, distributed adjudication — for example, the
ICANN community's trusted notifier concept, the EU's Trusted Flagger
concept, and the Global Cyber Alliance's Domain Trust project.

Issues requiring a future Policy Development Process:
• The definition of "adequate response", and APNIC's enforcement power
and process.


5. Advantages / Disadvantages
-------------------------------------------------------
Advantages:
• Establishes a shared, technically precise vocabulary for discussing
IP-address abuse within the APNIC community, where none currently
exists.
• Gives the community a stable, narrowly scoped starting point for any
future discussion of resource holder obligations, reducing the risk
that substantive policy questions become mired in definitional
disagreements.
• Closes a real coordination gap for content-adjacent conduct (such as
phishing, fraud, and scam) that falls outside ICANN's own remit, while
keeping adjudication with the resource holder and expressly excluding
speech- and content-moderation-style complaints (e.g., misinformation,
disinformation, defamation) that would risk broader scope creep.
• Anchors the malware, DDoS, scanning/intrusion, and routing-layer
categories in conduct that is technically identifiable without
reference to any jurisdiction's law, consistent with community
feedback distinguishing technically verifiable abuse from abuse that
depends on legal or social interpretation.
• Creates no new compliance mechanism of its own; the monitoring and
response expectations described in Section 4 restate an obligation
that already exists under current APNIC policy, rather than adding a
new one.

Disadvantages:
• A definition with no attached obligation may be seen by some
community members as insufficient to address the underlying problem,
or as a procedural step that delays substantive action.
• Some categories within the proposed definition, particularly
routing-layer abuse and resource transfer fraud, may be perceived as
overlapping with existing routing security initiatives (e.g., RPKI,
MANRS) or future transfer policy discussions, requiring careful
scoping during community discussion to avoid duplication.
• Defining a term in policy, even without attached obligations, may
create community expectation that obligations will follow, potentially
generating debate disproportionate to this proposal's limited scope.
• A formal definition, even a non-exhaustive one, risks narrowing
practical abuse-handling attention toward the categories named in it,
potentially at the expense of abuse that falls outside the definition
but remains operationally significant. This concern was raised
specifically by the Japan Open Policy Forum community.
• It remains unresolved how APNIC would assess whether a resource
holder has met its responsibility to respond to abuse, in a case where
the resource holder and a complainant disagree about the underlying
conduct, without APNIC making some direct or indirect determination
about that conduct. This tension, raised by Aftab Siddiqui, is not
resolved by this proposal; it is left, along with related
cross-jurisdiction adjudication questions, for the proposed working
group and subsequent policy discussion.


6. Impact on resource holders
-------------------------------------------------------
For resource holders, what changes in practice is that the existing
duty to monitor an abuse-mailbox and respond to complaints — which
currently has no defined trigger — would for the first time apply
against an agreed definition of "abuse". Resource holders retain the
primary role in deciding whether reported conduct falls within that
definition, and are protected by the good-faith safe harbor in Section
4 for reasonable action taken on a substantiated notice, including
where that judgment is later disputed or shown to be mistaken.
Resource holders whose registered use includes web hosting, email
hosting, or content delivery are likely to see this definition engaged
more often in practice than those operating purely as access or
transit networks — though this proposal does not itself differentiate
obligations by resource holder type; that question is raised for
future discussion in the note at the end of Section 4.


7. References
-------------------------------------------------------
• APNIC, "Security at APNIC," www.apnic.net/community/security/
• APNIC, "Update on the APNIC Honeynet Network," APNIC Blog, 5
February 2024,
blog.apnic.net/2024/02/05/update-on-the-apnic-honeynet-network/
• APNIC, "How DASH helps monitor network health," APNIC Blog, 9
September 2020,
blog.apnic.net/2020/09/09/how-dash-helps-monitor-network-health/
• APNIC, "Introducing Network Vulnerability Detection in DASH," APNIC
Blog, 11 December 2025,
blog.apnic.net/2025/12/11/introducing-network-vulnerability-detection-in-dash/
• DNS Research Federation, "China and India registered ASNs lead in
malware distribution through IP addresses," 4 October 2023,
dnsrf.org/blog/china-and-india-registered-asns-lead-in-malware-distribution-through-ip-addresses/
• DNS Research Federation, "Use of Subdomain Providers Gains
Popularity as a Mechanism to Launch Phishing Attacks," 14 August 2023,
dnsrf.org/blog/use-of-subdomain-providers-gains-popularity-as-a-mechanism-to-launch-phishing/
• DNS Research Federation, "Measuring Internet Abuse through IP
addresses -- Live indicators,"
dnsrf.org/measuring-internet-abuse-through-ip-addresses---live-indicators
• American Registry for Internet Numbers, "Grant Report: Measuring
Internet Abuse via IP Addresses," 8 January 2026,
www.arin.net/blog/2026/01/08/2024-grant-report-dnsrf/
• RIPE NCC, "RIPE NCC Anti-Abuse Support -- What to Do if It Happens
to You," RIPE Labs,
labs.ripe.net/author/angela_dallara/ripe-ncc-anti-abuse-support-what-to-do-if-it-happens-to-you/
• RIPE NCC, "Top 3 Types of IP Address Abuse That Threaten IPv4
Resource Holders," RIPE Labs,
labs.ripe.net/author/vincentas-grinius/top-3-types-of-ip-address-abuse-that-threaten-ipv4-resource-holders/
• CircleID, "Looking Ahead: ICANN's Upcoming Policy on DNS Abuse
Mitigation,"
circleid.com/posts/looking-ahead-icanns-upcoming-policy-on-dns-abuse-mitigation
• Klensin, J., "Terminology for Describing Internet Connectivity," BCP
104, RFC 4084, May 2005, datatracker.ietf.org/doc/html/rfc4084
• Handley, M. and Rescorla, E., Eds., "Internet Denial-of-Service
Considerations," RFC 4732, IAB, November 2006,
datatracker.ietf.org/doc/html/rfc4732
• Kaeo, M., "Current Operational Security Practices in Internet
Service Provider Environments," RFC 4778, January 2007,
datatracker.ietf.org/doc/html/rfc4778
• "Report from the IAB Workshop on Unwanted Traffic, March 9-10,
2006," RFC 4948, datatracker.ietf.org/doc/html/rfc4948
• Manila Principles on Intermediary Liability, manilaprinciples.org/