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