Hi Javed, On Thu, 29 Aug 2019 at 6:33 am, Javed Khan <[email protected]> wrote:
> We may think we are living in a perfect world but we are not. > of course With this proposal I'm more worried about the network downtime as managing > an AS0 ROA by an RIR may be prone to errors as we all do regardless if its > a manual or automated solution. > Would you like to explain how AS0 ROA can create network downtime? Operators network downtime doesn't have any effect on APNIC business as > they can simply say we stuffed up and fixing it. > > But think about those networks facing the downtime and their business > obligations to their customers, who will bear this liability. Sure these > operators can drag APNIC to the courts but that costs money that they > cannot afford but accept the stuff ups. > Still you don’t understand how AS0 ROA works and what this policy is trying to address. If a network operator is using a Bogon (unallocated address space) then trust me mate that network has no chance defending that case in any court. In fact APNIC should be dragging these network operators to court. > So I am not in favor of asking the RIR to create AS0 ROA. > Thats absolutely fine we can agree to disagree but let’s have a clear understanding of the policy. > J Khan > > ------------------------------ > *From:* Aftab Siddiqui <[email protected]> > *Sent:* Tuesday, 27 August 2019 6:16 PM > *To:* Owen DeLong <[email protected]> > *Cc:* Javed Khan <[email protected]>; Policy SIG < > [email protected]>; Sumon Ahmed Sabir <[email protected]> > > *Subject:* Re: [sig-policy] prop-132-v002: AS0 for Bogons > > 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 <[email protected]> > 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 VALIDATED/GOOD. > > 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? > > For Example, > - APNIC creates AS-0 ROA for 103.8.194.0/24 (This is an unallocated > prefix announced AS135754, a bogon). > - If I'm doing ROV then this prefix (103.8.194.0/24) 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. > > 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. > > > 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 > > "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. > > > > You can also check prefix 103.114.191.0/24 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. > > 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. > > > > 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 :) > > > > Owen > > > Regards, > > Aftab A. Siddiqui > > > On Sat, Aug 24, 2019 at 12:29 AM Javed Khan <[email protected]> > 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:* [email protected] < > [email protected]> on behalf of David Farmer < > [email protected]> > *Sent:* Friday, 23 August 2019 10:48 AM > *To:* Aftab Siddiqui <[email protected]> > *Cc:* Sumon Ahmed Sabir <[email protected]>; Policy SIG < > [email protected]> > *Subject:* Re: [sig-policy] prop-132-v002: AS0 for Bogons > > > > On Thu, Aug 22, 2019 at 9:04 PM Aftab Siddiqui <[email protected]> > wrote: > > Hi David, > > > On Fri, Aug 23, 2019 at 6:36 AM David Farmer <[email protected]> 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 <[email protected]> > 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 > [email protected] > > > 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 > [email protected] > https://mailman.apnic.net/mailman/listinfo/sig-policy > > > > -- > =============================================== > David Farmer Email:[email protected] > Networking & Telecommunication Services > Office of Information Technology > University of Minnesota > 2218 University Ave SE > <https://www.google.com/maps/search/2218+University+Ave+SE?entry=gmail&source=g> > Phone: 612-626-0815 > Minneapolis, MN 55414-3029 Cell: 612-812-9952 > =============================================== > * sig-policy: APNIC SIG on resource management policy > * > _______________________________________________ > sig-policy mailing list > [email protected] > https://mailman.apnic.net/mailman/listinfo/sig-policy > > > > -- > =============================================== > David Farmer Email:[email protected] > Networking & Telecommunication Services > Office of Information Technology > University of Minnesota > 2218 University Ave SE > <https://www.google.com/maps/search/2218+University+Ave+SE?entry=gmail&source=g> > Phone: 612-626-0815 > Minneapolis, MN 55414-3029 Cell: 612-812-9952 > =============================================== > > * sig-policy: APNIC SIG on resource management policy > * > _______________________________________________ > sig-policy mailing list > [email protected] > https://mailman.apnic.net/mailman/listinfo/sig-policy > > > > -- Regards, Aftab A. Siddiqui
* sig-policy: APNIC SIG on resource management policy * _______________________________________________ sig-policy mailing list [email protected] https://mailman.apnic.net/mailman/listinfo/sig-policy
