Das Six/Four System
Eine dezentralisierte anonyme Peer-To-Peer Netzwerk Infrastruktur mit Vertrauen

Six/Four Protokoll Spezifikationen
geschrieben von <mixter@hacktivismo.com>

Protocol Version: 1

0 Ziel
1 Peer Layer
2 Link Layer

0.0 Ziel

Das Ziel des Six/Four Systemprotokolls ist es, dass User ausserhalb des Six/Four Netzwerkes mit TCP und UDP Services im Internet
kommunizieren koennen und gleichzeitig dabei den Ursprung des Users und es fuer nicht vertrauenswuerde Mittelmaenner den Inhalt der Kommunikation geheim zu halten.

Six/Four ist KEIN Filesharing, dafuer aber ein anonymes Kommunikations- und Informationsbeschaffungsnetzwerk.
Das heisst, dass normale Peers keinerlei Informationen speichern (abgesehen von Keys uns Hostlisten) und nicht vom Internet aus zugaenglich sind sofern sie keine aktive Verbindung aufbauen.
Six/Four ansich ist KEIN VPN protocol (es kann in lokale Netze tunneln, wenn ein TrustedPeer an dessen Grenze steht), alles in allem jedoch nur ein Tunnel Protokoll.

1.0 Modulares Peer Layer

Das 6/4 besteht aus 2 "Ebenen", das LinkLayer behandelt die physikalischen Verbindungen von Peer zu Peer und basiert derzeit auf SSL mit einigen Protokoll Negotationen und Anti-Traffic-Analyse Erweiterungen.
Das momentane LinkLayer Protokoll ist am Ende dieses Dokuments beschrieben.
Das Peer Layer operiert unabhaengig und transparent oberhalt des Link Layer (somit kann es auch mit anderen Link Layer Implementierungen wie plain-text TCP, raw packet Uebermittlung, TFN2k transmission, oder Steganographie laufen).

Die Peer-Ebene kuemmert sich um das Routing aller Nachrichten (zur Entdeckung von Hosts und zur Datenuebertragung).
Die Wahl der Routen erfolgt in einer Weise, die 1) die Identitaet jedes Peers innerhalb von 2 Hops und mehr anonymisiert, da nur das direkte Ziel und die Quelle in der Routing-Tabelle aufgezeichnet werden 2) unbeweisbar macht, welcher Peer von sich aus Daten angefordert hat: kein Peer, der eine Peer-Layer Nachricht empfaengt, kann zuordnen, ob die Daten, die von seinem Nachbar-Peer kommen, auch von diesem erzeugt wurden, oder nur fuer einen anderen Peer weitergeleitet worden sind.
So koennen sogar feindliche Peers nie feststellen, ob ihr Nachbar-Peer (=direkt verbundener Peer), der Initiator einer Datenuebertragung mit einem Trusted Peer war.

1.1 Peer Layer Pakettypen

Das Peer Layer Protokoll besteht derzeit aus 8 verschiedenen Pakettypen, die unterschiedlich zwischen den Peers geroutet werden und unterschiedliche Interpretation und Routingtechniken benoetigen.
Pakete werden mit LINK->write() direkt ueber dem LinkLayer geschickt, wobei LINK ein verbundenes "Link" Klassenobjekt ist.
Alle Pakettypen haben die gleichen ersten 4 Felder (8 Bytes), um ein universelles Routing zu ermoeglichen.

/* Laenge eines unverschluesselten Pakets in bytes*/
unsigned short total_length;
/* -1 durch jeden Hop, Paket wird verworfen wenn ttl=0 ist */
unsigned char ttl;
/* PT_PING, PT_PONG, PT_STARTR, PT_STARTU, PT_CLIR, PT_ACK, PT_DATA, PT_DONE */
unsigned char packet_type;
/* Ein gemeinsamer, zufaelliger Integer (Um Duplikate zu finden und zu verwerfen) */
unsigned int packet_uid;

Bei den folgenden Paketen werden diese ersten 4 Felder weggelassen um diese Protokoll Spezifikation kurz zu halten.

