Re: hierarchical route objects, part 1

[Curtis Villamizar <]

In message <9701090843.AA22116@localhost>, Daniel Karrenberg writes:
> 
>   > Schmitz@localhost (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