Security Implications
When IP address space is planned in terms of services, the planners associated to a particular service (Subnet Service Type) can control the resources regardless of the region that the IP space is located in. In this scenario, the regional planner (identified by ACL associated to a Subnet Group) will only be able to administer the space assigned to their region that does not have any Subnet Service Type security restrictions.
At the same time, the entity user (customer) will only be able to view and manipulate the IP resources that are allocated to them. Both CSR and entity users can only execute commands that are enabled by their associated role permissions.
Some example security scenarios:
Blocks Associated to Subnet Service Types and the Impact on a CSR
Blocks associated to a subnet service type are restricted to users that appear in the ACL of the subnet service type. If there is no ACL associated to a subnet service type, then the block is subjected to ACL restrictions of the associated subnet group.
However, if an ACL is associated to a subnet service type, the subnet service type security overrides the associated subnet group security. The most common use of security associated to a subnet service type is to enable the administration of a specialized type of resource that cannot be left to regional administrators and should be managed by system-wide administrators, such as blocks reserved for point-to-point links.
Blocks Associated to Subnet Group and the Impact on a CSR
Subnet groups are a hierarchical container that a block must be associated to. A subnet group that has an ACL associated to it restricts the CSR users that can manipulate the blocks in that subnet group, unless that subnet is associated to a subnet service type. Subnet groups are not hierarchical for security purposes. If a CSR is given access to a subnet group via ACL, that CSR may not be able to manipulate the blocks in a child subnet group, unless the ACL restriction in that child subnet group allows for it.
Subnet Security Use Cases
Use Case 1: CSR Requests a Block Allocation
This use case refers to breaking up space from within the subnet group hierarchy. The requesting user must have rights to the subnet service type associated to the source block. If security is not restricted by subnet service type, then the requesting user must have access to the associated subnet group.
Use Case 2: Entity User Requests a Block Allocation
An entity user can only request an allocation from a parent entity’s allocation and cannot request space from a subnet group. A CSR with appropriate access can attend to this request. Once the allocation is associated to the (root) entity, then an entity user can perform the request operations but only if IP space associated to the parent or root entity.
Use Case 3: CSR Moves a Block from one Subnet Group to Another
In order to move a block from one subnet group to another, the CSR must have security permissions to modify the block in the subnet group that it is located in or associated to the subnet service type ACL. The user does not have to be associated to the target subnet group in order to move it. However, if this is the case, then the user may lose access to modify the subnet after the move. This is because after the move, the user does not have ACL access to the target subnet group, and hence cannot access the block.
