Dear Colleagues, Following the effort to streamline reverse DNS operations [1] and make it easier for the network range users to manipulate related DOMAIN objects. We propose a new attribute, "mnt-domains:" to be added to INETNUM and INET6NUM objects. (See section A of this proposal.) In addition we propose mandatory use of the "mnt-by:" attribute in DOMAIN objects. (See section B of this proposal.) ----- A.1. The "mnt-domains:" attribute The new attribute will be used to authorise modifications to encompassed DOMAIN objects. The "mnt-domains:" attribute has the same syntax as the "mnt-lower:" attribute; the value is the maintainer name. The attribute will be optional and may have multiple values. The new template for an INETNUM object will be as follows: inetnum: [mandatory] [single] [primary/look-up key] netname: [mandatory] [single] [lookup key] descr: [mandatory] [multiple] [ ] country: [mandatory] [multiple] [ ] admin-c: [mandatory] [multiple] [inverse key] tech-c: [mandatory] [multiple] [inverse key] rev-srv: [optional] [multiple] [inverse key] status: [mandatory] [single] [ ] remarks: [optional] [multiple] [ ] notify: [optional] [multiple] [inverse key] mnt-by: [mandatory] [multiple] [inverse key] mnt-lower: [optional] [multiple] [inverse key] mnt-routes: [optional] [multiple] [inverse key] mnt-irt: [optional] [multiple] [inverse key] mnt-domains: [optional] [multiple] [inverse key] changed: [mandatory] [multiple] [ ] source: [mandatory] [single] [ ] The new template for an INET6NUM object will be as follows: inet6num: [mandatory] [single] [primary/look-up key] netname: [mandatory] [single] [lookup key] descr: [mandatory] [multiple] [ ] country: [mandatory] [multiple] [ ] admin-c: [mandatory] [multiple] [inverse key] tech-c: [mandatory] [multiple] [inverse key] rev-srv: [optional] [multiple] [inverse key] status: [mandatory] [single] [ ] remarks: [optional] [multiple] [ ] notify: [optional] [multiple] [inverse key] mnt-by: [mandatory] [multiple] [inverse key] mnt-lower: [optional] [multiple] [inverse key] mnt-irt: [optional] [multiple] [inverse key] mnt-domains: [optional] [multiple] [inverse key] changed: [mandatory] [multiple] [ ] source: [mandatory] [single] [ ] A.2. Authorisation rules based on "mnt-domains:" The authorisation rules for creation and deletion of DOMAIN objects will be changed. Maintainers listed in the appropriate "inetnum:" or "inet6num:" attributes will be able to maintain encompassed DOMAIN objects. The authorisation algorithm is documented in the diagrams available at: - http://www.ripe.net/reverse/rdns-project/create.pdf - http://www.ripe.net/reverse/rdns-project/delete.pdf - http://www.ripe.net/reverse/rdns-project/modify.pdf Below is a textual representation of these diagrams. Please note that following the Routing Policy System Security (RPSS) authorisation rules, the authorisation mechanism will fall back to the "mnt-lower:" or "mnt-by:" attributes in the absence of "mnt-domains:" attributes. In the descriptions below "authorisation succeeds" means that the algorithm exits and that the object is created, modified or deleted. "Authorisation fails" means that the algorithm exits. The "closest matching INETNUM object" is either the INETNUM object that exactly matches the address space covered by the domain in the DOMAIN object or, if there is no exact match, the smallest less specific INETNUM object. Creation: 1. If the submitted DOMAIN object does not contain "mnt-by:" the authorisation fails (see section B of this proposal). 2. Find the closest matching INETNUM object (referred to as I). 3. If (I) has "mnt-domains:" and authentication provided matches the authentication provided in "mnt-domains:" in (I), authorisation succeeds. 4. If (I) has "mnt-domains:" and authentication provided does not match the authentication provided in "mnt-domains:" in (I), go to step 8. 5. If (I) has "mnt-lower:" and authentication provided matches the authentication provided in "mnt-lower:" in (I), authorisation succeeds. 6. If (I) has "mnt-lower:" and authentication provided does not match the authentication provided in "mnt-lower:" in (I), go to step 8. 7. If authentication provided matches the authentication provided in "mnt-by:" in (I), authorisation succeeds. 8. Find the DOMAIN object that is one level less specific (referred to as D). If there is no such object authorisation fails. 9. If (D) contains "mnt-lower:" and matches the authentication provided, authorisation succeeds. 10. If (D) contains "mnt-by:" and matches the authentication provided, authorisation succeeds. 11. Authorisation fails. Modification: 1. If the submitted DOMAIN object does not contain "mnt-by:" the authorisation fails (see section B of this proposal). 2. Find the DOMAIN object currently in the database (D) that is to be modified. 3. If (D) does not contain "mnt-by:" (see section B of this proposal) 3.a. If the update is authorised using authentication provided in the "mnt-by:" attribute of the submitted object, the authorisation succeeds. 3.b. Otherwise the update fails. 4. If (D) contains "mnt-by:" and matches the authentication provided, authorisation succeeds. 5. Authorisation fails. Deletion: 1. Find the DOMAIN object (D) that is to be deleted. 2. If (D) contains "mnt-by:" and matches the authentication provided, authorisation succeeds. 3. If (D) does not contain "mnt-by:" the authentication succeeds. (see section B of this proposal). 4. Find the INETNUM object (I) that is the closest match. 5. If (I) contains "mnt-domains:" and matches the authentication provided, authorisation succeeds. 6. If (I) contains "mnt-lower:" and matches the authentication provided, authorisation succeeds. 7. If (I) contains "mnt-by:" and matches the authentication provided, authorisation succeeds. 8. Authorisation fails. A.3. Inverse queries against "mnt-domains:" attributes In addition to the new authorisation algorithm for DOMAIN objects we propose the possibility of searching for INETNUM objects that have the given maintainers in their "mnt-domains:" attributes. The inverse query flag will be '-i md', with the alternative form of '-i mnt-domains', accepting a maintainer name as the lookup key. This will return all objects whose "mnt-domains:" attributes match the query argument. An example INETNUM object with "mnt-domains:" attribute will be as follows: inetnum: 192.168.28.0 - 192.168.28.255 netname: EXAMPLE-BLK descr: An example IPv4 address space country: EU # Country is really world wide admin-c: NONE-RIPE tech-c: NONE-RIPE status: ALLOCATED UNSPECIFIED mnt-by: EXAMPLE-MNT mnt-domains: EXAMPLE2-MNT changed: ripe-dbm@ripe.net 20031121 source: RIPE ----- B. Mandatory use of the "mnt-by:" attribute in DOMAIN objects As part of streamlining the reverse DNS delegations it has become evident that the authorisation mechanism for modifying DOMAIN objects needs to be strengthened. Currently it is possible to have DOMAIN objects without "mnt-by:" attributes. This means that the objects are not protected against unauthorised changes. If the changes are submitted via the proper interface they are reflected in the DNS. A mandatory "mnt-by:" attribute will enforce conscious decisions on who is allowed to maintain a domain, enforce a conscious choice of the authorisation mechanism and will reduce the chances of misconfiguration of the authorisation mechanism. The attribute is only mandatory for DOMAIN objects that are created or modified. DOMAIN objects without "mnt-by:" attributes that currently exist in the Whois Database remain unaltered. The authorisation mechanism will treat DOMAIN objects that do not have a "mnt-by:" attribute as unprotected; anybody will be able to delete or update the object. Note that during an update of an object without a "mnt-by:" attribute, a new "mnt-by" attribute must be added. The only restriction imposed on unprotected objects is that the update needs to be authorised by the maintainer referenced from the newly added "mnt-by:" attribute. For objects that already have a "mnt-by:" attribute the authorisation is based only on the maintainer referenced in the "mnt-by:" attribute of the 'old' object. This is how the authorisation currently works. ----- Closing remarks Timeline: We plan to introduce the changes in the authorisation mechanism only after we have concluded cleanup of inconsistencies [1]. The tentative milestone for the cleanup to be finished is 1 March 2004. The implementation is planned for the beginning of April 2004. Any changes to the authorisation mechanism will be announced at least two weeks in advance. In an accompanying message entitled "Consequences of DOMAIN Object Authorisation Changes" we analyze the possible operational impact of the authorisation mechanism proposed here. [1]: Links to the original proposal and related sub-projects can be found at http://www.ripe.net/reverse/rdns-project/ We look forward to your suggestions and comments. Best Regards, -- Can Bican Software Engineering Department Olaf Kolkman New Projects Group RIPE NCC