Proposed change 2004.1: extended route creation rules

Engin,

if this is, as stated, a rare event, would it not be better to have 
this be dealt with via a request to ripe-dbm?
You can implement a Perl snippet that does the checks you describe 
without polluting the general DB code with what feels like a kludge.

Joao

On 9 Feb, 2004, at 15:07, Engin Gunduz wrote:

>
> 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
>          )
>         )
>        )
>       )
>      )
>
>