Maz san, valid point - though I listed the reserved ASN but it's good to
explicitly mention that AS0 is exempted from this policy. If I don't hear
any more suggestion to change then I will update the text as below:

-----
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 AS 0 is reserved by
the IANA such that it may be used to identify non-routed networks (RFC6483
Sec 4).

-----


Regards,

Aftab A. Siddiqui


On Fri, 20 Jan 2023 at 13:58, Matsuzaki Yoshinobu via sig-policy <
[email protected]> wrote:

> Hi,
>
> I support the proposal. However, it would be cleaner to insert
> "(except AS0)" where necessary for clarification.
> --
> Matsuzaki Yoshinobu <[email protected]>
>  - IIJ/AS2497  INOC-DBA: 2497*629
>
> Date: Fri, 20 Jan 2023 11:23:54 +1100
> 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]
>
_______________________________________________
sig-policy - https://mailman.apnic.net/[email protected]/
To unsubscribe send an email to [email protected]

Reply via email to