Thanks, Sunny! This is very helpful.
Given the potential for this to produce outages, I’d like to propose that APNIC consider an additional step in the process. I think there should be a way for a resource holder (or former resource holder) to log in to the APNIC web site and trigger a suspension of the AS0 ROA for any of their prefixes until the matter can be reviewed by staff during business hours. For reasonable protection, I think this should only be available for prefixes that received AS0 ROA status within the preceding 10 days and only once. Staff would review any such suspensions during their next regular work period and make a determination to either extend the suspension for further investigation and work with the resource holder in question, uphold the AS0 status, or restore the resources to the resource holder. I think this would provide a useful safety net to networks that could be adversely impacted by this. It does provide a very short window in there is a very limited potential for abuse (someone who had their resources revoked could, theoretically get up to a 72 hour reprieve), but I think that’s pretty low risk in the grand scheme of things. Owen > On Aug 29, 2019, at 21:42 , Srinivas Chendi <su...@apnic.net> wrote: > > Hi all, > > If this proposal reaches consensus and endorsed by the APNIC EC, this is > how we would implement the policy. > > **Creation of AS0 (Zero) ROA > - Based on the publicly available “delegated-apnic-extended-latest” > stats file at https://ftp.apnic.net/stats/apnic/ > - All resources (IPv4 and IPv6) flagged as “Available” and “Reserved” > will be added to the AS0 ROA. > - On average 15 records are updated in the > “delegated-apnic-extended-latest" file daily. > - AS0 ROA will be updated at the same time as resource (IPv4 and IPv6) > delegation to exclude these prefixes. > - Relying party will see the changes when the propagation of updated AS0 > ROA is completed and this may take up to 24 hours. > - As a reference, the default sync periods of some relying party > validation tools are as follows: > > - RIPE validator v2: every hour > - RIPE validator v3: every 10 minutes > - Routinator: every hour > - rcynic: every hour > > **Account closure > - APNIC makes extensive effort to contact the Member > - If all efforts failed, APNIC will decide to terminate and reclaim all > resources delegated to that member. At the same time/day all whois > objects for that account will be deleted. > - “delegated-apnic-extended-latest” stats file is updated within 24hours > to flag the reclaimed resources as “Reserved” > - Reclaimed resource prefixes will be added to the AS0 ROA at the time > of reclamation. > - If the closed member created any ROAs these will be deleted at the > time of reclamation. > > **Account reactivation > - If the APNIC Member reactivates the account within 3 months from the > account closure, APNIC will re-delegate the reclaimed resources and > reinstates whois objects and ROAs. > - “delegated-apnic-extended-latest” stats file is updated within 24hours > to flag the re-delegated resources as “Allocated or Assigned” > - At the time of reactivation, AS0 ROA will be updated to exclude the > re-delegated prefixes > > > **Clarifications requested: > > The way in which the ROAs appear in the RPKI needs to be considered. > Currently, the hierarchy involves a TA (for 0/0, ::/0, etc.), an > intermediate CA (same resource set), five further CAs (one for IANA and > one for each other RIR), and then the member CAs > > (see diagram on slide 8 of > https://conference.apnic.net/44/assets/files/APCS549/Transitioning-to-a-single-TA.pdf). > > Three possible options are: > > - have the intermediate CA issue an AS0 ROA; > - have each of the IANA/RIR CAs issue an AS0 ROA; > - construct a separate CA under each of the IANA/RIR CAs > containing the relevant unallocated resources, and have each of > those CAs issue an AS0 ROA. > > Does the community have any preference out of these three options? > > Regards > Sunny > _______________________________________________________________________ > > Srinivas (Sunny) Chendi > Senior Advisor - Policy and Community Development > > Asia Pacific Network Information Centre (APNIC) | Tel: +61 7 3858 3100 > PO Box 3646 South Brisbane, QLD 4101 Australia | Fax: +61 7 3858 3199 > 6 Cordelia Street, South Brisbane, QLD | http://www.apnic.net > _______________________________________________________________________ > > > On 27/08/2019 9:25 am, Srinivas (Sunny) Chendi wrote: >> Hi Javed, >> >> Thanks for your email and for your participation in the policy >> development process. >> >> We're consulting our experts to provide a response to your query soon. >> Please allow us sometime. >> >> Regards >> Sunny >> >> On 24/08/2019 12:28 am, Javed Khan wrote: >>> For now, I'm neither for or against this proposal. I think the >>> intention of the author is good but the implementation is not as easy >>> as is explained in the proposal. QoS is very crucial for ISPs to >>> sustain the fierce market competition and if APNIC fails to timely >>> update the AS0 ROAs, this will effect the service delivery and/or >>> network downtime. >>> >>> I request APNIC to provide a detailed review of this proposal from a >>> service and legal perspective so the community can better understand >>> the implementation, if this proposal reaches consensus. >>> >>> >>> Kind regards >>> Javed Khan >>> MSCE and CCSP >>> >>> >>> ------------------------------------------------------------------------ >>> *From:* sig-policy-boun...@lists.apnic.net >>> <sig-policy-boun...@lists.apnic.net> on behalf of David Farmer >>> <far...@umn.edu> >>> *Sent:* Friday, 23 August 2019 10:48 AM >>> *To:* Aftab Siddiqui <aftab.siddi...@gmail.com> >>> *Cc:* Sumon Ahmed Sabir <sasa...@gmail.com>; Policy SIG >>> <sig-pol...@apnic.net> >>> *Subject:* Re: [sig-policy] prop-132-v002: AS0 for Bogons >>> >>> >>> On Thu, Aug 22, 2019 at 9:04 PM Aftab Siddiqui >>> <aftab.siddi...@gmail.com <mailto:aftab.siddi...@gmail.com>> wrote: >>> >>> Hi David, >>> >>> >>> On Fri, Aug 23, 2019 at 6:36 AM David Farmer <far...@umn.edu >>> <mailto:far...@umn.edu>> wrote: >>> >>> The problem statement says; >>> >>> Bogons are defined in RFC3871, A "Bogon" (plural: "bogons") >>> is a packet >>> with an IP source address in an address block not yet >>> allocated by IANA >>> or the Regional Internet Registries (ARIN, RIPE NCC, APNIC, >>> AFRINIC and >>> LACNIC)... >>> >>> >>> So that raises a question, what about resources that are >>> deregisterd because they are returned, revoked, or otherwise >>> reclaimed, for any of a myriad of reasons, including non-payment >>> of fees? Do they become Bogons with AS0 ROAs the moment they are >>> deregistered? Later, if so when? What if there is a ROA for them >>> in the system? Are the ROAs removed, if so when? >>> >>> >>> I also had some concerns about revoked and/or reclaimed space and >>> closed account due to non payment so I asked Secretariat in advance >>> and here is the response. >>> ======= >>> APNIC membership account is classified as closed when its status is >>> flagged as ‘closed’ in APNIC’s internal system. >>> >>> 30 days - payment period upon issuance of invoice, if no payment is >>> received within this period member receives expiry notice and the >>> account status becomes 'suspended' >>> After 15 days – member receives email notification for closure >>> giving them another 15 days to pay >>> After 15 days – the status of the account becomes 'closed' and all >>> delegated resources under the account are reclaimed >>> >>> All in all members have 60 days period to pay before the status of >>> the account becomes ‘closed’. >>> ======= >>> >>> As long as the account is suspended APNIC doesn't consider those >>> resources as free/available/reclaimed and because they are not part >>> of unallocated pool thats why no need to create AS0 ROAs for such >>> resources. AS0 ROAs will be created once APNIC mark those resources >>> available and remove them from their delegation record. Now, the >>> second issue is if there is a ROA for them in the system. Because AS >>> 0 ROA has a lower relative preference than any other ROA that has a >>> routable AS then APNIC has to somehow delete the existing ROA from >>> the system. Its easy if the member account is closed and all >>> resources are reclaimed. But I leave this to APNIC to decide how >>> they are going to make that happen. >>> >>> >>> Currently, when the account is closed nothing actively makes the >>> resources unusable, accept for if you were also changing providers >>> during this timeframe, then when the new provider checks the resources >>> they will be unregistered. But most providers don't recheck the >>> registration of resources very often, if ever, other than at the time >>> of setup of service. >>> >>> With this proposal at some point, the resource will effectively become >>> unusable with nonpayment, when the AS0 ROA is created, and any ROAs >>> are removed, I'm fine with this, but it should be called out as a >>> consequence of the proposal, so no one can say they didn't realize >>> that is a consequence of the proposal. >>> >>> This proposal changes the consequences for nonpayment, that should be >>> made clear in the proposal one way or another. >>> >>> Also as Owen noted the RIRs frequently have a hold period after the >>> account is closed, resource are usually held for some period after >>> account closure and before they are reissued to a new user. >>> >>> Personally I think they should be deregistered for some amount >>> of time before the becoming Bogons and have an AS0 ROA created >>> them, also for the AS0 ROA to be effective any ROAs for these >>> deregistered resources need to be removed as well. >>> >>> >>> I would propose something like the following; >>> >>> 1. Upon de-reregistration any existing ROAs are removed from >>> RPKI >>> 2. 30 days after de-registraion, AS0 ROAs are created except >>> for non-payment fees >>> 3. 90 days after de-registraion, AS0 ROAs are created in the >>> case of non-payment fees >>> >>> Thanks. >>> >>> >>> Thanks for these suggestions but do you think the existing waiting >>> period as outlined above in APNIC's response is good enough to mark >>> them as free/unallocated? or you think additional cooling-off window >>> should be added after the account is closed? How about 30 days after >>> de-registration whether it was closed due to non-payment or >>> otherwise. >>> >>> >>> They were just suggestions, but I will note that you only discussed >>> the timing for nonpayment, resources can be returned voluntarily or >>> they can be revoked for cause, this is rare but it does happen and the >>> timing assoicated with these instances should be understood as well. >>> >>> Also, I was suggesting the AS0 ROAs should not created immediately on >>> account closure but some period of time after that, >>> >>> Right now there seems to be two phases, suspension and account >>> closure, I'm proposing a third phase resource deactivation, the >>> creation of the AS0 ROAs. I suppose account closure and resource >>> deactivation can occur simultaneously, I think they should be separate >>> as an escalating series of events. >>> Thanks >>> >>> On Thu, Aug 22, 2019 at 12:52 AM Sumon Ahmed Sabir >>> <sasa...@gmail.com <mailto:sasa...@gmail.com>> wrote: >>> >>> Dear SIG members >>> >>> A new version of the proposal "prop-132: AS0 for Bogons" >>> has been sent to the Policy SIG for review. >>> >>> Information about earlier versions is available from: >>> http://www.apnic.net/policy/proposals/prop-132 >>> >>> You are encouraged to express your views on the proposal: >>> >>> - Do you support or oppose the proposal? >>> - Is there anything in the proposal that is not clear? >>> - What changes could be made to this proposal to make it >>> more effective? >>> >>> Please find the text of the proposal below. >>> >>> Kind Regards, >>> >>> Sumon, Bertrand, Ching-Heng >>> APNIC Policy SIG Chairs >>> >>> >>> >>> ---------------------------------------------------------------------- >>> >>> prop-132-v002: AS0 for Bogons >>> >>> >>> ---------------------------------------------------------------------- >>> >>> Proposer: Aftab Siddiqui >>> aftab.siddi...@gmail.com <mailto:aftab.siddi...@gmail.com> >>> >>> >>> 1. Problem statement >>> -------------------- >>> Bogons are defined in RFC3871, A "Bogon" (plural: "bogons") >>> is a packet >>> with an IP source address in an address block not yet >>> allocated by IANA >>> or the Regional Internet Registries (ARIN, RIPE NCC, APNIC, >>> AFRINIC and >>> LACNIC) as well as all addresses reserved for private or >>> special use by >>> RFCs. See [RFC3330] and [RFC1918]. >>> >>> As of now, there are 287 IPv4 bogons and 73 IPv6 bogons in >>> the global >>> routing >>> table. In the past, several attempts have been made to >>> filter out such >>> bogons >>> through various methods such as static filters and updating >>> them >>> occasionally >>> but it is hard to keep an up to date filters, TeamCymru and >>> CAIDA >>> provides full >>> bogon list in text format to update such filters. TeamCymru >>> also >>> provides bogon >>> BGP feed where they send all the bogons via a BGP session >>> which then can be >>> discarded automatically. Beside all these attempts the issue >>> of Bogon >>> Advertisement >>> hasn't be resolved so far. >>> >>> >>> 2. Objective of policy change >>> ----------------------------- >>> The purpose of creating AS0 (zero) ROAs for unallocated >>> address space by >>> APNIC >>> is to resolve the issue of Bogon announcement. When APNIC >>> issues an AS0 >>> ROA for >>> unallocated address space under APNIC’s administration then >>> it will be >>> marked as >>> “Invalid” if someone tries to advertise the same address >>> space. >>> >>> >>> Currently, in the absence of any ROA, these bogons are >>> marked as >>> “NotFound”. Since >>> many operators have implemented ROV and either planning or >>> already >>> discarding “Invalid” >>> then all the AS0 ROAs which APNIC will create for >>> unallocated address >>> space will be >>> discarded as well. >>> >>> 3. Situation in other regions >>> ----------------------------- >>> No such policy in any region at the moment. >>> >>> >>> 4. Proposed policy solution >>> --------------------------- >>> APNIC will create AS0(zero) ROAs for all the unallocated >>> address space >>> (IPv4 and IPv6) >>> for which APNIC is the current administrator. Any resource >>> holder (APNIC >>> member) can >>> create AS0 (zero) ROAs for the resources they have under >>> their >>> account/administration. >>> >>> >>> A ROA is a positive attestation that a prefix holder has >>> authorised an >>> AS to originate a >>> route for this prefix whereas, a ROA for the same prefixes >>> with AS0 >>> (zero) origin shows >>> negative intent from the resource holder that they don't >>> want to >>> advertise the prefix(es) >>> at this point but they are the rightful custodian. >>> >>> >>> Only APNIC has the authority to create ROAs for address >>> space not yet >>> allocated to the members >>> and only APNIC can issue AS0 (zero) ROAs. Once they ROA is >>> issued and >>> APNIC wants to allocate >>> the address space to its member, simply they can revoke the >>> ROA and >>> delegate the address space >>> to members. (this proposal doesn't formulate operational >>> process). >>> >>> 5. Advantages / Disadvantages >>> ----------------------------- >>> Advantages: >>> Those implementing ROV globally and discarding the invalids >>> will be able >>> to discard bogons from >>> APNIC region automatically. >>> >>> Disadvantages: >>> No apparent disadvantage >>> >>> 6. Impact on resource holders >>> ----------------------------- >>> No impact to APNIC or respective NIR resource holders not >>> implementing >>> ROV. Those implementing ROV >>> and discarding the invalids will not see any bogons in their >>> routing table. >>> >>> >>> 7. References >>> ------------------------------------------------------- >>> RFC6483 - https://tools.ietf.org/rfc/rfc6483.txt >>> RFC6491 - https://tools.ietf.org/rfc/rfc6491.txt >>> RFC7607 - https://tools.ietf.org/rfc/rfc7607.txt >>> _______________________________________________ >>> * sig-policy: APNIC SIG on resource management >>> policy * >>> _______________________________________________ >>> sig-policy mailing list >>> sig-policy@lists.apnic.net >>> <mailto:sig-policy@lists.apnic.net> >>> https://mailman.apnic.net/mailman/listinfo/sig-policy >>> >>> >>> >>> -- =============================================== >>> David Farmer Email:far...@umn.edu <mailto:email%3afar...@umn.edu> >>> Networking & Telecommunication Services >>> Office of Information Technology >>> University of Minnesota >>> 2218 University Ave SE Phone: 612-626-0815 >>> Minneapolis, MN 55414-3029 Cell: 612-812-9952 >>> =============================================== >>> * sig-policy: APNIC SIG on resource management >>> policy * >>> _______________________________________________ >>> sig-policy mailing list >>> sig-policy@lists.apnic.net <mailto:sig-policy@lists.apnic.net> >>> https://mailman.apnic.net/mailman/listinfo/sig-policy >>> >>> >>> >>> -- >>> =============================================== >>> David Farmer Email:far...@umn.edu <mailto:email%3afar...@umn.edu> >>> Networking & Telecommunication Services >>> Office of Information Technology >>> University of Minnesota >>> 2218 University Ave SE Phone: 612-626-0815 >>> Minneapolis, MN 55414-3029 Cell: 612-812-9952 >>> =============================================== >>> >>> * sig-policy: APNIC SIG on resource management >>> policy * >>> _______________________________________________ >>> sig-policy mailing list >>> sig-policy@lists.apnic.net >>> https://mailman.apnic.net/mailman/listinfo/sig-policy >>> > * sig-policy: APNIC SIG on resource management policy > * > _______________________________________________ > sig-policy mailing list > sig-policy@lists.apnic.net > https://mailman.apnic.net/mailman/listinfo/sig-policy * sig-policy: APNIC SIG on resource management policy * _______________________________________________ sig-policy mailing list sig-policy@lists.apnic.net https://mailman.apnic.net/mailman/listinfo/sig-policy