Packet Typ: PT_PING Gesamtgroesse: 9 Bytes
Beschreibung: PING Pakete werden gesendet um andere nicht-vertrauenswuerdige Peers im Netz zu finden.
Andere Peers muessen primaer gefunden werden um Peers zu haben mit denen man sich physikalisch verbinden kann.
Ein PING Paket wird gebroadcastet und verteilt sich in einem Radius einer bestimmten Anzahl an Hops.
Die empfohlene Hop-Rate ist 6.
Jeder Peer der ein PING Paket routet oder erhaelt SOLLTE mit einem PT_PONG ueber denselben Pfad antworten ueber den ihn das Paket erreicht hat. (SOLLTE: Nicht notwendig fuer stealth-mode Peers.)

/* Wieviele Hops das Paket noch zu tun hat. -1 durch jeden Peer */
unsigned char hopsleft;

Packet Typ: PT_PONG Gesamtgroesse: 24 Bytes
Beschreibung: Ein PONG Packet ist eine Antwort auf ein PING.
Es wird anhand der "pings_puid" geroutet, die der packet_uid des urspruenglichen Pakets entspricht.
Routing benutzt dies um das pong ueber denselben Pfad zu schicken, ueber den auch das ping ging.

/* Wie oben erwaehnt, packet_uid des entsprechenden PING */
unsigned int pings_puid;
/* IPv4 Adresse des antwortenden Peer */
unsigned int myaddr;
/* Port des antwortenden Peer (Standard: 443) */
unsigned short myport;
/* Six/Four PROTOCOL Version, sollte 1 sein */
unsigned short myversion;
/* LinkLayer Erweiterungen - bisher ungenutzt */
unsigned int myextensions;

Packet Typ: PT_STARTR Plain-text
Header: 16 Bytes Gesamt: variabel
Beschreibung: Stellt eine Anfrage fuer eine Verbindung zu einem Host/Service ausserhalb des Six/Four Netzwerkes, zum
Beispiel einem Webserver.
Dieses Paket sollte an den zustaendigen TrustedPeer geroutet werden, der dann die Verbindung erstellt und einen Tunnel aufbaut (Permanenter anonymer Routing Kreis).
Wenn dies gelingt empfaengt man PT_DATA Pakete direkt nachdem die Verbindung initialisiert wurde.
Wenn der Versuch fehl schlaegt wird der TrustedPeer schweigen und der User wird ein Time-Out fuer die Verbindung
kriegen (Lokal in seiner Download Tabelle) und sollte die Anfrage erneut an einen anderen TrustedPeer stellen.
Fuer mittlere Peers ueber die dieses Paket geroutet wird bedeutet dies, dass es mindestens ueber einen weiteren
Peer geroutet werden MUSS und es ueber weitere zufaellige Peers geroutet werden KANN.
Wenn der TrustedPeer physikalisch mit dem mittleren Peer verbunden ist muss dieser Peer das Paket an den TrustedPeer schicken.

/* Trusted Peer IPv4 address. */
unsigned int tpaddr;
/* Control Transmission ID - Die vom Peer zufaellig gewaehlte Session ID,
die zur Initialisierung verwendet wird. Diese ID identifiziert die
Session fuer den anfragenden Peer, den TrustedPeer und die mittleren
Peers
*/
unsigned int ctid;
/* STARTREQ_P folgt */
/* Das Datapayload folgt und es ist:
- von variabler Laenge (totlength - 16 - STARTREQ_P),
- ist mit dem signierte/verifizierten RSA Key des TrustedPeer (tpaddr)
RSA verschluesselt
- Enthaelt zusaetzliche Daten die vom TrustedPeer an den aussenstehenden
Rechner direkt nach der Verbindung geschickt werden. (Kann eine Groesse
von 0 haben)
*/

Packet Typ: PT_STARTU Plain-text
Header: 164 Bytes Gesamt: variabel
Beschreibung: STARTU (UDP Anfragen) sind komplett dieselben wie STARTR (TCP Anfragen), aber vermitteln halt, dass der TrustedPeer einen UDP Socket nutzen soll.

Subpacket Typ: STARTREQ_P (verschluesselt, Beschreibung siehe PT_STARTR)

/* Laenge des Hostnamen in Bytes */
unsigned short hostlen;

/* Ziel Port/Service. Zum Beispiel Port 80. Ein TrustedPeer KANN Zugriff
zu bestimmten Ports/Services durch eine AccessControlList sperren,
indem er einfach nicht reagiert oder ein PT_DONE Packet zuruecksendet.
*/
unsigned short dstport;

