Dear Colleagues, The RIPE NCC has proposed a number of changes to the authorisation mechanism for the creation of DOMAIN objects. (References to this project and related projects can be found at: http://www.ripe.net/reverse/rdns-project/) One of our requirements in designing the authorisation mechanism is that it is backwards compatible. However, we have identified at least one scenario where this is not the case. In section 1 below we document that scenario, give an estimate of its severity and of the operational impact for Local Internet Registries (LIRs). In section 2 we document the possible operational impact of the introduction of a mandatory "mnt-by:" attribute for DOMAIN objects. In section 3 we document the "mnt-domains:" attribute based authorisation for PI space. Please send any comments on these or other operational impacts of the proposed DOMAIN object authorisation change to the author or the DNS Working Group mailing list. In this text 'INETNUM object' is used to indicate network objects and to represent both IPv4 INETNUM and IPv6 INET6NUM objects. Section 1: Blocking through more specific inetnums In this section DOMAIN objects refer to DOMAIN objects that represent names in the reverse address name space. Currently the authorisation for the creation or deletion of DOMAIN objects is based on the request being filed by an LIR that made an assignment for the relevant address space. Example: An LIR has been allocated a /19, a /22 has been assigned to a customer. Both the /19 and /22 are represented by INETNUM objects in the Whois Database. Currently the LIR can request reverse delegation for the 4 reverse domains that live under the assigned /22. The authorisation is only based on the RegID in the request, and some heuristic checks. Currently the maintainer attributes in both the INETNUM objects are irrelevant in the authorisation. In the new proposal this will change. The authorisation will be based on the "mnt-domains:" attribute in the smallest less specific INETNUM object. If the "mnt-domains:" attribute does not exist, the authorisation will 'cascade' from "mnt-lower:" to the "mnt-by:" attributes. This may lead to the "mnt-by:" attribute on the smallest less specific inetnum preventing an LIR from creating a delegation, which is backwards incompatible. Example: Using the same situation as above. Consider the INETNUM object for a /19 allocation has a "mnt-by:" attribute containing Maintainer A and a "mnt-lower:" attribute containing Maintainer B. There also exists a /22 that is assigned out of the /19. The INETNUM object for that assignment only contains a "mnt-by:" attribute with Maintainer B. The LIR will now only be able to create a DOMAIN object for a /24 space under the /22 if they have access to Maintainer B credentials. We have tried to assess how often an LIR uses different maintainers for the allocations, assignments and related DOMAIN objects. Our estimate (see appendix) is that in 15% of the cases there are differences. Our explanation for a large number of cases where the maintainers differ is that the LIR has delegated the responsibility to maintain address space and relevant reverse space to their customers. In those cases the LIR will not be able to create or delete DOMAIN objects themselves but their customers will be able to. When problems are experienced there is a possible work around. If there is a need for the LIRs to maintain the reverse space for the /22 in the example above, the customer could add a "mnt-domains:" attribute containing both Maintainer A and B. This would, off course, involve customer co-operation. Section 2: Making "mnt-by:" a mandatory attribute in DOMAIN objects This change has been proposed to raise the overall security of the Whois Database. Since the database will be used as an authoritative source for the creation of zone files it is important that users consciously add maintainers to their objects, thereby making the choice about the level of authorisation they want to use to protect their objects. The operational impact of this is that users will have to adapt their processes and/or software to add "mnt-by:" attributes and make sure that, when created or modified, the objects are submitted with the credentials that belong to the maintainer referenced in the "mnt-by:" attribute. Having a proper maintainer with sufficient protection will protect users from "object theft", which would, in the future setup, translate to "DNS delegation theft". Note that people who do not have a "mnt-by:" attribute on their DOMAIN object will be able to change or delete the object. However, when the object is changed a "mnt-by:" attribute will have to be added. Section 3: "mnt-domains:" based authorisation and PI space The logic of the authorisation mechanism means that, in the absence of a "mnt-domains:" attribute, the creation of a delegation is blocked by the "mnt-lower: RIPE-NCC-HM-PI-MNT" attribute. In order to be able to request reverse delegation space without further human intervention, the users of PI space now have to add a "mnt-domains:" attribute to their INETNUM objects. The majority of INETNUM objects that represent PI space assigned after 1997 contain a "mnt-by:" attribute that points to a maintainer associated with the address space user. For users of PI space that do not have such a "mnt-by:" attribute the situation is more problematic. They will have to contact an LIR to request the addition of the "mnt-by:" and "mnt-domains:" attributes. The details of that procedure are out of the scope of this document. Appendix: Estimate of different maintainers The sample scanned was 10% of the size of the total number of objects in the RIPE Database. From the sample we deduce that out of all INETNUM objects ~15% have a "mnt-lower:" attribute that is different to the "mnt-by:" attribute in one of its child INETNUM objects. These objects are maintained by ~8% of the maintainers that currently exist in the RIPE Database. --------------- Olaf Kolkman New Projects Group Can Bican Software Engineering Department RIPE NCC