North American Network Operators Group

Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical

Re: route ingress

  • From: Sean M. Doran
  • Date: Thu Jan 08 08:50:57 1998

"John A. Tamplin" <[email protected]> writes:

> I don't understand how the current top-down allocation affects how that 
> would be done.

This is a very broad issue so i will oversimplify.

Right now, in order to verify that a particular prefix is
being announced properly, one has to be able to associate
the prefix with the announcer in two directions.

Firstly, one has to walk a tree of registries from the
root towards the announcement to make sure the address has
been allocated correctly.  This means that registries from
the root down have to keep some sort of credential scheme
for each entity to which it has allocated addresses,
and moreover, that those credentials are carried in
routing announcements, which is interesting when you
consider aggregation.

Secondly, one needs a routing registry which indicates
that the route has been announced following the proper
policy.  Then, when you hear an announcement you have to
walk back through the policy tree to ensure that  not only
the policy as registered was followed but also you need to
check processing credentials to make sure people aren't
faking up a remote AS-to-AS adjacency, for example.

With a bottom up allocation scheme, assuming something
like IS-IS on steroids as the Internet-wide routing
protocol, where there is a flat-routed (or
locally-interpreted) part on the extreme right and the
address grows leftwards away from the originating area,
one does not have to go to a registry to check whether a
particular network should be originating a particular
address.  Moreover, routing will be hierarchical in
nature, in verifying policy one will generally make use of
a tree of trust in verifying the processing signatures,
although one can ask each area recursively if it had
intended the announcement to its adjacent (parent or
child) area.

Policy in a hierarchical network where addressing strictly
follows topology will be simpler to describe even in the
presence of unusual constraints, and therefore the
verification work will be simpler.  Moreover, at a
distance, all you want to do is verify the presence or
absence of an area to area adjacency rather than the
presence or abence of a large number of global prefixes.
Finally, all you need is a database of unique area-id to
credentials, rather than a hierarchical database of 
prefix-to-entity/entity-to-credential scheme.

>  As I see it (and I haven't spent any significant time
> working on it, but it seems straightforward):
>  1) ARIN/whoever signs an address allocation to an entity

To make it clearer, try working on defining "whoever".

>  2) that entity signs route announcements to peers/upstreams, incuding
>     who they are announced to

What do you do about aggregation, both atomic and proxy?

What do you do about pieces of an aggregate when they
appear, or more importantly, when they do not appear?

>  3) readvertisements are signed by the advertiser

What do you do if there is a transient change in topology
such that the chain of announcers differs substantially?

For instance, suppose you see an AS path of A B C D E for
a particular prefix, and later you see F G H I E?  How do
you know this announcement is correct and should be believed?

> Any recipient of a route can verify that the address space was properly 
> allocated by inspecting the address allocation certificate and verifying
> the signature of the registry, and they can verify the path that 
> advertisement has taken to get to where it is.  Thus no one can interject
> a route to a network prefix that is not properly allocated, and someone 
> cannot steal a route advertisement for someone else's prefix.  The biggest
> problem with something like this is the size of the routing table in
> memory (since you have to keep certificates around for readvertisements)
> and in the bandwidth required for the updates.

Ok, so suppose someone somewhere announces 128.100.251/24.
Walk the decision tree of a number of routers, notably
ones at big exchange points, or ones at smaller multihomed
networks a couple of ASes away from some of the big
networks, and tell me what you think needs to happen.

Then make it more fun: deaggregate 9/8 at the /24 (or the
/30) level and announce it around, or try announcing huge
swaths of address space programattically with a modified
gated (for example).  Where is the huge wave of
announcements caught and dealt with, and what has to cope
with such a flood of announcements?

> I am not familiar with NIMROD, do you have a pointer to it?

It's in the usual place for IETF working groups, 
and specifically
is what you want.

The likliest evolutionary direction of the Internet now is
something like NIMROD married to MPLS (another IETF WG)
with translation between the new stuff and old IPv4 hosts
(and to-be-considered-old IPv6 hosts) close to the edges
of the Internet.