Six/Four System Protocol Specs

written by <mixter@hacktivismo.com>

Protocol Version 1

Contents

1 Goal

2 High-Level Concept of a Six/Four Connection

3 Modular Peer Layer

3.1 Peer Layer Packet Types

4 Modular Link Layer

1 Goal

The goal of the Six/Four System protocol is to let its users connect out to and communicate with TCP- and UDP- services on the Internet, outside of the Six/Four network, in real-time, while making it impossible to know the user's origin, and making it impossible for untrusted middle-men peers to know the content of each session.

Six/Four is NOT a file-sharing, but an anonymous information retrieval and communication network. This means that normal peers do not store any information (other than keys and host lists) and are not designed to be accessible from the outside Internet unless they actively make a connection. Six/Four is NOT a VPN protocol per se (it can only tunnel into local networks if a chosen trusted peer sits at the border of an intranet/LAN), but nothing more than a tunneling protocol.

2 High-Level Concept of a Six/Four Connection

A high-level perspective of the Six/Four concept.

1) A Six/Four peer client, PEER1, links into the Six/Four network, to one or more random or chosen peers, over the LinkLayer specific protocol.

The LinkLayer protocol MUST be generic and encrypted, and MUST NOT be detectable as Six/Four-Specific through remote traffic analysis, including statistical traffic analysis, replay, and timing attacks.

Man-in-the-Middle attacks by hostile key insertion between peers directly connected to each others that are not trusted peers are not covered, as only securely- or pre-authenticated keys can solve this problem, and besides being hard to realize using dynamic IP addresses, without a semi-anonymous global PKI in place, preauthentication would compromise the identity of the individual running a peer, or at least the fact that it is running a Six/Four peer.

The standard LinkLayer protocol is SSLv3 over TCP.

1b) Clients SHOULD be able to safeguard against a local attack (which means, per definition, a hostile agent connecting to the local peer and routing Six/Four traffic to detect that the local peer is in fact using the Six/Four protocol), by means of White-List or Black-List access controls.

2) PEER1 now may exchange peer-to-peer routing, discovery and data packets in an ad-hoc P2P traffic mode within the Six/Four network, secured from directly connected peer to directly connected peer by the LinkLayer.

3) PEER1 wants to communicate with HOST1. HOST1 is a regular host outside of the Six/Four network, an internet server running any common protocol (such as HTTP, FTP, IRC, ICQ, ...) which is TCP- or UDP-based. The peer choses his Trusted Peer end-point from his local list of Trusted Peers available and known to him.

A PEER and a TP MUST use securely authenticated, asymmetric cryptography to communicate and/or to negotiate a secure symmetric session key. The key of PEER1's chosen trusted peer, TP1, MUST be pre-authenticated, and certified. The certification MUST guarantee an association of the key with the IP Address of TP1, to prevent hostile key insertion. It MAY additionally associate the Trusted Peer key with the port number.

4) PEER1 sends a connection initiation packet over the Six/Four network, that is destined for TP1. The payload of the connection initiation packet MUST be encrypted with the public, pre-authenticated key of TP1, and MUST contain a secure-randomly-chosen symmetric session key (so that TP1 and PEER1 can communicate securely). The payload also MUST contain the destination address and port of HOST1, to which TP1 will attempt to connect directly over TCP or UDP, and MAY contain initial data to be sent to HOST1 by TP1 right after connection initiation.

4b) The routing decision, i.e. the path discovery of the connection initiation packet, and then, subsequent data packets, between PEER1 and TP1, are currently done via a hop-by-hop routing protocol: for routing an initial packet from PEER1 to TP1, each hop determines a random next destination to send the packet on to, until TP1 is in reach of a directly connected peer. Each peer memorizes the route by associating the Connection ID in the packet with the information of the source peer from which the packet came and the destination peer to which the packet was sent, effectively establishing a single-path Mixnet route, with each hop only knowing its direct source/destination. The disadvantage of this routing system is that the address of TP1 is transmitted in the initial connection packet for all peers to read to make a correct routing decision. However, it is impossible to tell who originated the initial connection packet. No other remote party can tell whether PEER1 originated the connection request, or merely forwarded a packet from another peer.

