> On Aug 27, 2019, at 03:16 , Aftab Siddiqui <aftab.siddi...@gmail.com> wrote:
> Hi Owen,
> I don’t think you actually addressed his concern…
> Well, let me try again then :) 
>> On Aug 26, 2019, at 17:17 , Aftab Siddiqui <aftab.siddi...@gmail.com 
>> <mailto:aftab.siddi...@gmail.com>> wrote:
>> Hi Javed,
>> I understand your concern, let me try to explain.
>> AS-0 ROA is an attestation by the holder of a prefix that the prefix 
>> described in the ROA, and any more specific prefix, should not be used in a 
>> routing context. The route validation consider a "valid" outcome if "ANY" 
>> ROA matches the address prefix and origin AS, even if other valid ROAs would 
>> provide an "invalid" validation outcome if used in isolation.  Since, its 
>> not possible to generate a prefix with AS-0 there fore it is not possible 
>> that valid ROA will impact the routing of a prefix even if there is an AS-0 
>> ROA for that prefix. Also, AS 0 ROA has a lower relative preference than any 
>> other ROA that has a routable AS.  
> Presumably, APNIC would withdraw/invalidate any other ROA for the prefix (or 
> its subordinates) at or before the time when they would issue an AS-0 ROA.
> Revoking the previously valid ROAs moves the prefix from VALIDATED/GOOD to 
> UNVALIDATED/UNKNOWN status in any route validator. This would not affect the 
> routing table in most cases since there won’t be a validated route (in this 
> instance) to supersede the UNVALIDATED/UNKNOWN route which was previously 
> Issuing the AS-0 ROA would subsequently move the prefix from VALIDATED/GOOD 
> or UNVALIDATED/UNKNOWN status to INVALID/KNOWN status, thus causing most 
> validating routers to discard the route.
> There are only few reasons why APNIC would remove a valid ROA from member's 
> account.
> - Due to Non-payment and APNIC reclaiming the resources and closing the 
> account
> - Returned address space by the member for any reason and the space becomes 
> part of free pool. 
> In either case there are some cooling off period as I shared in previous 
> email which goes up to 60 days before APNIC can mark those resources as 
> free/available. IMO, there is absolutely no reason to have those ROAs in 
> place but again this is an operational issue and this policy is not dealing 
> with it. But can you suggest any reason when those ROAs should not be removed?

What if the payment status is in dispute?
There are likely other scenarios that haven’t been considered.

My point is not to claim that the current process is unacceptable. My point is 
that in order to consider whether or not this proposal has unintended 
consequences, we need a clear statement from staff how ROAs would be treated 
with this policy in place in these various situations to conduct a useful 
evaluation of the consequences in question.

I agree that these are operational matters, but they are operational matters 
that affect the outcome of this policy in a very real and potent way that is 
unique to this particular policy. Most policies do not enable staff actions 
that can disrupt routing. This one potentially does. I’m not saying that’s a 
bad thing, but I am saying that the community as a whole should get the 
information from staff about the implementation details and then evaluate those 
impacts very carefully before passing judgment on the policy proposal.

