Hi,
I support this proposal.

Regards/Jahangir


On Fri, Jan 20, 2023 at 6:24 AM Bertrand Cherrier <[email protected]>
wrote:

> Dear SIG members,
>
> The proposal "prop-150: ROA/whois object with Private, Reserved and
> Unallocated
> (reserved/available) Origin ASN" has been sent to the Policy SIG for
> review.
>
> It will be presented at the Open Policy Meeting (OPM) at APNIC 55 on
> Wednesday, 1 March 2023.
>
> https://conference.apnic.net/55/program/schedule/#/day/10
>
> We invite you to review and comment on the proposal on the mailing list
> before the OPM.
>
> The comment period on the mailing list before the OPM is an important
> part of the Policy Development Process (PDP). We encourage you to
> express your views on the proposal:
>
>    - Do you support or oppose this proposal?
>    - Does this proposal solve a problem you are experiencing? If so,
>      tell the community about your situation.
>    - Do you see any disadvantages in this proposal?
>    - Is there anything in the proposal that is not clear?
>    - What changes could be made to this proposal to make it more effective?
>
> Information about this proposal is appended below as well as available at:
>
> http://www.apnic.net/policy/proposals/prop-150
>
> Regards,
> Bertrand, Shaila, and Anupam
> APNIC Policy SIG Chairs
>
>
> ------------------------------------------------------------------------------------------------------
>
>
>
> prop-150-v001: ROA/whois object with Private, Reserved and Unallocated
> (reserved/available) Origin ASN
>
> ------------------------------------------------------------------------------------------------------
>
>
>
> Proposer: Aftab Siddiqui ([email protected])
>
>
> 1. Problem statement
> --------------------
> Prop-138v2 was converted into a guideline with the understanding that it
> will help members to understand not to create ROA with Private, Reserved
> and unallocated ASN range. Unfortunately, there are still ROAs with
> specified ranges.
>
> Additionally, if a member creates a ROA with someone else's ASN as
> Origin and if APNIC reclaims that ASN due to any policy reason
> (non-payment, account closure etc) then this leaves a security issue for
> the member.
>
>
> 2. Objective of policy change
> -----------------------------
> Restrict APNIC members to create ROAs with private, reserved or
> unallocated ASN. Also, notify members if the Origin ASN in their ROA has
> been unallocated (reserved/available) and don't automatically renew
> those ROAs with unallocated (reserved/available) ASN.
>
>
> 3. Situation in other regions
> -----------------------------
> ROAs containing Private and Reserved ASN are visible from APNIC, LACNIC
> and RIPE NCC region.
>
>
> 4. Proposed policy solution
> ---------------------------
> Route Origin Authorisation (ROA) is an RPKI object signed by a prefix
> holder authorising origination of said prefix from an origin AS
> specified in said ROA. It verifies whether an AS is authorised to
> announce a specific IP prefix or not. ROA contains 3 mandatory fields
> Prefix, Origin AS and Maxlength.
>
> Prefix: The prefix you would like to originate from the specified ASN.
> IPv4 and IPv6 Prefixes listed under "Internet Resources" on My APNIC
> portal can be only be used here.
>
> Origin AS: The authorised ASN which can originate the "Prefix". The
> origin AS can only be from the IANA specified range and MUST not contain
> an ASN from:
>
> - 23456          # AS_TRANS RFC6793
> - 64496-64511    # Reserved for use in docs and code RFC5398
> - 64512-65534    # Reserved for Private Use RFC6996
> - 65535          # Reserved RFC7300
> - 65536-65551    # Reserved for use in docs and code RFC5398
> - 65552-131071   # Reserved
> - 4200000000-4294967294    # Reserved for Private Use RFC6996
> - 4294967295     # Reserved RFC7300
>
> And any IANA unallocated ASN. Route Management system should inform the
> member that why these Origin ASNs are not acceptable.
>
> - Same policy should be applied to corresponding route/route6 whois
> objects.
> - ROAs and route/route6 objects already in the database with Private,
> Reserved and unallocated ASN should not be renewed (after expiry) and
> deleted respectively after notifying the prefix holder.
>
> Part B - Notify in case of Origin ASN has been marked as unallocated
> (reserved/available)
>
> When a member creates a ROA with Origin ASN other than their own then
> there is a possibility that Origin ASN can be unallocated by APNIC due
> to closure of account or any other reason deemed appropriate. In this
> scenario the prefix holder should receive a notification (via email - if
> email notifications are enabled OR via myapnic portal) suggesting that
> the ROA doesn't contain valid Origin ASN and should be removed. This ROA
> should not be automatically renewed as well.
>
> This should also apply to route/route6 objects as well.
>
>
> 5. Advantages / Disadvantages
> -----------------------------
> Advantages:
> This will help APNIC members avoid mistakenly creating unnecessary ROAs
> with Private, Reserved and unallocated resources and in case of creating
> ROAs with unallocated (reserved/available) ASN this will avoid a
> security issues.
>
> Disadvantages:
> Overhead for APNIC to develop Origin AS check.
>
>
> 6. Impact on resource holders
> -----------------------------
> APNIC has to request members to delete existing ROAs and route/route6
> objects with Private, Reserved and unallocated origin AS.
>
>
> 7. References
> -------------
> None.
>
> _______________________________________________
> sig-policy - https://mailman.apnic.net/[email protected]/
> To unsubscribe send an email to [email protected]
_______________________________________________
sig-policy - https://mailman.apnic.net/[email protected]/
To unsubscribe send an email to [email protected]

Reply via email to