A theoretically viable, more advanced communication strategy within the peer-to-peer network, which, unlike Six/Four's single-path Mixnet routing, would not require the initial connection packet to include the IP address of TP1, would be Anonymous Message Broadcasting , as defined by David Chaums "Dining Cryptographers" theorem. This would involve a constant flow of decoy messages between all parties, and broadcasting of all packets over the LinkLayer, instead of actual decision-based routing paths. Six/Four could generally operate using Anonymous Message Broadcasting with an adaption to its Peer Layer. Even though this approach is viable, the bandwidth requirements for data transmission using Six/Four tunnels would be extremely high, which is why this option was disregarded.

5) A Six/Four connection is now established between the virtual end-points PEER1 and HOST1, with all information travelling between PEER1 and TP1 securely encrypted and forwarded along the dynamically established route, associated with the connection ID and the previous peer and next peer on each intermediate peer between PEER1 and TP1, and a direct TCP or UDP connection from TP1 to HOST1.

5b) As a response to each transmitted DATA packet sent between PEER1 and TP1 as a part of the virtual connection between PEER1 and HOST1, an ACK packet is sent back to the opposite site, confirming the received data with a sequence number. After either PEER1 or TP1 receives an ACK to a DATA packet that it sent before, it will continue sending data.

6) Time-outs and connection errors may be, and often are, implicit, which means that there is no mandatory mechanism of informing the requesting PEER1 that his chosen Trusted Peer, TP1, could not be reached. It is however possible to send a connection termination message, using connection-ID based routing, e.g. to formally end a connection.

7) Discovery is done on a basis of broadcasting a PING packet, propagating to all peers in the vicinity of at most 6 hops. Peers in the range of less than 3 hops MUST not respond, to make a complete mapping of a peer's immediate surroundings impossible. Peers in the range of 3-6 hops MAY respond to a PING packet with a PONG packet, or MAY chose to entirely ignore the packet, remaining effectively invisible on the network, except to their directly connected peers. PING sources are memorized hop-by-hop, and PONGs are to be routed the same way back.

3 Modular Peer Layer

The 6/4 is comprised of two "layers", the Link Layer handles the physical connectivity from peer to peer, and is currently based on SSL with some protocol negotiation and anti-traffic-analysis extensions. The current LinkLayer protocol is described at the end of this document. The Peer Layer operates independently and transparently on top of the Link Layer (thus, it could work with other Link Layer implementations such as plaintext TCP, raw packet transmission, TFN2k transmission, or steganography...).

The Peer Layer takes care of routing all messages (for host discovery, and data exchange request and data transfer). The routing is done in a way that it 1) anonymizes the identity of each peer within a range of 2 hops and more, since only the direct destination and source for packet pathways are recorded in the routing table 2) provides cause for deniability: each peer receiving a Peer Layer message won't know whether the data it got from its neighboring peer was generated by the peer, or just routed through, and came from another peer before. Thus, even hostile peers can never prove that their neighbor (=directly connected) peer was the initiator of a transfer request.

3.1 Peer Layer Packet Types

The Peer Layer protocol is comprised of (currently) 8 different packet types which are routed differently among peers and require different interpretation and routing behavior. Packets are directly send atop of the Link Layer using LINK->write() where LINK is a connected "Link" class object. All packet types do have the first four fields (together 8 bytes), required for uniform routing, in common:

/* total length of whole packet when decrypted, in bytes */ unsigned short total_length; /* decrease by 1 for every hop, drop packet if ttl reaches zero */ unsigned char ttl; /* PT_PING, PT_PONG, PT_STARTR, PT_STARTU, PT_CLIR, PT_ACK, PT_DATA, PT_DONE */ unsigned char packet_type; /* a unique, random integer (for finding and dropping duplicate packets) */ unsigned int packet_uid;

