---------------------------------------------------- prop-151-v001: Restricting non hierarchical as-set ---------------------------------------------------- Proposer: Aftab Siddiqui (aftab.siddiqui@gmail.com) 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/