hierarchical route objects, part 1
Dear colleagues, regarding hierarchical authorization of route objects in the RIPE database: from what I have heard there is a general feeling that it is needed and the basic scheme to implement it should follow the lines: * The root of the authorization tree is an AS-object (aut-num object). If it contains a "mnt-lower" attribute it controls all route-objects which have this AS as origin. * Then for route-objects the same rules apply as for inetnum-objects with respect to IP subranges: If a route-object contains a "mnt-lower" attri- bute it controls all more specific route-objects immediately below. * The authorization is checked against - more or less specific route-objects, or existence of the route-object itself with same origin (differing origin rejected) - if no route-objects exist: which authorization is specified for the autnum-object referred to by the origin attribute (rejected if this authorisation is not met) - if not even an autnum-object exists no action is taken However: there is still a problem that route-objects are somehow logically linked to allocated address space. The question how to deal with this is still open - I continue on this in a separate mail. Yet, the three rules for route-objects described above are a kind of common denominator(*) and moreover a very reasonable approach (these rules are also independent of the address space allocation relation to route-objects). If there are no further denials I suggest to implement it that way. Regards Joachim (*) Yes, I know: When aiming for the common denominator, be prepared for the occasional division by zero. _____________________________________________________________________________ Dr. Joachim Schmitz schmitz@noc.dfn.de DFN Network Operation Center Rechenzentrum der Universitaet Stuttgart ++ 711 685 5553 voice Allmandring 30 ++ 711 678 8363 FAX D-70550 Stuttgart FRG (Germany) _____________________________________________________________________________
Joachim, I like the idea that the maintainer of the autnum object can control the route objects created with its as number as the origin. And agree with Daniel, a notification is probably sufficient when the origins ASes are different. With respect to: Joachim Schmitz (Schmitz@rus.uni-stuttgart.de) on January 8:
* Then for route-objects the same rules apply as for inetnum-objects with respect to IP subranges: If a route-object contains a "mnt-lower" attri- bute it controls all more specific route-objects immediately below.
I disagree that this is a good idea. If I register the following route object (which actually exists): route: 128.0.0.0/1 descr: HALF-DEFAULT-ONE origin: AS1800 advisory: AS690 1:1800 2:1239 mnt-by: MAINT-AS1800 mnt-lower: MAINT-AS1800 nobody else can register any route objects. Cengiz -- Cengiz Alaettinoglu Information Sciences Institute (310) 822-1511 University of Southern California http://www.isi.edu/~cengiz
Schmitz@RUS.Uni-Stuttgart.DE (Joachim Schmitz) writes:
* The root of the authorization tree is an AS-object (aut-num object). If it contains a "mnt-lower" attribute it controls all route-objects which have this AS as origin.
Agreed.
* Then for route-objects the same rules apply as for inetnum-objects with respect to IP subranges: If a route-object contains a "mnt-lower" attri- bute it controls all more specific route-objects immediately below.
This is flawed for several reasons: In the real world it is still the originating AS which has authority over which routes they announce. Example: AS3333 could at this minute decide to announce 129.69.18.28/32 (the address of Joachim's primary MX host). There is nothing anyone can do about the announcement per se. I can configure our routers to do that and chances are good that -at least initially- large parts of the Internet will believe the route. Of course other ASes can refuse to accept this route but that is routing policy and has nothing to do with originating the route by AS3333 which is the only significance of the route object. So the originating AS should be the sole point of hierarchical *authorisation* for the route object. Note that notification is different and refer to my earlier message about this. Further the root of the mixed hierarchy is subject to change in your proposal. This is difficult to handle. Example: aut-mum: AS3333 mnt-lower: RIPE-HIER Now creation of route: 193.0.0.0/23 origin: AS3333 would be controlled by RIPE-HIER. However if I create: aut-num: AS65535 mnt-lower: BLACK-HAT route:193.0.0.0/22 mnt-lower: BLACK-HAT origin: AS65535 creation of route: 193.0.0.0/23 origin: AS3333 is controlled by BLACK-HAT who can happily delete the spurious objects. Now one could refine the algorithm by saying that the originating AS has to be equal but after some thought is becomes obvious that that is largely equivalent to not having this rule at all.
* The authorization is checked against - more or less specific route-objects, or existence of the route-object itself with same origin (differing origin rejected)
Sorry different origin can be legitimate use. How do you authorise that? Note that first registered controls may not be the "correct" decision and leads to nasty conflicts that have to be resolved manually. Daniel
In message <9701090843.AA22116@ncc.ripe.net>, Daniel Karrenberg writes:
Schmitz@RUS.Uni-Stuttgart.DE (Joachim Schmitz) writes:
* The root of the authorization tree is an AS-object (aut-num object). I f it contains a "mnt-lower" attribute it controls all route-objects whic h have this AS as origin.
Agreed.
* Then for route-objects the same rules apply as for inetnum-objects wit h respect to IP subranges: If a route-object contains a "mnt-lower" attr i- bute it controls all more specific route-objects immediately below.
This is flawed for several reasons:
In the real world it is still the originating AS which has authority over which routes they announce. Example: AS3333 could at this minute decide to announce 129.69.18.28/32 (the address of Joachim's primary MX host). There is nothing anyone can do about the announcement per se. I can configure our routers to do that and chances are good that -at least initially- large parts of the Internet will believe the route. Of course other ASes can refuse to accept this route but that is routing policy and has nothing to do with originating the route by AS3333 which is the only significance of the route object. So the originating AS should be the sole point of hierarchical *authorisation* for the route object. Note that notification is different and refer to my earlier message about this.
The whole point of the hierarchical registration is to make the database good for some purpose. If people do announce bogus routes, as the routing protocols will allow them to do, then the IRR will protect the legitimate holder of that address space as long as the heirarchical registration is in place and in use. Your black hat example is also flawed. At the top of the heirachy can be 0/0 registered to IANA and withdrawn (not announced). The registries themselves can have top level objects below that. In order to make any changes, you need to have been given authorization from a higher level. You can then assign authorization to lower blocks to other parties. Curtis
Curtis,
Curtis Villamizar writes :
Your black hat example is also flawed. At the top of the heirachy can be 0/0 registered to IANA and withdrawn (not announced). The registries themselves can have top level objects below that. In order to make any changes, you need to have been given authorization from a higher level. You can then assign authorization to lower blocks to other parties.
This works for IP network objects since the registries need to add these objects manually anyway. This is not that obvious for 'route' objects. Are you proposing that the registries have to approve (manually) all the route objects that are in the route hierarchy directly below their own allocated space ? Or do you have a way to solve this in an automatic way? (this is not an attack, I sincerely hope that anybody can come up with something that works) Note that the InterNIC's IP registration data makes it very difficult to use the data on allocated IP space and then the connection between allocated IP space and routes is not always that clear. We could create special maintainers for ISPs that can only act on address space with origin AS'es that they own. However, I don't think that anybody is interested in creating more confusion by creating all kinds of kludges like this, David K. ---
In message <9701110027.AA10908@brind.isi.edu>, davidk@ISI.EDU writes:
Curtis,
Curtis Villamizar writes :
Your black hat example is also flawed. At the top of the heirachy can be 0/0 registered to IANA and withdrawn (not announced). The registries themselves can have top level objects below that. In order to make any changes, you need to have been given authorization from a higher level. You can then assign authorization to lower blocks to other parties.
This works for IP network objects since the registries need to add these objects manually anyway.
This is not that obvious for 'route' objects. Are you proposing that the registries have to approve (manually) all the route objects that are in the route hierarchy directly below their own allocated space ?
Tie the hierarchy to the inetnums. Continue to flog the InterNIC for non-participation in the IRR. The maintainer of a database such as the RADB that uses InterNIC as the number registry may have to take InterNIC data (ftp) and load it into inetnum records. An inetnum references one or more maintainer (in mnt-by). To create a route object, you must satisfy one of the criteria: 1. You must be in the maintainer field in a less specific route object (used to create route objects for more specific prefixes; hopefully these get aggregated somewhere ). 2. You must be in a maintainer for the exact inet-num and for the AS that you are putting in the route object (used after the initial top level route object is created). Once a top level route object is created, a more specific route object can be created and the mnt-by field can reference more than one maintainer. Here is an example. The registries approve of the top level blocks, that is the aggregates (or blocks that should be announced as aggregates). Whoever the aggregate is allocated to creates the top level route object and can delegate below that. For example, ANS has 207.24/14. There were two route objects needed to handle multihomed (a /22 and a /24) prefixes. The usual way a provider would delegate would be to reference more than one maintainer in the route object (the provider and the customer, and probably the other provider if the route object had a unique origin AS).
Or do you have a way to solve this in an automatic way? (this is not an attack, I sincerely hope that anybody can come up with something that works)
I don't see what the problem is (other than the InterNIC). If you allocate PI space (heaven forbid:) then the prefix is tied to the inetnum until a route object exists.
Note that the InterNIC's IP registration data makes it very difficult to use the data on allocated IP space and then the connection between allocated IP space and routes is not always that clear. We could create special maintainers for ISPs that can only act on address space with origin AS'es that they own. However, I don't think that anybody is interested in creating more confusion by creating all kinds of kludges like this,
David K.
The InterNIC was done a terrible job in that regard. What more can I say. It should be possible to dump the InterNIC's data and populate inet-nums. There is a maintainer field in the InterNIC data so future allocation would be OK as long as there were corresponding maintainer names in the InterNIC and the IRR. Asking people to put their IRR mntner name in the "maintainer" field when asking for addresses isn't so bad. Is it? Curtis
participants (5)
-
Cengiz Alaettinoglu -
Curtis Villamizar -
Daniel Karrenberg -
davidk＠isi.edu -
Schmitz＠RUS.Uni-Stuttgart.DE