Keyboard Shortcuts
Thread View
j: Next unread messagek: Previous unread messagej a: Jump to all threadsj l: Jump to MailingList overview
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 (aftab.siddiqui@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 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.
Hi,
I support the proposal. However, it would be cleaner to insert "(except AS0)" where necessary for clarification.
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 < sig-policy@lists.apnic.net> wrote:
Hi,
I support the proposal. However, it would be cleaner to insert "(except AS0)" where necessary for clarification. -- Matsuzaki Yoshinobu maz@iij.ad.jp
- IIJ/AS2497 INOC-DBA: 2497*629
Date: Fri, 20 Jan 2023 11:23:54 +1100 Bertrand Cherrier b.cherrier@mynet.nc 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 (aftab.siddiqui@gmail.com)
- 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.
- 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.
- Situation in other regions
ROAs containing Private and Reserved ASN are visible from APNIC, LACNIC and RIPE NCC region.
- 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.
- 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.
- Impact on resource holders
APNIC has to request members to delete existing ROAs and route/route6 objects with Private, Reserved and unallocated origin AS.
- References
None.
sig-policy - https://mailman.apnic.net/sig-policy@lists.apnic.net/ To unsubscribe send an email to sig-policy-leave@lists.apnic.net
sig-policy - https://mailman.apnic.net/sig-policy@lists.apnic.net/ To unsubscribe send an email to sig-policy-leave@lists.apnic.net
Hi, I support this proposal.
Regards/Jahangir
On Fri, Jan 20, 2023 at 6:24 AM Bertrand Cherrier b.cherrier@mynet.nc 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 (aftab.siddiqui@gmail.com)
- 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.
- 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.
- Situation in other regions
ROAs containing Private and Reserved ASN are visible from APNIC, LACNIC and RIPE NCC region.
- 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.
- 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.
- Impact on resource holders
APNIC has to request members to delete existing ROAs and route/route6 objects with Private, Reserved and unallocated origin AS.
- References
None.
sig-policy - https://mailman.apnic.net/sig-policy@lists.apnic.net/ To unsubscribe send an email to sig-policy-leave@lists.apnic.net
Activity Summary
- 134 days inactive
- 134 days old
- sig-policy@lists.apnic.net
- 4 participants
- 3 comments