Re: [sig-policy] prop-132-v002: AS0 for Bogons
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-bounces@lists.apnic.net
> <sig-policy-bounces@lists.apnic.net> on behalf of David Farmer
> <farmer@umn.edu>
> *Sent:* Friday, 23 August 2019 10:48 AM
> *To:* Aftab Siddiqui <aftab.siddiqui@gmail.com>
> *Cc:* Sumon Ahmed Sabir <sasabir@gmail.com>; Policy SIG
> <sig-policy@apnic.net>
> *Subject:* Re: [sig-policy] prop-132-v002: AS0 for Bogons
>
>
> On Thu, Aug 22, 2019 at 9:04 PM Aftab Siddiqui <aftab.siddiqui@gmail.com
> <mailto:aftab.siddiqui@gmail.com>> wrote:
>
> Hi David,
>
>
> On Fri, Aug 23, 2019 at 6:36 AM David Farmer <farmer@umn.edu
> <mailto:farmer@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
> <sasabir@gmail.com <mailto:sasabir@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.siddiqui@gmail.com <mailto:aftab.siddiqui@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:farmer@umn.edu <mailto:Email%3Afarmer@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:farmer@umn.edu <mailto:Email%3Afarmer@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
>