/* Ein zufallsgenerierter, binaerer AES Schluessel, mit dem die Session
verschluesselt wird. Der TrustedPeer und der anfragende Peer MUESSEN
alle subsequenten Daten (in PT_DATA und PT_CLIR Paketen) mit diesem
negotiierten Key verschluesseln.
*/
char aeskey[165];

/* Der HOSTNAME folgt (hostlen Bytes)
Dies ist ein nicht-aufgeloester FQDN. Nur der TrustedPeer MUSS aufloesen
*/
/* Es folgt DATA PAYLOAD (LEN= totlen - STSIZE_HEAD - STSIZE_P - hostlen)
Die Daten die an den aussenstehenden Server gesendet werden. Zum Beispiel
fuer einen Webserver etwas wie "GET / HTTP/1.0". Dies kann 0 sein.
*/

Packet Typ: PT_CLIR Plain-text
Header: 16 Bytes Gesamt: variabel
Beschreibung: DATA Packete werden vom TrustedPeer zurueckgesendet, sobald Daten bei einer geoeffneten Session zur Verfuegung stehen (Der TrustedPeer MUSS Daten von ausgehenden Verbindungen annehmen) und solang die vorhergehenden mit einem ACK bestaetigt wurden.

/* Session ID, siehe PT_STARTR */
unsigned int ctid;
/* Original Plain-text Laenge */
unsigned int oplen;
/* AES-ENCRYPTED DATA_P (LEN = total_length - 4) */

Subpacket Typ: DATA_P (verschluesselt):
unsigned int seq_writ; /* Geschriebene Bytes, total */
/* DATA (LEN = PT_DATA->totlen - 4 - 4) */

Packet Typ: PT_DONE Overall size: 12 bytes
Beschreibung: Sagt dem TrustedPeer oder dem anfragendem Peer die Verbindung zu beenden.

/* Session ID, siehe PT_STARTR */
unsigned int ctid;

2.0 Modulares Link Layer - "SSL" Implementierung des Link Layers

PROTOKOLL.
Die SSL Implementierung benutzt TCP und SSL.
Die "SSL" Implementierung ist derzeit das Standard Link Layer.

STANDARD PORT.
Der Standardport des Link Layer ist 443.
Die SSL Implementierung sollte probieren dieselben SSL Optionen wie die gaengigen HTTPS Server Implementierungen (zum Beispiel)
Apache-SSL zu benutzen.

ERSTELLEN EINER VERBINDUNG (AKTIV).
Ein Peer muss sich mit einem anderen Peer wie bei einer physikalischen TCP Verbindung ueber connect() verbinden.
Wenn die Vermittlung an irgendeiner Stelle fehlschlaegt muss sich der Peer disconnecten.
Direkt nachdem die TCP Verbindung erstellt wurde MUSS ein Standard SSLv23 Layer vermittelt werden.
Die SSL Link Layer Implementierung benutzt PKCS Fuelloptionen, welche die Trafficanalyse von Ciphertext verhindert.
Solang das der Fall ist wird die Groesse nicht zufaellig veraendert.
Ein Packet zur Initialisierung -- das Handshake Packet -- wird ueber SSL I/O uebermittelt. Es besteht aus:

unsigned int addr; /* Vom Peer bevorzugte IPv4 Adresse. */
unsigned short port; /* Port vom Peer, sofern benoetigt */
unsigned short version; /* Protokoll Version = 1 */
unsigned int extensions; /* Erweiterung -- noch redundant */

ANNEHMEN EINER VERBINDUNG (PASSIV).
Ein Peer muss eine Verbindung wie bei einer physikalischen TCP Verbindung mit accept() annehmen.
Wenn die Vermittlung an irgendeiner Stelle fehlschlaegt muss sich der Peer disconnecten.
Direkt nachdem die TCP Verbindung erstellt wurde MUSS ein Standard SSLv23 Layer vermittelt werden.
PKCS Fuelloptionen zum verhindern von Traffic Analyse MUSS genutzt werden.
Der Peer erwartet jetzt 12 Bytes an Daten zu lesen, bestehend aus:

unsigned int addr; /* Remote Peer IPv4 Adresse */
unsigned short port; /* Remote Peer Port */
unsigned short version; /* 1 */
unsigned int extensions; /* Ungenutzt */

Wenn alle Parameter korrekt ankommen wird die Verbindung als etabliert betrachtet und Peer Layer Pakete koennen ausgetauscht werden.

INDEX