[dns-wg] Consequences of DOMAIN Object Authorisation Changes

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