For the following packet types, these first four general fields will be omitted to keep this protocol specification short.

Packet type: PT_PING Overall size: 9 bytes Description: PING packets are sent for discovering other, untrusted peers in the network. Other peers need to be discovered primarily for having peers to physically connect to. A PING packet is broadcasted and propagates with a radius of a certain count of hops. The recommended hopcount is 6. Each peer who routes or receives a PING SHOULD reply with a PT_PONG packet down the routing path where it came from. (SHOULD: Not mandatory for stealth-mode peers.) /* How many hops this packet has left to travel. Decreased by 1 at each peer. */ unsigned char hopsleft;

Packet type: PT_PONG Overall size: 24 bytes Description: A PONG packet is a reply to a PING. It is routed by the "pings_puid" field, which is the packet_uid field of the original ping packet. Routing uses this to push the pong back the path where the ping came from. /* As stated above, packet_uid of the respective PING. */ unsigned int pings_puid; /* IPv4 address of replying peer. */ unsigned int myaddr; /* Port of replying peer (default is 443). */ unsigned short myport; /* Six/Four PROTOCOL version. Should be 1. */ unsigned short myversion; /* Link Layer Extensions - currently unused but mandatory field. */ unsigned int myextensions;

Packet type: PT_STARTR Plaintext header: 16 bytes Overall size: variable Description: Requests the initiation of a connection to a host/service outside of the Six/Four network, such as a public webserver. This should be routed to the specified Trusted Peer, which will initiate a connection and set up a "tunnel" (permanent anonymous routing circuit). If this succeeds, packets of type PT_DATA are received back soon after the connection initiation. If it fails, the Trusted Peer may remain silent, and the user has to take care of timing out the connection (locally, in his Download table) and re-requesting it through a different route. For middle-men peer, this packet is routed through, it MUST be passed on to at least one other random peer and MAY be passed on to more than one random peer. If the Trusted Peer is physically connected to a middle man peer, that peer MUST send the packet on to that Trusted Peer. /* Trusted Peer IPv4 address. */ unsigned int tpaddr; /* Control Transmission ID - The Session ID which is randomly chosen by the peer making the connection initiation request. This ID identifies this session for requesting peer, trusted peer and middle-men peers. */ unsigned int ctid; /* STARTREQ_P follows */ /* Data payload follows and is variable length (totlength - 16 - STARTREQ_P), is RSA encrypted with the Trusted Peer's (tpaddr) signed/verified RSA key, and contains initial data to be sent to the outside server by the Trusted Peer right after connection (can be 0 byte sized). */

Packet type: PT_STARTU Plaintext header: 164 bytes Overall size: variable STARTU (UDP Session start requests) are entirely the same as PT_STARTR (TCP start requests), but indicate that the trusted peer should use a udp socket.

Subpacket type: STARTREQ_P (encrypted, description see PT_STARTR above): /* length of the hostname field in bytes */ unsigned short hostlen; /* destination port / service. E.g. port 80. A Trusted Peer MAY * deny access to certain ports/services by access control against * anonymous Six/Four nodes, sending back nothing or a PT_DONE packet. */ unsigned short dstport; /* A random, binary AES key that will be the session encryption key. * Trusted Peer and requesting peer MUST encrypt all subsequent data * (in PT_DATA and PT_CLIR packets) with this negotiated key. */ char aeskey[165]; /* HOSTNAME follows (hostlen bytes) * This is a non-resolved FQDN. Only the Trusted Peer MUST do the resolving. */ /* DATA PAYLOAD follows (LEN = totlen - STSIZE_HEAD - STSIZE_P - hostlen) * The initial data to be sent to the outside server. E.g. for a webserver * something like "GET /". This can be zero-sized. */