>> For Example,
>> - APNIC creates AS-0 ROA for <> (This is 
>> an unallocated prefix announced AS135754, a bogon).
>> - If I'm doing ROV then this prefix ( <>) 
>> will become invalid for me because it doesn't have a valid ROA. Anyone not 
>> doing ROV or any other form of bogon filtering will still accept this prefix 
>> and keep on treating it as normal.
>> - Now, APNIC delegates this prefix to someone else after some time (remember 
>> the AS-0 ROA still exist). That someone is AS139038 (myself).
>> - Because this prefix is now under my administration I can create ROA with 
>> my own ASN i.e. AS139038
>> - Before delegating the prefix to me APNIC should have delete that AS-0 ROA 
>> but lets assume they forgot to do so or some technical glitch happened and 
>> the AS-0 ROA still exist for this prefix even after delegating it to me
>> - Since I have created a ROA with my ASN i.e. AS139038 then the validators 
>> will mark the prefix originating from my ASN as valid even though there is 
>> an AS-0 ROA for that prefix. 
> Different example:
> APNIC issues 2001:db8:feed::/48 to XYZ Corp. who creates a ROA for AS65551.
> If you’re doing ROV, then this prefix 2001:db8:feed::/48 is validated 
> assuming you receive the route with an AS PATh that matches "* 65551 $”.
> Subsequently, XYZ Corp forgets to pay their APNIC invoice and APNIC revokes 
> the space.
> Under current policy, APNIC Simply deletes the ROA and anyone doing ROV no 
> longer sees 2001:db8:feed::/48 as valid, but they don’t see it as invalid. It 
> moves to unknown.
>       In the current (and foreseeable future) world, and unknown route is 
> probably still going to be accepted by the vast majority of peers, so this 
> has little effect on routing.
> Under the proposed policy, at some point, APNIC issues a new ROA for 
> 2001:db8:feed::/48 tied to AS0.
> This has two effects that are not present in the current situation:
>       1.      The route with origin AS6551 is no tagged as “Invalid” — There 
> is no matching VALID ROA since they were all revoked by the RIR.
>       2.      Most peers doing ROV will likely drop the prefix. While unknown 
> prefixes are not likely dropped, known invalid prefixes are a different 
> matter and
>                       even though some ROV operators will not drop them 
> today, more and more will sooner rather than later.
> This means that the RIR now has much greater direct power over influencing 
> routing decisions than in the pre-RPKI/ROV days.
> This policy is addressing only one thing "Control Bogon Announcements". If 
> the XYZ Corp hasn't paid the due fees (even after several reminders which are 
> in place by the RIR and after the cooling off period as per the operational 
> practice of RIR) then XYZ Corp doesn't have the right to use 
> 2001:db8:feed::/48 and APNIC will mark those resources as free/available. The 
> policy deals with the resources part of free/available pool, how they become 
> part of that pool is not part of this policy and its an operational issue. 

See above about billing disputes.

