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]
