Proposed change 2004.1: extended route creation rules

Dear colleagues,

[apologies for duplicate mails]

Some time ago, Frank brought an issue regarding route object
aggregation to our attention in the DB-WG mailing list.  Please
see the short thread at:

http://www.ripe.net/ripe/mail-archives/db-wg/2003/msg00474.html
http://www.ripe.net/ripe/mail-archives/db-wg/2003/msg00475.html

We have prepared a proposal to extend the route object creation
rules to resolve this issue.  However, the resulting proposal 
turns out to be quite complex as it builds on the current route
object creation rules, which are already complex enough.

Considering that the need for route object aggregation is encountered
very rarely, it might not be worth implementing it.  After the
deployment of version 3 of our whois software, we have seen only a
couple of such cases.  In those cases, we have resolved the issue by
applying the rules that we specify below manually.

I would like to ask the working groups if they think this proposal 
is too complex.  Implementing it would not be a problem technically,
but I'm more concerned about explaining the complex rules properly
to the users of the whois database.

Best regards, and thanks for your time,
--
Engin Gunduz
RIPE NCC Software Engineering Department


=============================================================
A PROPOSAL FOR EXTENDED ROUTE OBJECT CREATION RULES

This document is about being able to create route objects that
aggregate inetnums/route objects.  This is needed where a user
cannot merge two or more inetnum objects into one larger inetnum
object, but still needs to create a route object that aggregates
these inetnum objects.  This is seen especially with assigned PI
inetnum objects.
A hypothetical example:  Suppose there exist the following two 
inetnums in the whois database:

inetnum: 12.0.0.0 - 12.0.0.255
netname: EXAMPLE-PI
descr:   Example Banking PLC
admin-c: AA1-RIPE
status:  ASSIGNED PI

inetnum: 12.0.1.0 - 12.0.1.255
netname: ANOTHER-EXAMPLE-PI
descr:   Anotherexample Printing Industries NV  
admin-c: ZZ1-RIPE
status:  ASSIGNED PI

These are assigned to different end-users.  Further suppose that
they coincidentally take service from the same Internet Service
Provider.  The Internet Service Provider will want to aggregate these
two assignments into a single 12.0.0.0/23 route to be announced,
rather than announcing two separate prefixes, in order to keep the
number of prefixes in routing tables to the minimum.  However, the
Internet Provider will not be able to create a single route object in
the RIPE Routing Registry which implements RPSSec RFC (RFC2725). This
is because the inetnum object that contains the 12.0.0.0/23 prefix will be

inetnum:      12.0.0.0 - 12.9.255.255
netname:      EU-ZZ-000000
descr:        block for PI assignments
descr:        maintained by RIPE NCC
country:      EU
remarks:      These addresses are assigned
              to network operators. The RIPE NCC
              does not operate any networks using
              address space from this block.
              An explanation of how to find the
              correct contacts is available at
              <http://www.ripe.net/nicdb.html>
admin-c:      CREW-RIPE
tech-c:       CREW-RIPE
tech-c:       OPS4-RIPE
status:       ALLOCATED PI
mnt-by:       RIPE-NCC-HM-MNT
mnt-lower:    RIPE-NCC-HM-MNT
changed:      hostmaster at ripe.net 20030731
source:       RIPE

Note the "mnt-lower:" attribute that has RIPE-NCC-HM-MNT. 
See http://www.ripe.net/ripencc/faq/database/qa4.html#5 for
a graphical representation of the current route object creation rules.

Proposal:
  To address this problem, we need to extend the route object creation rules
so that it would be possible to create a route object that takes its
authorisation from a collection of route and/or inetnum objects that are
more specific than the route object to be created.  As the situation is 
quite rare, the 'extended' behaviour can be activated by using the keyword
'EXTENDED-ROUTE-CREATION' in the subject line of the update message or with
the syncupdates.  The extended behaviour is not the default behaviour.