> Today, a terminated member can keep on using the resources without any 
> consequences unless APNIC reach out to them (which doesn't work at times) or 
> their upstream and tell them to stop advertising it. 

Yes… I’m not sure whether that’s truly a bad thing in all cases. We can agree 
to disagree about this, but the reality is that today, the RIRs are a 
convenience for guaranteeing uniqueness. This policy proposal moves them from a 
convenient way to register uniqueness to a routing policy enforcement role.

I don’t know for sure whether that is good or bad and really, mine is not the 
most important judgment on that question anyway. However, I will say that I 
think the community should consider that question very carefully before moving 
this policy forward.
> I’m not saying whether this is good or bad (who am I to judge at this point), 
> but I am saying it’s a valid concern and a huge potential operational 
> consequence
> of this proposed policy.
> I'm still unable to see that as a concern, XYZ Corp has to pay the fees to 
> use those resources. Its part of the membership agreement they signed

XYZ Corp has to pay the fees to keep the resources registered to them in the 
database. It’s part of the membership agreement they signed. I don’t know if 
the membership agreement they signed specifically precludes them from using 
those (or any other resources not registered to them) on the internet outside 
of APNIC’s purview. I’m pretty sure that’s not actually a provision in most of 
the RIR’s service agreements. I’m almost certain it’s not a provision in the 

Until now the system has functioned with the RIRs operating as registries for 
uniqueness and cooperating ISPs enforcing that uniqueness to the extent it gets 
enforced (which is admittedly rather lax). There are many options for 
tightening that up, but in the current situation, it has the ISPs acting as a 
check and balance against the RIRs acting contrary to the interests of the 
community. While I’m not saying that the RIRs are evil or would necessarily do 
so, I am saying that institutions with unchecked power are not historically 
known for remaining good very long after the checks and balances on their power 
are removed.

This policy proposal potentially significantly erodes part of those checks and 
balances by moving part of the decision on honoring advertisements of expired 
resources out of the hands of some ISPs and into the hands of the RIRs.

> "3.2 The Member must: Promptly pay all fees and charges due to the Company in 
> accordance with the Fee Schedule"
> But again this is not part of the policy.

But what is the member paying the fees for… Are they paying the fees for the 
right to use the numbers on the internet? I bet not as I don’t see any way that 
APNIC could actually sell that service or live up to those terms. No, instead, 
they are paying fees to maintain a registration of uniqueness of those numbers 
as being under their purview in a particular database (or set of databases). 
That’s a service APNIC can and does provide.

>> You can also check prefix <> via any 
>> validator you are running which has both AS-0 ROA (created by them) and also 
>> a ROA with their routable ASN (AS397702). Many operators have created AS-0 
>> ROAs along side the ROA with their own routable ASN. 
> Yes, but this doesn’t cover the case Javed expressed concern about.
>> I hope this helps answer you concern. Please let me know if you still have 
>> any question.
> Even if Javed is somehow satisfied with your answer, I think that we need a 
> detailed explanation from staff how this policy would be implemented and
> what measures would be taken to avoid the erroneous (and potentially 
> disastrous) combination of revocation of all previous ROAs and issuance of
> an AS-0 ROA.
> The policy doesn't talk about revocation of resources and subsequent ROAs 
> associated with it and its mechanism. Fee schedule, Revocation and membership 
> termination/cancelation is part of the membership agreement and how APNIC 
> executes the revocation is the operational issue of the APNIC. 

No, but it _DOES_ affect the outcome of all of those circumstances in a rather 
large and graphic way that is previously unprecedented on the internet. If you 
cannot see that, then you really are not thinking this through adequately.

> Also, a clear description of the timelines for how non-payment/cancellation 
> would be handled in terms of when ROAs would be revoked
> and when the AS-0 ROA would be issued for a reclaimed block in relation to 
> the revocation of previous ROAs and in relation to the invoice due date.
> I hope that’s a clear enough expression.
> I will leave that for APNIC to respond and its a fair enough concern that a 
> clarity is needed.

Thank you. I’m sure staff will respond promptly. I suspect it will take them 
some time to formulate a thorough response and they may well be scrambling to 
pull together procedures and documentation needed to address it as we type. I’m 
sure it falls into the category of “Answer requires thought” for them.

> That is my current question about this proposal. I am sure Javed will speak 
> up if it doesn’t also reflect his question/concerns.
> I once again tried to answer your questions and happy to hear from Javed as 
> well :)

Thanks. Hopefully you now understand my concerns about the implications beyond 
the policy text that go with implementation and how they are related.


> Owen
>> Regards,
>> Aftab A. Siddiqui
>> On Sat, Aug 24, 2019 at 12:29 AM Javed Khan <javedkha...@outlook.com 
>> <mailto:javedkha...@outlook.com>> 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 
>> <mailto:sig-policy-boun...@lists.apnic.net> 
>> <sig-policy-boun...@lists.apnic.net 
>> <mailto:sig-policy-boun...@lists.apnic.net>> on behalf of David Farmer 
>> <far...@umn.edu <mailto:far...@umn.edu>>
>> Sent: Friday, 23 August 2019 10:48 AM
>> To: Aftab Siddiqui <aftab.siddi...@gmail.com 
>> <mailto:aftab.siddi...@gmail.com>>
>> Cc: Sumon Ahmed Sabir <sasa...@gmail.com <mailto:sasa...@gmail.com>>; Policy 
>> SIG <sig-pol...@apnic.net <mailto: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;
>> Upon de-reregistration any existing ROAs are removed from RPKI
>> 30 days after de-registraion, AS0 ROAs are created except for non-payment 
>> fees
>> 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 
>> <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 
>> 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 
>> <https://tools.ietf.org/rfc/rfc6483.txt>
>> RFC6491 - https://tools.ietf.org/rfc/rfc6491.txt 
>> <https://tools.ietf.org/rfc/rfc6491.txt>
>> RFC7607 - https://tools.ietf.org/rfc/rfc7607.txt 
>> <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 
>> <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 
>> <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 
>> <https://mailman.apnic.net/mailman/listinfo/sig-policy>
*              sig-policy:  APNIC SIG on resource management policy           *
sig-policy mailing list

Reply via email to