Hi Vivek and Anupam b, On the point that why the policy will not be enforced on the existing non-hierarchical AS-SET as mentioned in the impact section.
6. Impact on resource holders ----------------------------- APNIC has to request members to update their non hierarchical as-set as a new recommended policy. No changes will be enforced to existing non hierarchical as-set. The purpose of this policy is to make sure that no APNIC member intentionally or unintentionally create an unauthenticated AS-SET, while the existing non-hierarchical AS-SET pose security issue for AS-SET holder but it doesn't create any problem for any other resource holders. Thats why it should be informed to all resource holders that their AS-SETs are vulnerable to name collision attacks from other non-authenticated IRR databases but APNIC shouldn't delete them. Regards, Aftab A. Siddiqui On Wed, 22 Feb 2023 at 10:13, Aftab Siddiqui <[email protected]> wrote: > Hi Satoru san, > I appreciate the feedback from the JP community. I do understand some of > the points you have raised, I will be doing a detailed technical > presentation during the Routing Security SIG to discuss most of the issues > you have raised here. I would request you and other friends from the > community to attend the routing security SIG. > > Regards, > > Aftab A. Siddiqui > > > On Tue, 21 Feb 2023 at 22:43, Satoru Tsurumaki <[email protected]> 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-151, >> based on a meeting we organised on 15th Feb to discuss these proposals. >> >> Many participants support the intent of this proposal, but do not believe >> it should be discussed in Policy SIG. >> >> (comment details) >> - I agree with the purpose of the proposal, but I wonder if it is not >> something that should be discussed in the sig policy. >> >> - I think the problem is how to determine which AS number to permit. >> >> - I do not oppose this proposal, but I do not think we should have >> excessive expectations of IRR. >> >> - This proposal should be discussed globally by MANRS or others, >> not by APNIC Policy SIG. >> >> Regards, >> >> Satoru Tsurumaki / JPOPF Steering Team >> >> 2023年1月20日(金) 9:25 Bertrand Cherrier <[email protected]>: >> >> >> > >> > Dear SIG members, >> > >> > The proposal "prop-151: Restricting non hierarchical as-set" 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-151 >> > >> > Regards, >> > Bertrand, Shaila, and Anupam >> > APNIC Policy SIG Chairs >> > >> > >> > ---------------------------------------------------- >> > >> > prop-151-v001: Restricting non hierarchical as-set >> > >> > ---------------------------------------------------- >> > >> > Proposer: Aftab Siddiqui ([email protected]) >> > >> > >> > 1. Problem statement >> > -------------------- >> > An as-set (RFC 2622 Section 5.1) provides a way to document the >> > relationship between ASes which can then be publicly verified. RFC2622 >> > further defines 2 categories for as-set which can be Hierarchical or Non >> > Hierarchical. A hierarchical set name is a sequence of set names and AS >> > numbers separated by colons ‘:’ e.g. AS4826:AS-VOCUS >> > >> > Non hierarchical as-set pose a security issue where any one can create >> > an as-set without any authentication or authorisation e.g. any member >> > can create AS-FACEBOOK (if available) without authorisation from >> > Facebook. Since many peering filters are based on as-set, creating a >> > blank as-set or as-set with wrong members can cause automated filters to >> > apply empty prefix-filters to BGP session. >> > >> > >> > 2. Objective of policy change >> > ----------------------------- >> > Restrict APNIC members to create non hierarchical as-set and notify all >> > members who already have non hierarchical as-set that it is recommended >> > to move them to hierarchical as-set. >> > >> > >> > 3. Situation in other regions >> > ----------------------------- >> > - RIPE NCC has recently implemented restriction of non hierarchical >> as-set >> > - LACNIC IRR supports only hierarchical as-set >> > >> > >> > 4. Proposed policy solution >> > --------------------------- >> > APNIC members are only allowed to create hierarchical as-set. As defined >> > in the RFC2622 Section 5 "A hierarchical set name is a sequence of set >> > names and AS numbers separated by colons ":". At least one component of >> > such a name must be an actual set name (i.e. start with one of the >> > prefixes above). All the set name components of an hierarchical name >> > has to be of the same type." >> > >> > An as-set object with name AS65536:...... can only be created by the >> > maintainer of the AS65536. Therefore, this must be the only allowed >> > structure for hierarchical as-set. >> > >> > Any non hierarchical as-set can not be used as a parent to create a >> > hierarchical as-set e.g. AS-AFTAB (non hierarchical as-set) should not >> > be allowed to create AS-AFTAB:AS141384 (hierarchical as-set). >> > >> > >> > 5. Advantages / Disadvantages >> > ----------------------------- >> > Advantages: >> > This will protect members from intentional or unintentional creation of >> > as-set which already exist in other IRR databases creating name >> collision. >> > >> > Disadvantages: >> > Overhead for APNIC to notify existing non hierarchical as-set >> > maintainers about the policy update. >> > >> > >> > 6. Impact on resource holders >> > ----------------------------- >> > APNIC has to request members to update their non hierarchical as-set as >> > a new recommended policy. No changes will be enforced to existing non >> > hierarchical as-set. >> > >> > >> > 7. References >> > ------------- >> > - Thanks to Job Snijders, Nick Hilliard and other community members on >> > for providing in depth details on various platforms. >> > - RIPE db-wg proposal: >> > https://www.ripe.net/ripe/mail/archives/db-wg/2022-November/007646.html >> > - IRRd 4 update: https://github.com/irrdnet/irrd/issues/408 >> > - >> > >> https://www.manrs.org/2022/12/why-network-operators-should-use-hierarchical-as-sets/ >> > >> > >> > >> > _______________________________________________ >> > 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]
