references on non-central authority network protocols
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: http://www.ipnsig.org/ 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? ;-) -- Eddy Brotsman & Dreger, Inc. - EverQuick Internet Division Phone: +1 (316) 794-8922 Wichita/(Inter)national Phone: +1 (785) 865-5885 Lawrence ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Date: Mon, 21 May 2001 11:23:58 +0000 (GMT) From: A Trap <blacklist@brics.com> To: blacklist@brics.com Subject: Please ignore this portion of my mail signature. These last few lines are a trap for address-harvesting spambots. Do NOT send mail to <blacklist@brics.com>, or you are likely to be blocked.
On Sat, 13 Apr 2002, Stephen Sprunk wrote:
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.
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. -- 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 Which isn't robust against malicious hosts in the same network, but thats fixable with a heirarchial scheme. -- This is off the top of my head, so I probably made a stupid mistake.. But I'm pretty sure some variation of this scheme would work. Scott
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"
-----Original Message----- From: owner-nanog@merit.edu [mailto:owner-nanog@merit.edu]On Behalf Of Scott A Crosby Sent: Saturday, April 13, 2002 6:45 PM To: Stephen Sprunk Cc: Patrick Thomas; nanog@merit.edu Subject: Re: references on non-central authority network protocols
On Sat, 13 Apr 2002, Stephen Sprunk wrote:
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.
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.
--
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
Which isn't robust against malicious hosts in the same network, but thats fixable with a heirarchial scheme.
--
This is off the top of my head, so I probably made a stupid mistake.. But I'm pretty sure some variation of this scheme would work.
Scott
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
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 ;-P
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.
-----Original Message----- From: owner-nanog@merit.edu [mailto:owner-nanog@merit.edu]On Behalf Of Tony Hain Sent: Monday, April 15, 2002 11:40 AM To: Stephen Sprunk; Scott A Crosby Cc: Patrick Thomas; nanog@merit.edu Subject: RE: references on non-central authority network protocols
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 ;-P
http://www.ietf.org/internet-drafts/draft-hain-ipv6-pi-addr-use-02.txt
Tony
On Mon, 15 Apr 2002 18:22:56 PDT, Bruce Williams said:
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!
At OC-192 speeds? ;)
On Mon, 15 Apr 2002 Valdis.Kletnieks@vt.edu wrote:
On Mon, 15 Apr 2002 18:22:56 PDT, Bruce Williams said:
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!
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...
-----Original Message----- From: Tony Hain [mailto:alh-ietf@tndh.net] Sent: Monday, April 15, 2002 11:40 AM To: Stephen Sprunk; Scott A Crosby Cc: Patrick Thomas; nanog@merit.edu Subject: RE: references on non-central authority network protocols
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 ;-P
http://www.ietf.org/internet-drafts/draft-hain-ipv6-pi-addr-use-02.txt
Tony
At 03:40 PM 4/14/2002 -0500, Stephen Sprunk wrote:
No, the trick is for a distributed algorithm to generate a non-trivial number of unique values for a (short) fixed-length field.
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/ ---------- Dave Crocker <mailto:dave@tribalwise.com> TribalWise, Inc. <http://www.tribalwise.com> tel +1.408.246.8253; fax +1.408.850.1850
On Sat, 13 Apr 2002, Stephen Sprunk wrote:
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 ;-P
There are several alternatives to TCP being researched, but there are currently no viable alternatives to IP.
-- Internet Vision Internet Consultancy Tel: 020 7589 4500 60 Albert Court & Web development Fax: 020 7589 4522 Prince Consort Road vision@ivision.co.uk London SW7 2BE http://www.ivision.co.uk/
On Mon, 15 Apr 2002 03:41:49 BST, Jasper Wallace said:
Location - either distribute all the addresses evenly over the planet or try to map to population density.
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 ;) -- Valdis Kletnieks Computer Systems Senior Engineer Virginia Tech
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. --On Monday, 15 April 2002 03:41 +0100 Jasper Wallace <jasper@ivision.co.uk> wrote:
On Sat, 13 Apr 2002, Stephen Sprunk wrote:
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 ;-P
There are several alternatives to TCP being researched, but there are currently no viable alternatives to IP.
-- Internet Vision Internet Consultancy Tel: 020 7589 4500 60 Albert Court & Web development Fax: 020 7589 4522 Prince Consort Road vision@ivision.co.uk London SW7 2BE http://www.ivision.co.uk/
-- Joseph T. Klein +1 414 628 3380 Senior Network Engineer jtk@titania.net Adelphia Business Solutions jtk@adelphiacom.net "... the true value of the Internet is its connectedness ..." -- John W. Stewart III
On Fri, 12 Apr 2002, Patrick Thomas wrote: :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. :) -- batz
participants (12)
-
batz -
Bruce Williams -
Dave Crocker -
E.B. Dreger -
Eric Gauthier -
Jasper Wallace -
Joseph T. Klein -
Patrick Thomas -
Scott A Crosby -
Stephen Sprunk -
Tony Hain -
Valdis.Kletnieks＠vt.edu