The Algorithm:
  The proposed algorithm to authorise the route object creation is:

  Check if the keyword was used.  If not, proceed with normal route creation rules
    as described in RFC2725 (http://www.ripe.net/ripencc/faq/database/qa4.html#5)
  Check if there is an exact match route object or an exact match inetnum object
    If there is one, then proceed with normal route creation rules even if the 
    keyword was specified.
  Find the inetnums/routes that can be used for route creation:
      Get a list of all inetnums and route objects that are one level more
      specific than the route object to be created. (-r -Troute,inetnum -m <prefix>)
      From this list, eliminate the inetnums that have exact match or less specific
        route objects. (Note: During route object creation, the existing route
        objects take precedence over existing inetnum objects).
      Check if the resulting set of inetnums/routes cover the whole space of
        the route to be created.  If not, authorisation fails, hence creation attempt
        fails.
      Collect the mntners to be used during the authorisation check.  Follow these
      rules:
        For each object in the set, check if there are "mnt-routes:" attributes in
          the object.  If there are, they will be used.  If there are not, the mntners
          that are mentioned in "mnt-by:" attributes will be used.
      Check the authorisation: During the authorisation, the mntners in the same object
        will be ORed, while the mntners in separate objects will be ANDed. 


Example 1:

Suppose we have these inetnums in the database:

inetnum:    0.0.0.0 - 255.255.255.255
status:     ALLOCATED UNSPECIFIED
mnt-by:     RIPE-NCC-HM-MNT
mnt-lower:  RIPE-NCC-HM-MNT
mnt-routes: RIPE-NCC-NONE-MNT

inetnum:    12.0.0.0 - 12.255.255.255
status:     ALLOCATED PI
mnt-by:     RIPE-NCC-HM-MNT
mnt-lower:  RIPE-NCC-HM-MNT

inetnum:    12.0.0.0 - 12.0.0.255
netname:    EXAMPLE-PI
descr:      Example Banking PLC
admin-c:    AA1-RIPE
status:     ASSIGNED PI
mnt-by:     MNT-EXAMPLE-PI

inetnum:    12.0.1.0 - 12.0.1.255
netname:    ANOTHER-EXAMPLE-PI
descr:      Anotherexample Printing Industries NV  
admin-c:    ZZ1-RIPE
status:     ASSIGNED PI
mnt-by:     MNT-ANOTHEREXAMPLE-MNT-BY
mnt-routes: MNT-ANOTHEREXAMPLE-MNT-ROUTES
mnt-routes: MNT-ANOTHEREXAMPLE-MNT-ROUTES-2


There is also this aut-num object:

aut-num:    AS65534
mnt-by:     MNT-AUT-NUM-MNT-BY
mnt-routes: MNT-AUT-NUM-MNT-ROUTES

There are no route objects that are in 12.0.0.0/23 space,
or less specific of 12.0.0.0/23.

The user wants to create the following route object:

route:  12.0.0.0/23
origin: AS65534
mnt-by: MNT-ROUTE

When the creation is attempted without the keyword 'EXTENDED-ROUTE-CREATION,'
the whois software will try to get the IP space authentication from inetnums,
as no related route object exists.  The one level less specific inetnum is
12.0.0.0 - 12.255.255.255, which has the attribute "mnt-lower:  RIPE-NCC-HM-MNT".
As the user does not have access to the authorisation for RIPE-NCC-HM-MNT
mntner, the creation attempt will fail.

When the creation is attempted with the keyword 'EXTENDED-ROUTE-CREATION':
- There are no exact match route or inetnum objects, so proceed with
    extended route creation rules.
- to get the authorisation from IP space, the whois software will perform
    '-r -Troute,inetnum -m 12.0.0.0/23' query, which will return

inetnum:    12.0.0.0 - 12.0.0.255
inetnum:    12.0.1.0 - 12.0.1.255

- there are no inetnums to be eliminated from the list.
- the resulting set of inetnums/routes (it actually has two inetnums
   and no routes) covers the whole space of 12.0.0.0/23.
- collect the mntners to be used in the authorisation process.
   from the aut-num: MNT-AUT-NUM-MNT-ROUTES
   from the route object itself that will be created: MNT-ROUTE
   from the IP space: (MNT-EXAMPLE-PI AND 
                       (MNT-ANOTHEREXAMPLE-MNT-ROUTES OR MNT-ANOTHEREXAMPLE-MNT-ROUTES-2))
     12.0.0.0 - 12.0.0.255 does not have "mnt-routes:", so "mnt-by:" must
     be used.
     12.0.1.0 - 12.0.1.255 has two "mnt-routes:", so they both must be used,
     but they must be ORed.
-  the resulting mntner list:
     (
      MNT-AUT-NUM-MNT-ROUTES AND MNT-ROUTE AND
      (
       MNT-EXAMPLE-PI AND 
       (
        MNT-ANOTHEREXAMPLE-MNT-ROUTES OR MNT-ANOTHEREXAMPLE-MNT-ROUTES-2
       )
      )
     )

Example 2:  

Suppose there are these inetnums in the database:

inetnum:    0.0.0.0 - 255.255.255.255
mnt-by:     RIPE-NCC-HM-MNT
mnt-lower:  RIPE-NCC-HM-MNT
mnt-routes: RIPE-NCC-NONE-MNT

inetnum:    12.0.0.0 - 12.255.255.255
mnt-by:     RIPE-NCC-HM-MNT
mnt-lower:  RIPE-NCC-HM-MNT

inetnum:    12.0.0.0 - 12.0.0.255
mnt-routes: MNT-INETNUM-1

inetnum:    12.0.1.0 - 12.0.1.255
mnt-routes: MNT-INETNUM-2

and the following route objects:

route:      12.0.1.0/24
origin:     AS65534
mnt-routes: MNT-ROUTE-1

route:      12.0.2.0/23
origin:     AS6
mnt-routes: MNT-ROUTE-2

route:      12.0.2.0/23
origin:     AS65534
mnt-routes: MNT-ROUTE-3
mnt-routes: MNT-ROUTE-4

and this aut-num:

aut-num:    AS65534
mnt-by:     MNT-AUT-NUM-MNT-BY
mnt-routes: MNT-AUT-NUM-MNT-ROUTES

The user wants to create the following route object:

route:  12.0.0.0/22
origin: AS65534
mnt-by: MNT-ROUTE

When the creation is attempted without the keyword 'EXTENDED-ROUTE-CREATION,'
the whois software will try to get the IP space authentication from inetnums,
as no related route object exists.  The one level less specific inetnum is
12.0.0.0 - 12.255.255.255, which has "mnt-lower:  RIPE-NCC-HM-MNT" attribute.
As the user does not have access to the authorisation for RIPE-NCC-HM-MNT
mntner, the creation attempt will fail.

When the creation is attempted with the keyword 'EXTENDED-ROUTE-CREATION':
- There are no exact match route or inetnum objects, so proceed with
    extended route creation rules.
- to get the authorisation from IP space, the whois software will perform
    '-r -Troute,inetnum -m 12.0.0.0/22' query, which will return

inetnum:    12.0.0.0 - 12.0.0.255
inetnum:    12.0.1.0 - 12.0.1.255
route:      12.0.1.0/24
route:      12.0.2.0/23  (origin AS6)
route:      12.0.2.0/23  (origin AS65534)

- eliminate the inetnums with less specific or exact match route objects
   in the list.  The resulting list will be:

inetnum:    12.0.0.0 - 12.0.0.255
route:      12.0.1.0/24
route:      12.0.2.0/23  (origin AS6)
route:      12.0.2.0/23  (origin AS65534)

- the resulting list covers the whole 12.0.0.0/22 space.  Continue.
- Collect the mntners to be used during the authorisation check. 
   from the aut-num: MNT-AUT-NUM-MNT-ROUTES
   from the route object itself that will be created: MNT-ROUTE
   from the IP space: (MNT-INETNUM-1 AND MNT-ROUTE-1 AND
                       (MNT-ROUTE-2 AND (MNT-ROUTE-3 OR MNT-ROUTE-4)))

-  the resulting mntner list:
     (
      MNT-AUT-NUM-MNT-ROUTES AND MNT-ROUTE AND
      (
       (
        MNT-INETNUM-1 AND MNT-ROUTE-1 AND
        (
         MNT-ROUTE-2 AND
         (
          MNT-ROUTE-3 OR MNT-ROUTE-4
         )
        )
       )
      )
     )