Thanks to George I saw the recording of policy webinar, Hi vivek, can you share more details about the incident where an operator gave a reason to create a ROA with private ASN?
RFC1930 - Guidelines for creation of an AS - Section 10 Reserved AS Numbers The Internet Assigned Numbers Authority (IANA) has reserved the following block of AS numbers for private use (not to be advertised on the global Internet): RFC6996 - Autonomous System (AS) Reservation for Private Use - Section 4. Operational Considerations If Private Use ASNs are used and prefixes originate from these ASNs, Private Use ASNs MUST be removed from AS path attributes (including AS4_PATH if utilizing a four-octet AS number space) before being advertised to the global Internet. Regards, Aftab A. Siddiqui On Tue, 21 Feb 2023 at 22:43, Satoru Tsurumaki <stsur...@gmail.com> wrote: > Dear Colleagues, > > I am Satoru Tsurumaki from Japan Open Policy Forum Steering Team. > > I would like to share key feedback in our community for prop-150, > based on a meeting we organised on 15th Feb to discuss these proposals. > > The Various opinions were expressed about this proposal. > > > (comment details) > - I support this proposal if it not cause the increasing APNIC's load. > > - I beleive that ROA and whois should be discussed separately, > since what is required for RoA and whois is different > in terms of accuracy, etc. > > - Essentially, APNIC should not allow such strange registrations. > > > Regards, > > Satoru Tsurumaki / JPOPF Steering Team > > 2023年1月30日(月) 9:55 Bertrand Cherrier <b.cherr...@mynet.nc>: > > > > > 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 (aftab.siddi...@gmail.com) > > > > > > 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/sig-policy@lists.apnic.net/ > > To unsubscribe send an email to sig-policy-le...@lists.apnic.net > _______________________________________________ > sig-policy - https://mailman.apnic.net/sig-policy@lists.apnic.net/ > To unsubscribe send an email to sig-policy-le...@lists.apnic.net
_______________________________________________ sig-policy - https://mailman.apnic.net/sig-policy@lists.apnic.net/ To unsubscribe send an email to sig-policy-le...@lists.apnic.net
