"John A. Tamplin" <jat@Traveller.COM> 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 http://www.ietf.org/html.charters/nimrod-charter.html 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. Sean.