extensions to RPSS (rfc2725)

[Engin Gunduz <]

Dear colleagues,

As I mentioned earlier in one of my mails to the list,
we are missing an extensions document to Routing Policy System
Security document(RFC 2725) which corresponds to Joao's
RPSLng draft. I have prepared a preliminary draft to fulfill
this need, which I'm attaching now.

Comments/improvements are most appreciated,
Thanks,
-engin


Engin Gunduz
RIPE NCC Database Group


----------------------------

RPSLng effort, extensions to Routing Policy System Security

Abstract

 This memo defines a set of extensions and new rules to
 Routing Policy System Security document to support IPv6
 and multicast address families.


1. Introduction
  
  RFC 2622 [1] defines the RPSL language for the IPv4 unicast
  routing protocols, and RFC 2725 [2] defines the Routing Policy
  System Security specifications to assure the integrity of the
  data contained in a routing registry. 

  This document proposes to extend Routing Policy System Security
  to enable a routing registry to handle IPv6 and multicast
  policy definitions and still assure the integrity of the data.

2. inet6num Object

  inet6num objects are used to document IPv6 address allocations and
  assignments. The dictionary definition of an inet6num object is:

   inet6num:      [mandatory]  [single]
   netname:       [mandatory]  [single]
   descr:         [mandatory]  [multiple]
   country:       [mandatory]  [multiple]
   admin-c:       [mandatory]  [multiple]
   tech-c:        [mandatory]  [multiple]
   remarks:       [optional]   [multiple]
   notify:        [optional]   [multiple]
   mnt-by:        [mandatory]  [multiple]
   mnt-lower:     [optional]   [multiple]
   mnt-routes6:   [optional]   [multiple]
   changed:       [mandatory]  [multiple]
   source:        [mandatory]  [single]

  The syntaxes of mnt-by, descr, admin-c, tech-c, remarks, notify, 
  mnt-by, changed and source attributes are as defined in RPSL [1].
  The syntax of mnt-lower attribute is as defined in RPSS [2].

   2.1 netname attribute

     "netname:" attribute specifies the name of a range of IP address 
     space [4]. Its syntax is an 'object-name' as specified in section 2 of
     RPSL [1].

   2.2 mnt-routes6 attribute

     "mnt-routes6:" attribute in inet6num object is used to control the 
     creation of route6 objects in the IPv6 space that this inet6num
     object specifies. Authorisation rules for creation of route6 objects 
     are elaborated in section 4. The syntax of mnt-routes6 is very similar
     to that of mnt-routes as specified in RPSS [2], except that it can
     list only IPv6 prefixes in curly braces, rather than IPv4 prefixes. 
     For example:
 
      mnt-routes6: A-MAINTAINER {2001:8888::/35, 2001:9998::/35}
      mnt-routes6: B-MAINTAINER

3. route6 Object

   The dictionary definition of a route6 object is as follows:

   route6:        [mandatory]  [single]
   descr:         [mandatory]  [multiple]
   origin:        [mandatory]  [single]
   holes:         [optional]   [multiple]
   member-of:     [optional]   [multiple]
   inject:        [optional]   [multiple]
   aggr-mtd:      [optional]   [single]
   aggr-bndry:    [optional]   [single]
   export-comps:  [optional]   [single]
   components:    [optional]   [single]
   remarks:       [optional]   [multiple]
   notify:        [optional]   [multiple]
   mnt-lower:     [optional]   [multiple]
   mnt-routes6:   [optional]   [multiple]
   mnt-by:        [mandatory]  [multiple]
   changed:       [mandatory]  [multiple]
   source:        [mandatory]  [single]

   The syntax of "mnt-routes6:" attribute is as defined above in section
   2.2. 

3. aut-num Object

   aut-num object as defined in RPSL[1], RPSS[2] and RPSLng draft [3]
   is extended to include "mnt-route6:" attribute. This attribute's
   syntax is defined in section 2.2 above.

4. Authorisation Model for route6 Objects

    Deletion and update of a route6 object is not different from
    other objects, as defined in RPSS [2]. Creation rules of a route6
    object is replicated here from the corresponding rules for
    route object in RPSS [2] section 9.9.

    When adding a route6 object, the submission must satisfy two
    authentication criteria. It must match the authentication
    specified in the aut-num object and the authentication specified
    in either a route6 object or if no applicable route6 object is
    found, then an inet6num object.

    An addition is submitted with an AS number and IPv6 prefix as   
    its key. If the aut-num object does not exist on a route6 to
    add, then the addition is rejected. If the aut-num exists then
    the submission is checked against the applicable maintainers.
    A search is then done for the prefix first looking for an exact
    match. If the search for an exact match fails, a search is made
    for the longest prefix match that is less specific than the prefix
    specified. If this search succeeds it will return one or more
    route6 objects. The submission must match an applicable maintainer
    in at least one of these route6 objects for the addition to 
    succeed. If the search for a route6 object fails, then a search
    is performed for an inet6num object that exactly matches the
    prefix or for the most specific inet6num that is less specific
    than the route6 object submission.
   
    Having found the aut-num and either a list of route6 objects or 
    an inet6num, the authorisation is taken from these objects.
    The applicable maintainer object is any referenced by the 
    mnt-routes6 attributes. If one or more mnt-routes6 attributes
    are present in an object, the mnt-by or mnt-lower attributes
    are not considered. In the absense of a mnt-routes6 attribute
    in a given object, then first mnt-lower attributes are
    used (only in the case the given object is inet6num object and
    it is less specific than the route6 object to be added), and
    if no applicable mnt-lower attribute is found, then the mnt-by
    attributes are used for that object. The authentication must
    match one of the authorisation in each of the two objects. 


5. Authorisation Model for Other RPSL Objects

   There is no change introduced for the authorisation of other
   types of objects.

6. Note on introduction of mnt-routes6 attribute.

    The introduction of "mnt-routes6:" attribute is required to
    provide backward compatibility. It is possible to overload
    "mnt-routes:" attribute, and make it include only IPv6 prefixes
    in the curly braces in the route6 and inet6num objects. This 
    would not cause a problem, as route6 class is completely
    new and "mnt-routes:" attribute would have been introduced in
    this document into the inet6num class. However, backward
    compatibility problem would result in aut-num objects, as it
    is relevant to both IPv4 and IPv6 address spaces, thus it would
    need to include both IPv4 and IPv6 address prefixes in curly
    braces, for example

      mnt-routes: A-MAINTAINER {2001:8888::/35, 192.168.144.0/23}

    which does not comply with the syntax of the attribute as
    defined in [2].

References:

  [1] Alaettinoglu, C., Villamizar, C., Gerich, E., Kessens, D.,
        Meyer, D., Bates, T., Karrenberg, D. and M. Terpstra, "Routing
        Policy Specification Language (RPSL)", RFC 2622, June 1999.

  [2] Villamizar, C., Alaettinoglu, C., Meyer, D. and S. Murphy,
        "Routing Policy System Security", RFC 2725, December 1999.

  [3] Damas, J., Parent, F. and A. Robachevsky, "RPSLng", Work in
        Progress.

  [4] Damas, J. and A. Robachevsky,  "RIPE Database Reference Manual", 
       15 August 2002.


$Id: rpslng-security.txt,v 1.3 2003/01/30 17:26:54 engin Exp $