From nobody Tue Apr 21 01:30:00 1998 X-From-Line: jon@central.warehouse.net Mon Apr 20 02:38 MET 1998 Received: from mailhost.warehouse.net (mailhost.warehouse.net [203.15.225.5]) by sigge.signum.se (8.8.5/8.8.5) with ESMTP id CAA26396 for ; Mon, 20 Apr 1998 02:38:26 +0200 (MET DST) Received: from deviant.quantum.net.au ([203.15.225.232]) by mailhost.warehouse.net (post.office MTA v2.0 0813 ID# 0-11017) with SMTP id AAA148; Mon, 20 Apr 1998 10:37:52 +1000 Sender: jon@signum.se Message-ID: <353AAA95.468DD61E@central.warehouse.net> Date: Mon, 20 Apr 1998 11:53:25 +1000 From: Jon Organization: Kaos X-Mailer: Mozilla 3.01Gold (X11; I; Linux 2.0.30 i486) MIME-Version: 1.0 To: Dwayne CC: mc@hack.org, herseya@db.erau.edu, FutureCulture Mailing List Subject: Re: PunkNet mailing list and webpage References: <353A0D02.3856D178@pobox.com> Content-Type: multipart/mixed; boundary="------------31C9B5E26D9F99FC384AAA0F" X-Content-Length: 29491 Lines: 709 Xref: hurricane.signum.se mail.misc:497 X-Gnus-Article-Number: 497 Mon Apr 20 10:06:14 1998 This is a multi-part message in MIME format. --------------31C9B5E26D9F99FC384AAA0F Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Here is the latest and greatest spec. punknet.overview - the waffle punknet.protocols - the tech proposal Its still rough and speaks in the present tense. The main purpose is to get the general idea across, and for people who know modern network stuff to recognise existing solutions and announce them and propose changes. Cheers Jon -- Jon Holdsworth (BAppSc) of PurpleWorld jon@central.warehouse.net.spamprevention Reality is a signal Dwayne wrote: > > Hiyas > > i've set up a mailing list as i'm sick of fucking cc:ing and > fwding stuff. > > So: > > email majordomo@coso.com > subscribe punknet > > in the message body. > > You'll be sent an info message. > > So far I'm the only one on it, and no one other than you guys and > FC have been told of the list, so it's low-volume. > > Feel free to pass the info on to anyone you feel might be > interested. If you want me to have it insert something in the > subject line for filtering let me know and I will, but I filter > on to: and cc: fields anyways. > > there's a homepage at > > http://i.am/punknet/ > > it's pretty basic, but it'll do for now. I'll add more stuff as > it comes along. Eventually there'll be some sort of > javascript/java-based discussion board there, but for now just > direct all your enthusiasm via the list. > > Jon: I'll send you all the passwords etc in case I wind up under > a bus or I get taken out by the NSA etc. > > I'll tell you, dodgy majordomo configurations are a bitch to fix > up. > > Dwayne > -- > > return...to...the...source > ddraig@pobox.com > http://pobox.com/~ddraig --------------31C9B5E26D9F99FC384AAA0F Content-Type: text/plain; charset=us-ascii; name="punknet.overview" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="punknet.overview" This is the Overview document, punknet.overview. The technical details are contained in punknet.protocols Punk/Net Disclaimer: This is a hardware and software conceptual specification only. A more rigorous and costed specification might be built upon the ideas and api's suggested in this specification. The author does not advocate breaking of inter/national, state or municipal laws. On the contrary, it is the widespread oppression of inalieable, natural human rights by idealogical zealots, the insane and the greedy that it is hoped that this technology will aid in reducing and eliminating. Overview: Punk/Net!! A completely alegal (of necessity) digital radio network that makes full use of modern encryption technology. It propagates "memetically", ala projects like the Linux O/S, and is not organised from a central source. It is extremely tolerant of faults and evasive of capture, and is fast enough to be useable. It can encapsulate standard protocols like TCP/IP and UDP, though the matter of resolving Punk addresses against IP addresses is not Punk/Net's problem. It should be able to encompass the entire world, especially if it can be interfaced to the IP internet. It is also cheap and effective to propagate, otherwise it can't propagate. Purposes: To defeat any possible current or future efforts of irresponsible governments to allow monopolies to "own" spectra - spectra are a free feature of the universe available to everybody. To defeat censorship. Censorship is a wrong-headed thing, a hangover from eras when it was felt that it was in some way acceptable to force people to do things that were purely based on one set of people's idealogy (ie. this was mistaken for "morality"). More specifically: To protect the identity of transmitters and receivers utterly. To protect the contents of messages utterly. To not use or reveal any geographic data. To avoid detection as much as possible. To avoid interference with surroundings as much as possible. To have a completely dynamic topology and be able to survive the death, intermittency or departure of nodes, without human intervention. To allow connection-oriented services to work, as well as broadcast services. To be spam-proof and spoof-proof. To be interfaceable with the IP internet. To be inherently upgradeable and self-powered, so that the devices require a minimum of physical attendance (ideally none) and are long-lifed. Definitions: Node - a small electronic brain coupled with a smart digital radio tranceiver and some kind of non-consuming power supply. Neighbor - a node that a given node can hear and speak to directly (ie. establish carrier with). Hop - the transmission of a packet from a node a neighbor node. Client - a device used by a human who wishes to use Punk/Net to communicate. Essentially the same as a node and the client enters the network by becoming a node, but provides access to the various protocol-layers so that useful work can be done with the packets. Most likely the Client is a PC/Peripheral/Software hybrid. Encryption - a method of taking some data and a password and using the password to mathematically "scramble" the data, so that only the person/machine with the password can ever view the data again. A password is also known as a Key. This basic form of encryption is known as "Single Key Encryption". Public Key Encryption - a method of encrypting data whereby a special program generates two keys that are special mathematical mirrors of each other. If you only know one of the keys, you can still encrypt the data, but you cannot _decrypt_ it! _Only_ the person with the other key can decrypt the data. The relationship is symmetrical. If you generate these two keys yourself, you can keep one of them secret - the "Private" key - and publish the other one - the "Public" key. Anybody who has your public key can send you encrypted data that nobody execpt you can ever read, ensuring that it cannot be snooped on in transit. It is also not possible to calculate a key from the other key. Key - pretty much any random number, but can also be an encryption public key. Hardware: Non-consuming power supply: ie. a power supply that does not require regular renewal in the way that a battery or fuel cell does. Two suggestions have been: solar cells trickle-feeding a rechargeable battery system; electro magnetic coils placed near high-tension power lines from which they can leach off the Near-Field magnetic energy (these are sometimes called "Near Field Suckers"). Radio FM MHz tranceiver with switchable frequencies. Note: Don't attract enmity by using heavily-trafficked or stupid frequencies. Carrier seeking, detection and locking circuitry. Note: Spread Spectrum offers much here, but is not cheap or compact yet. Digital buffering circuitry. Packet capturing and emitting firmware. Intelligence provided by firmware, a smart CPU and some RAM. The node must be no bigger than a shoebox, maximum. The node must not cost more than $60 to build. (It has been demonstrated that a minimal node could now be built at about the size of two cigarette packets, but the power supply situation is not fully determined yet). The node must be able to completely reboot and re-integrate itself into the network (even if it takes a while). The node must, at a hardware and low-level-protocol level, do things randomly to avoid detection, such as going quiescent for random periods. Propagation of hardware: Design and build some nodes and get them to work in all weather and all network conditions. Run spamming and spoofing and snooping efforts to try and break them. When the prototyping cycle is completed, create detailed descriptions of the components, circuitry, and different power supplies. Distribute these combined descriptions together with a description of the intentions of Punk/Net. The IP Internet is the best place to start. If the idea takes, people will spontaneously build nodes, then put them up in their own neighborhoods. As the protocol is widely known, there is no proof at all that the node was placed by any particular person, even if the node is unfortunate enough to be physically found. The nodes also have an unexpected advantage in being autonomous box-shaped devices. Camoflage. Most buildings and modern structures are dotted with all sorts of protrusions and mechanical devices to do with the support systems of the structure itself, and the purpose of these devices is often not obvious. Suitably decorated nodes (eg. airbrushed with enamel inks to appear like rusty metal or stained brick) should blend in and be more or less invisible amongst these other devices. Rural nodes are needed too. Protocol axioms and layers are discussed in the punknet.protocols file. [end of document] --------------31C9B5E26D9F99FC384AAA0F Content-Type: text/plain; charset=us-ascii; name="punknet.protocols" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="punknet.protocols" This is the technical document, punknet.protocols. The general Overview is contained in the file punknet.overview. Punk/Net Disclaimer: This is a hardware and software conceptual specification only. A more rigorous and costed specification might be built upon the ideas and api's suggested in this specification. The author does not advocate breaking of inter/national, state or municipal laws. On the contrary, it is the widespread oppression of inalieable, natural human rights by idealogical zealots, the insane and the greedy that it is hoped that this technology will aid in reducing and eliminating. Purposes: To protect the identity of transmitters and receivers utterly. To protect the contents of messages utterly. To not use or reveal any geographic data. To avoid detection as much as possible. To avoid interference with surroundings as much as possible. To have a completely dynamic topology and be able to survive the death, intermittency or departure of nodes, without human intervention. To allow connection-oriented services to work, as well as broadcast services. To be spam-proof and spoof-proof. To be interfaceable with the IP internet. To be inherently upgradeable and self-powered, so that the devices require a minimum of physical attendance (ideally none) and are long-lifed. Definitions: Node - a small electronic brain coupled with a smart digital radio tranceiver and some kind of non-consuming power supply. The more RAM the better. Neighbor - a node that a given node can hear and speak to directly (ie. establish carrier with). A node that is 1 "Hop" away. Hop - the transmission of a packet from a node a neighbor node. Client - a device used by a human who wishes to use Punk/Net to communicate. Essentially the same as a node; the client enters the network by becoming a node, but provides access to the various protocol-layers so that useful work can be done with the packets. Most likely the Client is a PC/Peripheral/Software hybrid. Encryption - a method of taking some data and a password and using the password to mathematically "scramble" the data, so that only the person/machine with the password can ever view the data again. A password is also known as a Key. This basic form of encryption is known as "Single Key Encryption". Public Key Encryption - a method of encrypting data whereby a special program generates two keys that are special mathematical mirrors of each other. If you only know one of the keys, you can still encrypt the data, but you cannot _decrypt_ it! _Only_ the person with the other key can decrypt the data. The relationship is symmetrical. If you generate these two keys yourself, you can keep one of them secret - the "Private" key - and publish the other one - the "Public" key. Anybody who has your public key can send you encrypted data that nobody execpt you can ever read, ensuring that it cannot be snooped on in transit. It is also not possible to calculate a key from the other key. Public Key Encryption (PKE) also provides a means of "signing" a packet, proving that only you could have originated it. Key - pretty much any random number, but can also be an encryption public key. Protocol Axioms ---------------- Punk/Net is a Stateless protocol. The sending or receiving of a packet does not change the state of a node except transiently. Public Key Encryption (PKE) is integral to the very protocol itself. Any packet received by a node that cannot be interpreted is then regarded as being encrypted. The node then tests all its own current private keys on the packet, in order youngest-to-oldest, to see if it can decode the packet header. If it succeeds, this means the packet is addressed to this node! If however the node fails to decrypt the packet, the packet is dropped. The data payload of a successfully received packet can be examined to see if it is another packet. Packets can be nested like this, though this need not be generally exploited throughout the system. A node enters the network as described in the details of the Announce packet type. A node leaves the network "silently", no messages need to be emitted to announce this. Nodes do not rely on any one node to propagate messages for them. The very nature of the protocol is to constantly seek out alternative routes and to use as many of them as possible. Layers of Punk/Net ------------------ Lowest Hardware - carrier chase and detect Transport - packet header, length and CRC checking Punk - the protocol described in detail in this document OverPunk - a proposed higher level protocol that rides on Punk, described below Highest Packet types of the Punk network layer (a bit hazy): Announce Broadcast Sounding Addressed Query QueryResponse These packet types are intended to mesh together, creating a simple but effective event-driven (ie. stateless) protocol. Packet types of the OverPunk network layer (very hazy): ZoneAnnounce News These packets are to provide advertised routing (like RIP in tcp/ip) and a simple channel system so that the network remains usefully employed, respectively. Basics of packet types ----------------------- Announce Carries an encryption public key. This effectively "names" the Sender. Travels only 1 hop, to neighbor nodes. Purpose: To integrate a new node into the network by announcing its public key to its immediate neighbors. The node creates a public/private PKE key pair. The node stores the private key internally, with a timestamp, and is now "known by name" using this key. The node sends out an Announce packet in all directions (broadcast is the only physical means of transmission in Punk/Net, which helps hide the destination. Unfortunately it also hides it from the rest of the network! However, this is the problem intended to be resolved here). This can be written as Packet[payload,payload...], so here it is Announce[key]. Any nodes 1 hop away can receive this Announce[key] packet, because they are defined as being 1 hop away by the very fact that they can hear the originating node at all! These neighbor nodes react to the Announce[key] packet by storing the key in a list, and then by broadcasting their own Announce[key] packet. Thus neighbors swap keys. Two mechanisms are necessary here to prevent bad things happening: 1. The Announce is encrypted in response, using the key that the originator first sent. This prevents the responses from propagating out into the network, since only the originator will be able to decode the response Announces, and other nodes receiving them will not be able to and will drop the packets. 2. The Announce packet needs to have a session number in the header. This means that the response Announces will not trigger the originator to re-respond in turn. This cannot be spoofed to jam the network, as only session numbers that the originator knows of will do anything, and the neighbors will only respond to the originator. Ie. the best a spoofer can do is cause a small amount of noise. Broadcast Carries a maximum number of hops. 0 is ignore max-hops. Carries a number of hops so far, with a flag saying whether to support this or not. Carries a MessageID to ensure it propagates only forwardly. Carries a Data payload of arbitrary length. Other Punk/Net packet types can be embedded in the Data field. Purpose: To enable a message to visit all nodes in the network once-only. This enables Punk/Net to DO something. A node can originate a Broadcast packet, causing a "ripple" of data to travel outward through the network. Any node receiving a Broadcast packet will transmit it to its neighbors. It will also store the MessageID for a time, dropping the packet silently if it ever sees it again, to prevent feedback. This means that the packet only propagates forward. If the max-hops is greater than 0, any node receiving this packet will increment the number of hops so far by 1, or silently drop the packet if the number of hops is now greater than max-hops. This isn't really spoofable for jamming purposes, since it is a "noise" protocol by definition. Smarts could be further built into the node's operating system to counter spoofing. Query Only travels 1 hop. Carries a Query type. Carries a Parameter Data field of arbitrary length. At least 1 type of Query is supported - Dump Address Table To Me - this is the Punk/Net equivalent of RIP. Purpose: To enable a node to retrieve addressing information from its immediate neighbors. Used by nodes to interrogate other nodes. And what does a node want to ask another node, you ask? Addressing information. Addressing is possible in Punk/Net. The Punk/Net addressing system is distributed across tables stored in all nodes. These tables grow over time as a natural process, but a node entering the network will want to make use of them immediately. To this end, the Query and QueryResponse packets provide a shortcut whereby a node can ask its neighbors for their address tables. Note that this also effectively tells the node its own "address". QueryResponse Only travels 1 hop. Carries a Query type. Carries a Parameter Data field of arbitrary length. At least 1 type of Query is supported - Dump Address Table To Me - this is the Punk/Net equivalent of RIP. Purpose: To enable a node to retrieve addressing information from its immediate neighbors. Used by nodes to respond to interrogation by other nodes. The payload is currently only intended to be the address table of the node. Sounding Carries a MessageID. Carries a Zone key. Carries a number of hops so far. Carries a max-hops. Purpose: To enable nodes to announce themselves to the network as originators of a new Zone, and to supply the key for the Zone. These form the basic building block of the Punk/Net addressing scheme. What happens is this. A node will spontaneously every now and again emit a Sounding packet, which contains a random number. The node stores this number. The Sounding packet also has a max-hops, which defines its "range". Packets with bigger rangers are emitted less frequently, packets with smaller ranges are emitted more frequently. The node stores the max-hops value with the number. This number is known as the "key", and all the nodes in the network that are within the max-hops range of the key are known as the "Zone" for that key. Any node receiving a Zone key will store the key along with the max-hops value from the packet, increment the hops-so-far in the packet header, cache the MessageID and drop the packet silently if it ever sees it again in the forseeable future, then broadcast it in all directions. If the hops-so-far is greater than the max-hops, the packet is silently dropped. This causes lots of overlapping Zones to be formed, of all different sizes. They can persist for a time, refreshed by repeat broadcasts from the originators of the Zones. It is thus possible to address a packet, fuzzily but definitely, by listing a series of Zone keys in order from biggest-range to smallest-range as the address. The structure that the Zone keys are stored in are referred to as the Address Table, as discussed regarding the Announce packet, above. The Announce[key] keys are stored in the same table as 1-hop Zone keys, since they have exactly the same properties as the Zone keys announced by Sounding packets. Addressed Carries a MessageID to ensure it propagates forward. Carries a list of Zone keys in descending max-hops; ie. the target address. Carries a number of hops since last Zone-size drop. Carries a Data payload of arbitrary length. Optionally carries the Sender's own address. Purpose: To enable a message to reach a specific node without having to use a blanket broadcast. The addressing tables enable packets to follow Punk/Net's fuzzy routing. The OverPunk higher-level protocol should make routing even more efficient (ie. less redundant node visiting). The sequence is as follows. A node sends out an Addressed packet. Another node catches the packet. The receiver examines the address, a list of Zone keys, and searches for any of the keys in its address table. If it finds one, it knows that it (the node) is in that Zone. If the Zone is lower range than another Zone, the higher range Zone key is stripped out of the list and dropped. This is because the packet is obviously _closer_ to its target now! This continues until all keys have been compared and the address list has been reduced as much as possible. If the hops-so-far is greater than twice the range of the largest ranged Zone key in the packet's address, the packet has strayed far from the path, and is silently dropped. If a Zone was dropped (referred to, logically enough, as a "Zone drop"), the hops-so-far is reset to 0. This recursively prevents the packet straying from zones it has been found to occupy. If no change was made to the address (the receiver did not recognise any of the keys), the number of hops-so-far is incremented and the packet is sent on its way. It effectively behaves as a Broadcast packet until one of its keys is recognised. The node employs the MessageID to prevent feedback in the usual way. The packet will spiral down further and further closer to the target. Lots of copies of it will go out and spam the network, but only in a single pass. At the local level, this should be hardly noticeable. It also "smears" the physical location of the recipient across big potential chunks of the network. Packet Interactions: A node will construct key pairs every so often, and at any one time will be known by several of them. The node gradually ages the keys and retires ones that are now too old. Every so often the node will send out announce packets containing its still active keys. Public keys function as both a name for a node (it has several at any one time) and a means of encrypting data sent to it (and because of the above, a means of exclusively sending to it alone). The Punk/Net universe is regarded as being a sea of nodes in an n-dimensional topological space that has nothing (in principle) to do with the real geography. The nodes are regarded as being collected in pseudo-random overlapping groups. Since the only metric available in this space is number-of-hops-away, that is the metric used. Nodes emit Sounding packets more or less constantly, and these packets travel throughout the network establishing Punk/Net's "fuzzy" routing. Bigger Zones (read: Zone keys from Sounding packets with large max-hops values) are broadcast less frequently than smaller ones, and the software is aware of this fact. A client uses its Address Table to create a fuzzy address for itself, chosen randomly but monotonically-ordered from its various Zone keys. It can use this address as a connection point. A node sends out a Query packet. The nearest nodes (1-hop away) will respond with a QueryResponse packet containing the Address Table. The Zones in the Address Table are integrated into the querying node's own Address Table. An address table is a list of Zone keys stored with MAX-HOPS and other info. OverPunk --------- There are at least 2 higher level protocols that can be employed: 1 Is a higher-level routing protocol that intends to make addressed packets travel faster and without flooding the entirety of Punk/Net. 2 Is good old "News", but done at a low level instead of a high one (NNTP could be supported via Encapsulation if one wanted. This version, being closer to Punk/Net itself, is better able to be exploited in a non-kludgy way by Punknodes). 1. OverPunk - Routing ---------------------- ZoneAnnounce Is sent out in a Broadcast packet. Max-hops=? Contains address of Sender. Contains Address Table of Sender. The purpose of this packet is to allow nodes that are in overlap areas where several Zones cross to help nodes outside those overlap areas send and receive Addressed packets more quickly. The basic idea is that any node can report (via Broadcast) what Zones it is in, ie. what Zone keys it possesses. These keys are extracted from the normal Address Table. If the packet reaches another node that is in one of the same Zones as the ZoneAnnouncer, this by definitions means that the two nodes can exchange Addressed packets already. However, they may both each possibly be members of other Zones that the other is not, and it is this information that they can exchange. If one of them receives an Addressed packet and cannot resolve any of the Zones at all, it can look up the Zones in its OverPunk table and see if it has ever heard of a nodes somewhere that _does_ know about one or more of the Zones in the Addressed packet's address list. In sequence: A node emits a ZoneAnnounce packet, containing its Address Table (or a prudent subset of it, at the node's discretion). When received, the address of the Sender is checked - if it is not within any Zone known to this node, the packet is discarded. If the packet survives, any Zone keys that this node already has tabled are discarded. The remaining Zone keys refresh a fast-lookup cache, with the address(es) of their sender(s) listed with them. The keys expire unless refreshed. When this node later receives an addressed packet with a Zone key that it does not recognise, it can look it up in that cache and encapsulate the addressed packet in a packet addressed to the Sender of that key. The wrapper, so addressed, is given the MessageID of the packed packet, to prevent feedback accidents. All nodes can tell if the payload of a packet is addressed to them, by applying all their current keys and seeing if one of them decodes the header of the payload. The payload is then treated as a new packet, variously depending on the application. In this case - If the original Sender receives a packet it can look at the data field to see if there is another addressed packet embedded there. If there is, the node unpacks the packed packet, discards the wrapper and zeroes the number-of-hops-so-far value in the unpacked packet, then sends the unpacked packet to its own Punk layer, as though it had just received it itself. 2. OverPunk - News ------------------- News packet: Is sent out in a Broadcast packet. Max-hops arbitrary. Contains a newsgroup name in a Punknode-readable format, NNTP style text headers. Contains a news article in a Punknode-readable format, NNTP style article text. The actual handling of news is up to whatever software is accessing the OverPunk layer. Ideally it would be a daemon masquerading as an IP style NNTP server, talking to a Punk/Net radio interface peripheral. Such a daemon could act as an upstream "feeder" and "receiver" for NNTP style news. Further ------- Back-off times and other protocol nitty-gritty strategies are left for the reader; A TCP (Transport Control Protocol) is not our biz here, we are only interested in this document in the TP (Transport Protocol) or Transport Layer. Reliable transmission is the domain of a higher-level control protocol (a TCP), not of the Transport Layer; - these are well studied things and are not worth cluttering this spec with. Two things to keep in mind though; Punknet should NOT be cooperative, every node has to be able to keep its own without relying too much on the good behaviour of other nodes; Individual nodes should be able to function as individually as they like, just so long as externally they honour Punk. Other high-level protocols can be invented. A means of making nodes even more mobile would be nice - with the above paradigm you would already have to know the keys of nodes along your route, or hope that you would be in contact with individual nodes for long enough to get their Announce[key] responses. Punk Web would be nice. Since TCP/IP can be encapsulated over Punk/Net, ghostly web sites shouldn't be too hard to set up. [end of document] --------------31C9B5E26D9F99FC384AAA0F--