Hello,
I am looking for any and all research (and perhaps your comments),
references, etc. regarding replacements for the TCP/IP protocol that do
not require centralized authority structures (central authority to assign
network numbers).
Any links, comments, etc., appreciated.
--PT
I am looking for any and all research (and perhaps your comments),
references, etc. regarding replacements for the TCP/IP protocol that do
not require centralized authority structures (central authority to assign
network numbers).
Any links, comments, etc., appreciated.
Well,
I don't think this is exactly what you were looking for, but the guys
at JPL (NASA's Jet Propulsion Lab), along with Vince Cerf, are working
on ways to extend the Internet throughout the solar system in an
attempt to link space craft and (should it happen) human settlements
in space to our little digital world. Lets face it, if you're going
to be stuck in a tin can the size of a VW Bug for 18 months, eating
only "rations" and not showering, you're gonna want access to the planets
largest collection of Porn... um.. I mean... all of the deeply insiteful
and intellectually enriching content found on the Internet...
I THINK this is their site:
The one sentence background, as I understand it, is that they feel
you can't run TCP/IP over interplanetary distances because the long
latencies wouldn't jive well with the SYN/ACK nature of TCP.
Eric 
Thus spake "Patrick Thomas" <root@utility.clubscholarship.com>
I am looking for any and all research (and perhaps your
comments), references, etc. regarding replacements for the
TCP/IP protocol that do not require centralized authority
structures (central authority to assign network numbers).
Please explain how you think any protocol could support non-trivial numbers
of users without some arbiter to prevent address collisions.
There are several alternatives to TCP being researched, but there are
currently no viable alternatives to IP.
S
Date: Sat, 13 Apr 2002 18:37:42 -0500
From: Stephen Sprunk <ssprunk@cisco.com>
Please explain how you think any protocol could support
non-trivial numbers of users without some arbiter to prevent
address collisions.There are several alternatives to TCP being researched, but
there are currently no viable alternatives to IP.
You mean extending NetBEUI to be Internet-wide would be a futile
exercise? 
Rolling off the top of my head, I think its doable. The general trick is
to make it hard to forge packets with arbitrary addresses (by using
authentication).
Assume each host has an public and private key pair by some conventional
algorithm (RSA, or other). The private key is never disclosed.
K_public, K_private.
Let H be a collision resistant hash function, and SIGN do a digital
signature that may be verified by anyone who knows K_public.
Then, each host is given an address of:
k_public
Now, annotate each packet with sufficient information to authenticate
that the packet came from the host k_public.
SIGN(H(k_public || BODY)) || k_public || BODY
(Note: hosts could be given addresses of H(k_public) for shorter
addresses. Another enhancement would be to annotate the packet with a
counter to help catch replay attacks.)
Anyways, I think this fits the bill, you cannot create an arbitrary
k_public of your choice. If you could, then you could break the public key
cryptosystem (or the cryptographic hash).
The only way to create a valid signature is to know k_private. Packets are
not accepted unless they come with a valid signature, so knowing k_public
does not tell one how to create packets.
Uh, let's see - you submask k_public to route, hmm... either you have 32 bit
encription or you have IP1024... IP1024 - THAT would solve address space
limits, but imagine the BGP prefix updates...
Bruce Williams
"Two is not equal to three, even for large values of two"
:I am looking for any and all research (and perhaps your comments),
:references, etc. regarding replacements for the TCP/IP protocol that do
:not require centralized authority structures (central authority to assign
:network numbers).
I think this could use some explaining, as 'centralized' is a pretty
relative term, even in todays Internet. ARIN, APNIC, RIPE and others(?)
would qualify as non-centralized, because there is more than just
one of them. If you are in a geographic area served by one of them,
then you might think it is centralized. I would say the same for
DNS in its current mutation.
However, from what I would speculate you are trying to find information
on, you might want to look at the DoD protocol stack, decide what
layer you really need this decentralized functionality on,
and then see if existing P2P network technologies might fit your
requirements.
By looking for a network protocol that doesn't require registration
authorities, or some sort of enrollment process which would manage
addressing conflicts, you will run into one of two inevitable
problems.
The first being that to ensure reachability, you will need a lower
layer protocol encapsulating your decentralized one (think of it
as a social contract), as communications protocols aren't terribly
useful when you can't see or talk to anyone.
The second being that you will have to dispense with the
possibility of unique identifiers, and accept the conflicts
inherant in the collisions this causes. It is up to you
to decide if this is consistent with the requirements of
your protocol.
Someone mentioned that people could simply generate their own
"addresses" using public keys, which is theoretically possible,
but we've seen how that works in usenet, where for one person
to send an encrypted message to another, their message has to be
propagated to absolutely everyone for the intended recipient to read it.
It doesn't scale.
Multicasting doesn't solve this either, as you have to register
as part of a group to recieve the broadcasts. It's efficient, but
you still have this issue of registration authorities to enroll you
in a multicast group.
So, as far as getting rid of centralized authority on a network, you
just have to redefine "centralized" to mean something less
abstract and more connected to the community of users, and redefine
"authority" as a service instead of an administrator.
You also have to decide what level you want that service to take place:
Process, interface, segment, subnet, route, ASN, route, subnet, segment,
interface, process.
Thus spake "Scott A Crosby" <crosby@qwes.math.cmu.edu>
Rolling off the top of my head, I think its doable. The general
trick is to make it hard to forge packets with arbitrary
addresses (by using authentication).
No, the trick is for a distributed algorithm to generate a non-trivial
number of unique values for a (short) fixed-length field.
Assume each host has an public and private key pair by some
conventional algorithm (RSA, or other). The private key is
never disclosed.
...
A variant of this could be made where just the network is
assigned with this scheme, the host isn't. IE, hosts are assigned
addresses of:k_public || hostaddr
For instance, let's say IP had started with a constant 24-bit network field
(no Class A or B), or 16M possible networks. My rough count shows we have
97 /8's usefully allocated, or 776M hosts assuming 50% efficiency. We'd
need 6.4M /24 networks to cover this many hosts, out of a possible 16M
networks. I dare you to find any hash that can reliably give 38% of all
possible values without a collision. Once you've done that, perhaps you can
enhance BGP to handle 800M routes
Which isn't robust against malicious hosts in the same network,
but thats fixable with a heirarchial scheme.
The odds of k_private being disclosed grow exponentially with the number of
hosts per network.
Interesting idea though. Perhaps someone will write an i-d on autonomous
numbering for IPv6.
S
Thus spake "Patrick Thomas" <root@utility.clubscholarship.com>
> I am looking for any and all research (and perhaps your
> comments), references, etc. regarding replacements for the
> TCP/IP protocol that do not require centralized authority
> structures (central authority to assign network numbers).Please explain how you think any protocol could support non-trivial numbers
of users without some arbiter to prevent address collisions.
Location - either distribute all the addresses evenly over the planet or try
to map to population density.
(the higher your density of sites, the more accurate your coordinates need
to be).
you could aggregate addresses by doing something like:
2 hemispheres
36 'triangular' chunks spaced every 10 degrees latitude.
then split up in longditudernal stripes.
but i think you'd be better allocation on the basis of population density.
How exactly you'd make the social and economic changes to get to a system
like this vs, the telcos/isps we have now is probably more trouble than it's
worth 
This works well (sort of) at the DNS level - that's why we have ISO country
code domains.
However, you can't do this well at the "routing a packet" level (which is
where IP lives) because you can't aggregate routes very well.
Try computing what happens to your routing tables in the Boston, NYC, or
Silicon Valley area, or anyplace else there's a fairly high density of
high-tech, and multiple providers. In the worst case scenario, you have
an office building that has Genuity customers on floors 2 and 7, Sprint
on 1, 3, and 9, a company on floor 4 and half of 5 from another vendor,
and 4 suites on each of floors 6 and 8, each of whom are dealing with a
different small ISP.
You think we got problems with punch-out prefixes *NOW*.
Figuring out what this means for "wardriving" is left as an exercise for
the student
Please submit an IETF draft ... a thread to this effect has popped up
in the Ptomaine group now and then since in theory you can also aggregate
the same way on a regional or continental basis.
Do you have a good algorithm for the allocation?
Do you use the projected population based on WHO estimates for the next
50 years?
Do you have an algorithm for adjusting the density of the allocation
grid by population density?
How do you deal with large IP clusters that fall outside the population
grid such as high density business centers.
Who adjudicates collisions within the same grid square? For an example
of a problem site take the Sears Tower in Chicago?
The devil is, as always, in the details.
Stephen Sprunk wrote:
Interesting idea though. Perhaps someone will write an i-d
on autonomous
numbering for IPv6.
RFC 3041 & http://www.tml.hut.fi/~pnr/publications/cam2001.pdf
Jasper Wallace wrote:
Location - either distribute all the addresses evenly over
the planet or try
to map to population density.(the higher your density of sites, the more accurate your
coordinates need
to be).you could aggregate addresses by doing something like:
2 hemispheres
36 'triangular' chunks spaced every 10 degrees latitude.
then split up in longditudernal stripes.
http://www.ietf.org/internet-drafts/draft-hain-ipv6-pi-addr-02.txt
but i think you'd be better allocation on the basis of
population density.How exactly you'd make the social and economic changes to get
to a system
like this vs, the telcos/isps we have now is probably more
trouble than it's
worth
http://www.ietf.org/internet-drafts/draft-hain-ipv6-pi-addr-use-02.txt
Tony
How does this route? The TSP ( traveling salesman problem ) model seems
better than geo based models. Possibly a dynamic public/private key - the
host provides part, the routers adds a wrapper of based on it's public key,
and routes based on a dynamic traveling salesman solution using current
network metrics. Blue Sky!
"Current network metrics" - the gnutella type P2P have a ping problem
keeping this info current enough, this is the heart of the P2P network
problem. They are evolving to the use of dynamic assignment of "super peers"
with other hosts as "leaf nodes" based on bandwidth to lessen this problem.
If anyone wants to email me offlist, I will give a number of references to
really good work in this area.
Bruce Williams
Benchmarks: Engineering wants to see how fast they can get the wheels to
spin on a car. Operations wants to know how fast the car will go. These
are different.
At OC-192 speeds?
I think this says it best:
The goal of a scientist is to find an interesting problem, and live off
it for a while. The goal of an engineer is to evade interesting
problems :)" -- Vadim Antonov <avg@kotovnik.com> on NANOG
Scott
This appears to have bounced due to a configuration error on my end...
This line of suggestion indicates a goal of identification, rather than addressing.
Addressing is supposed to have relevance to the infrastructure topology, so that it indicates a place within the topology.
As to the larger goal of non-centralized address assignment, the usual distinction is between administrative method, versus basis of assignment authority.
Distributed (non-centralized) administration is not very difficult. As noted, the RIRs are a version of that.
Independent assignment (multiple authorities) has not been achieved so far. Activities that appear to have this feature actually rely on a logical central authority, with operational coordination among the participants. The central authority in these cases is either some sort of statute or the cooperative enforcement of the participation community.
d/