[dns-wg] "mnt-domains:" Attribute Proposal

[Olaf Kolkman <]

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@localhost 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