Packet type: PT_CLIR Plaintext header: 16 bytes Overall size: variable Description: Subsequent data sent from the requesting peer to the Trusted Peer, to be forwarded to the outside destination associated with this ctid / session. The data payload MUST be encrypted with the negotiated AES key. /* Session ID, see PT_STARTR */ unsigned int ctid; /* Length of original plaintext data (necessary i.e. for binary data) */ unsigned int oplen; /* Original plaintext length */ /* AES-ENCRYPTED: DATA PAYLOAD (LEN = PT_CLIR->total_length - 16) */

Packet type: PT_ACK Overall size: 20 bytes Description: An ACK MUST be sent back by a requested peer when he has received a PT_DATA packet. The sequence number is set to the overall bytes of plaintext received in this session. /* Session ID, see PT_STARTR */ unsigned int ctid; /* Overall number of bytes received */ unsigned int seq_read;

Packet type: PT_DATA Plaintext header: 4 bytes Overall size: variable Description: DATA packets are sent back by a Trusted Peer whenever data is available from an open session (the Trusted Peer MUST keep polling data from outside servers for which sessions are established), as long as previous data that has been sent already has been acknowledged with an ACK. /* Session ID, see PT_STARTR */ unsigned int ctid; /* Original plaintext length */ unsigned int oplen; /* AES-ENCRYPTED DATA_P (LEN = total_length - 4) */

Subpacket type: DATA_P (encrypted): unsigned int seq_writ; /* Overall bytes written */ /* DATA (LEN = PT_DATA->totlen - 4 - 4) */

Packet type: PT_DONE Overall size: 12 bytes Description: Tells either Trusted Peer or requesting peer to finish session. /* Session ID, see PT_STARTR */ unsigned int ctid;

4 Modular Link Layer - "SSL" implementation

PROTOCOL. The SSL implementation uses TCP and SSL. The "SSL" implementation is currently the standard Link Layer.

DEFAULT PORT. The default port for the SSL link layer is 443. The SSL implementation should aim to use the same SSL options as the common HTTPS server implementations, such as Apache-SSL.

ESTABLISHING A CONNECTION (ACTIVE). A peer must connect to a peer by means of a physical TCP connection using connect(). If negotiation fails at any point, the peer must disconnect. Immediately after the TCP connection has been established, a standard SSLv23 layer MUST be negotiated. The SSL Link Layer implementation uses PKCS padding options that make the traffic analysis technique of ciphertext length analysis useless. Since it does so, manual random size padding is not used. One initial packet - the handshake packet - is transmitted over SSL I/O. It consists of:

unsigned int addr; /* This peer's preferred IPv4 address. */ unsigned short port; /* This peer's listening port, if any */ unsigned short version; /* Protocol version = 1 */ unsigned int extensions; /* Extensions - unused yet */

ACCEPTING A CONNECTION (PASSIVE). A peer must accept connections by means of a physical TCP connection using accept(). If negotiation fails at any point, the peer must immediately disconnect. After establishing the TCP connection, a SSLv23 layer MUST be negotiated. PKCS padding options suitable for avoiding traffic analysis MUST be used. The peer now expects to read 12 bytes of data, consisting of:

unsigned int addr; /* Remote peer's supposed IPv4 address. */ unsigned short port; /* Remote peer's listening port */ unsigned short version; /* 1 */ unsigned int extensions; /* Unused */

On receiving all parameters correctly, the connection is considered established and valid and Peer Layer packets may be exchanged.

About this document ...

This document was generated using the LaTeX2HTML translator Version 2002-2 (1.70)

The command line arguments were:
latex2html -no_subdir -split 0 -show_section_numbers /tmp/lyx_tmpdir10755x1TkOh/lyx_tmpbuf6/SIXFOUR-PROTOCOL.tex

The translation was initiated by mixter on 2003-02-14

root 2003-02-14