Hi Javed,

On Thu, 29 Aug 2019 at 6:33 am, Javed Khan <javedkha...@outlook.com> 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 <aftab.siddi...@gmail.com>
> *Sent:* Tuesday, 27 August 2019 6:16 PM
> *To:* Owen DeLong <o...@delong.com>
> *Cc:* Javed Khan <javedkha...@outlook.com>; Policy SIG <
> sig-pol...@apnic.net>; Sumon Ahmed Sabir <sasa...@gmail.com>
>
> *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 <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 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 <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 <
> 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>
> wrote:
>
> Hi David,
>
>
> On Fri, Aug 23, 2019 at 6:36 AM David Farmer <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>
> 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
>
>
> 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
> https://mailman.apnic.net/mailman/listinfo/sig-policy
>
>
>
> --
> ===============================================
> David Farmer               Email:far...@umn.edu
> 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
> sig-policy@lists.apnic.net
> https://mailman.apnic.net/mailman/listinfo/sig-policy
>
>
>
> --
> ===============================================
> David Farmer               Email:far...@umn.edu
> 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
> sig-policy@lists.apnic.net
> https://mailman.apnic.net/mailman/listinfo/sig-policy
>
>
>
> --
Regards,

Aftab A. Siddiqui
*              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

Reply via email to