Dear Colleagues, I am Satoru Tsurumaki from Japan Open Policy Forum Steering Team.
I would like to share key feedback from our community regarding prop-172, based on a meeting we organized on 24th Aug to discuss these proposals. Please note that this is a summary of the discussion held by 17 Japanese community members who attended the meeting, including those who actually handle abuse reports. Many concerns were expressed about this proposal. (Comment details) - Participants supported the overall objective of improving abuse handling within the Internet ecosystem. However, many questioned whether defining "abuse" belongs within APNIC's resource management policy. - Several participants noted that abuse is constantly evolving. New forms of abuse appear regularly, while existing threats change over time. A fixed policy definition could therefore become outdated quickly and reduce the flexibility needed by operators when responding to new threats. - It was also noted that some categories of abuse are highly dependent on national laws and local regulations. For example, activities that are illegal in one jurisdiction may be legal in another. Participants therefore questioned whether APNIC should define such activities consistently across the entire region. - Some participants distinguished between technically verifiable abuse (such as malware distribution, botnets, DDoS attacks, or route hijacking) and abuse that depends on legal or social interpretation (such as fraud, scams, copyright issues, or gambling-related content). While the former may be suitable for technical guidance, the latter was considered much more difficult to define objectively in policy. - Several participants expressed concern that introducing a formal definition could unintentionally narrow abuse handling by encouraging operators to focus only on predefined categories. Abuse that falls outside the policy definition might receive less attention even when operationally significant. - Rather than defining abuse through policy, several participants suggested that APNIC should develop operational guidance, best current practices, workshops, or training materials to improve abuse response while preserving operational flexibility. Regards, Satoru Tsurumaki Japan Open Policy Forum Steering Team 2026年8月10日(月) 12:21 Shaila Sharmin <[email protected]>: > Dear Colleagues, > > > A new proposal "prop-172: Defining Internet Abuse through IP Addresses" > has been sent to the Policy SIG for review. > > It will be presented at the Open Policy Meeting (OPM) at APNIC 62 on > Thursday, 10 September 2026. > > https://conference.apnic.net/62/program/program/index.html#/day/7/ > > We invite you to review and comment on the proposal on the mailing list > before the OPM. > > The comment period on the mailing list before the OPM is an important part > of the Policy Development Process (PDP). > > We encourage you to express your views on the proposal: > > · Do you support or oppose this proposal? > > · Does this proposal solve a problem you are experiencing? If so, > tell the community about your situation. > > · Do you see any disadvantages in this proposal? > > · Is there anything in the proposal that is not clear? > > · What changes could be made to this proposal to make it more > effective? > > > Information about this proposal is appended below as well as > https://www.apnic.net/community/policy/proposals/prop-172/ > > Regards > Bikram, Shaila, and Ching-Heng > > APNIC Policy SIG Chairs > > > > -------- > > > ------------------------------------------------------- > > prop-172-v001: Defining Internet Abuse through IP Addresses > ------------------------------------------------------- > > Proposer: Alban Kwan > [email protected] > > > > > 1. Problem statement > ------------------------------------------------------- > APNIC is a "steward" of Internet number resources in the Asia Pacific. That > role is widely recognised: it was reaffirmed through the 2016 IANA > stewardship transition, and NTIA, ICANN, RIPE, and LACNIC all use the same > language to describe it. 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 the categories of conduct that constitute IP address abuse; > • 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, in a way > that causes technical harm to the security, stability, or trust of the > Internet. It also includes facilitating unlawful conduct that the resource > holder has the practical and operational ability to address. This includes, > without limitation: > • distributing or hosting malware, including botnet command-and-control > infrastructure; > • originating, amplifying, or reflecting Distributed Denial of Service (DDoS) > traffic; > • 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 unlawful conduct 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. 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 retains its existing > responsibility to hold resource holders accountable for responding to and > addressing abuse. > > Note for further discussion (not operative policy text): > > 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; it's raised here for future > community discussion, alongside the related question of what notice standards > and processes (for example, for copyright, fraud, or > jurisdictionally-targeted unlawful conduct such as gambling) would be > appropriate if this definition is later used as a basis for obligations. > > > > > 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, and routing-layer categories in conduct that > APNIC's own technical infrastructure -- the Honeynet Project and DASH -- > already detects and surfaces to Members, so those categories reflect > operational reality rather than introducing novel or untested conduct. > • 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. > • Placing adjudication with the resource holder in the first instance, and > extending the definition to some content-adjacent conduct (e.g., phishing, > fraud, scam) and to jurisdiction-dependent conduct, will likely raise > community questions about who ultimately decides contested cases, and about > whether this represents a first step toward content-related enforcement. This > proposal does not resolve either question - both are raised here for > community discussion, alongside how any future obligations proposal might > address them. > > > > 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," including the phishing, fraud, and scam category and the > jurisdiction-targeting rule for other unlawful conduct described in Section > 4. 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 > > > _______________________________________________ > SIG-policy - https://mailman.apnic.net/[email protected]/ > To unsubscribe send an email to [email protected] -- -- Satoru Tsurumaki BBIX, Inc
_______________________________________________ SIG-policy - https://mailman.apnic.net/[email protected]/ To unsubscribe send an email to [email protected]
