I think the problem is overstated in that a ROA authorizing origination from an 
unallocated ASN is not necessarily a security risk.

Personally, I don’t see significant benefit to this proposal. I think 
guidelines are sufficient. People who wish to violate the guidelines, well, to 
quote Mr. Bush, “I encourage my competitors to try this.”

Owen


> On Jan 29, 2023, at 16:54, Bertrand Cherrier <[email protected]> wrote:
> 
> Dear SIG members,
> 
> A new version of 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
> Chairing the best SIG of all : The APNIC Policy SIG
> 
> 
> ------------------------------------------------------------------------------------------------------
>  
> 
> prop-150-v002: 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 
> 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 why these Origin ASNs are not acceptable. AS0 (zero) is also a 
> Reserved ASN (RFC7607) but will be exempted from this restriction as AS0 is 
> reserved by the IANA such that it may be used to identify non-routed networks 
> (RFC6483 Sec 4).
> 
> - 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 MUST 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