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]
