hierarchical route objects, part 1

In message <9701110027.AA10908 at brind.isi.edu>, davidk at 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