Keyboard Shortcuts
Thread View
j: Next unread messagek: Previous unread messagej a: Jump to all threadsj l: Jump to MailingList overview
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.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 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.
--------------------------------------------------------------------
Secretariat Impact Assessment
--------------------------------------------------------------------
A similar proposal was presented at the APNIC 52 OPM and was accepted as a guideline with the understanding that it will assist APNIC account holders in not creating ROAs (Routing Origin Authorizations) with Private, Reserved, and unallocated ASN ranges. This guideline was published in December 2021.
https://www.apnic.net/about-apnic/corporate-documents/documents/resource-gui...
APNIC notes this proposal would restrict an account holder's ability to create ROAs (Routing Origin Authorizations) with private, reserved, or unallocated ASNs (Autonomous System Numbers) as listed on the IANA website, except for AS 0 (zero), which may be used to identify non-routed networks. Internet number resources visible in account holders' MyAPNIC portal can only be used to create ROAs.
https://www.iana.org/assignments/as-numbers/as-numbers.xhtml
APNIC must notify the account holder as to why the ASN used to create the ROA is unacceptable and must not renew the ROAs and route/route6 objects currently in the APNIC Whois Database. All these unacceptable objects must automatically be deleted from the APNIC Whois Database.
APNIC also needs to notify the account holder in case the Origin ASN used in creating a ROA is unallocated and/or reserved and should be removed, and the same proposed solution would apply for creating corresponding route/route6 objects in the APNIC Whois Database.
This proposal may require changes to APNIC systems and procedures. If this proposal reaches consensus and endorsed by the EC, implementation may be completed within three months.
Regards, Sunny
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 b.cherrier@mynet.nc 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 (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 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.
- 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
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.cherrier@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.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 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.
- 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
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 stsuruma@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.cherrier@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.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 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.
- 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 Aftab,
When we questioned this Member why they created the route and ROA with private ASN, they informed us that their upstream requested them to create it. It was related to some automation/security feature their upstream was using to fix routing issues.
Thanks Vivek
From: Aftab Siddiqui aftab.siddiqui@gmail.com Date: Wednesday, 22 February 2023 at 8:36 pm To: Satoru Tsurumaki stsuruma@gmail.com Cc: mailman_SIG-policy sig-policy@apnic.net Subject: [sig-policy] Re: New version: prop-150: ROA/whois object with Private,,Reserved and Unallocated (reserved/available) Origin ASN 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 <stsuruma@gmail.commailto:stsuruma@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.cherrier@mynet.ncmailto:b.cherrier@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.siddiqui@gmail.commailto: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 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.
- 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.netmailto: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.netmailto:sig-policy-leave@lists.apnic.net
Hi Aftar and all,
I am interested on this topic coz we have similar cases where our customer (using Private ASN) who advertised their own IP block to us (AS4637) via eBGP.
Thank you.
[cid:image001.jpg@01D9476E.B79A07C0]
Joseph Kenneth Arino IP Engineering, Telstra (AS4637)
From: Aftab Siddiqui aftab.siddiqui@gmail.com Sent: Wednesday, February 22, 2023 6:36 PM To: Satoru Tsurumaki stsuruma@gmail.com Cc: sig-policy sig-policy@apnic.net Subject: [sig-policy] Re: New version: prop-150: ROA/whois object with Private,,Reserved and Unallocated (reserved/available) Origin ASN
You don't often get email from aftab.siddiqui@gmail.commailto:aftab.siddiqui@gmail.com. Learn why this is importanthttps://aka.ms/LearnAboutSenderIdentification
[External Email] This email was sent from outside the organisation – be cautious, particularly with links and attachments. 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 <stsuruma@gmail.commailto:stsuruma@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.cherrier@mynet.ncmailto:b.cherrier@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.siddiqui@gmail.commailto: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 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.
- 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.netmailto: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.netmailto:sig-policy-leave@lists.apnic.net
General
Hi Joseph and Vivek, SLURM was designed for specifically this kind of use case (and others as well). A ROA with Private ASN has significance for the upstream of that particular operator and no one else. If I see a ROA with 65530 as origin but can't see that origin in the routing table then it has no value to me and will be marked as "not found", whereas if that operator created a ROA with AS4637 as origin then I can verify that route because AS65530 will be stripped once announced to other peers by AS4637, since AS4637 has the direct relation with their downstream customer they should use the SLURM file.
Please refer to RFC8416 [1] some ISPs might like to use BGP and the RPKI with private address space (see [RFC1918], [RFC4193], and [RFC6598]) or private AS numbers (see [RFC1930] and [RFC6996]). Local use of private address space and/or AS numbers is consistent with the RFCs cited above, but such use cannot be verified by the global RPKI. This motivates creation of mechanisms that enable a network operator to publish, at its discretion, an exception to the RPKI in the form of filters and additions (for its own use and that of its customers). Additionally, a network operator might wish to make use of a local override capability to protect routes from adverse actions [RFC8211], until the results of such actions have been addressed. The mechanisms developed to provide this capability to network operators are hereby called "Simplified Local Internet Number Resource Management with the RPKI (SLURM)".
[1] - RFC 8416: Simplified Local Internet Number Resource Management with the RPKI (SLURM) (rfc-editor.org) https://www.rfc-editor.org/rfc/rfc8416
Regards,
Aftab A. Siddiqui
On Thu, 23 Feb 2023 at 13:08, Arino, Joseph Joseph.Arino@team.telstra.com wrote:
Hi Aftar and all,
I am interested on this topic coz we have similar cases where our customer (using Private ASN) who advertised their own IP block to us (AS4637) via eBGP.
Thank you.
*Joseph Kenneth Arino*
IP Engineering, Telstra (AS4637)
*From:* Aftab Siddiqui aftab.siddiqui@gmail.com *Sent:* Wednesday, February 22, 2023 6:36 PM *To:* Satoru Tsurumaki stsuruma@gmail.com *Cc:* sig-policy sig-policy@apnic.net *Subject:* [sig-policy] Re: New version: prop-150: ROA/whois object with Private,,Reserved and Unallocated (reserved/available) Origin ASN
You don't often get email from aftab.siddiqui@gmail.com. Learn why this is important https://aka.ms/LearnAboutSenderIdentification
[External Email] This email was sent from outside the organisation – be cautious, particularly with links and attachments.
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 stsuruma@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.cherrier@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.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 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.
- 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
General
Hi Aftab,
Thanks. I will be attending in person the upcoming APNIC 55 Open Policy Meeting on March 1 at Sofitel Hotel. Maybe we can have more discussion on this toipic.
Thank you.
[cid:image001.jpg@01D94773.53B237A0]
Joseph Kenneth Arino IP Planning & Engineering, Telstra (AS4637) 110 Paya Lebar Road, Level 8, OneTen Paya Lebar, Singapore 409009
D +65 6370 7876 E joseph.arino@team.telstra.commailto:joseph.arino@team.telstra.com
Planned Leave (2023) : Apr. 3-6, 19 Singapore Public Holidays (2023): Apr. 7, 22; May 1; Jun 3, 29; Aug. 9, Nov. 12, Dec. 25
From: Aftab Siddiqui aftab.siddiqui@gmail.com Sent: Thursday, February 23, 2023 10:21 AM To: Arino, Joseph Joseph.Arino@team.telstra.com Cc: Satoru Tsurumaki stsuruma@gmail.com; sig-policy sig-policy@apnic.net Subject: Re: [sig-policy] Re: New version: prop-150: ROA/whois object with Private,,Reserved and Unallocated (reserved/available) Origin ASN
You don't often get email from aftab.siddiqui@gmail.commailto:aftab.siddiqui@gmail.com. Learn why this is importanthttps://aka.ms/LearnAboutSenderIdentification
[External Email] This email was sent from outside the organisation – be cautious, particularly with links and attachments. Hi Joseph and Vivek, SLURM was designed for specifically this kind of use case (and others as well). A ROA with Private ASN has significance for the upstream of that particular operator and no one else. If I see a ROA with 65530 as origin but can't see that origin in the routing table then it has no value to me and will be marked as "not found", whereas if that operator created a ROA with AS4637 as origin then I can verify that route because AS65530 will be stripped once announced to other peers by AS4637, since AS4637 has the direct relation with their downstream customer they should use the SLURM file.
Please refer to RFC8416 [1] some ISPs might like to use BGP and the RPKI with private address space (see [RFC1918], [RFC4193], and [RFC6598]) or private AS numbers (see [RFC1930] and [RFC6996]). Local use of private address space and/or AS numbers is consistent with the RFCs cited above, but such use cannot be verified by the global RPKI. This motivates creation of mechanisms that enable a network operator to publish, at its discretion, an exception to the RPKI in the form of filters and additions (for its own use and that of its customers). Additionally, a network operator might wish to make use of a local override capability to protect routes from adverse actions [RFC8211], until the results of such actions have been addressed. The mechanisms developed to provide this capability to network operators are hereby called "Simplified Local Internet Number Resource Management with the RPKI (SLURM)".
[1] - RFC 8416: Simplified Local Internet Number Resource Management with the RPKI (SLURM) (rfc-editor.org)https://www.rfc-editor.org/rfc/rfc8416
Regards,
Aftab A. Siddiqui
On Thu, 23 Feb 2023 at 13:08, Arino, Joseph <Joseph.Arino@team.telstra.commailto:Joseph.Arino@team.telstra.com> wrote: Hi Aftar and all,
I am interested on this topic coz we have similar cases where our customer (using Private ASN) who advertised their own IP block to us (AS4637) via eBGP.
Thank you.
[cid:image001.jpg@01D94773.53B237A0]
Joseph Kenneth Arino IP Engineering, Telstra (AS4637)
From: Aftab Siddiqui <aftab.siddiqui@gmail.commailto:aftab.siddiqui@gmail.com> Sent: Wednesday, February 22, 2023 6:36 PM To: Satoru Tsurumaki <stsuruma@gmail.commailto:stsuruma@gmail.com> Cc: sig-policy <sig-policy@apnic.netmailto:sig-policy@apnic.net> Subject: [sig-policy] Re: New version: prop-150: ROA/whois object with Private,,Reserved and Unallocated (reserved/available) Origin ASN
You don't often get email from aftab.siddiqui@gmail.commailto:aftab.siddiqui@gmail.com. Learn why this is importanthttps://aka.ms/LearnAboutSenderIdentification
[External Email] This email was sent from outside the organisation – be cautious, particularly with links and attachments. 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 <stsuruma@gmail.commailto:stsuruma@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.cherrier@mynet.ncmailto:b.cherrier@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.siddiqui@gmail.commailto: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 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.
- 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.netmailto: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.netmailto:sig-policy-leave@lists.apnic.net
General
General
Activity Summary
- 94 days inactive
- 94 days old
- sig-policy@lists.apnic.net
- 7 participants
- 8 comments