hierarchical route objects, part 1

  > Schmitz at 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