The M2 network is a thin layer of addressing on top of IP with no central user or addressing administration. The M2 network allows freely chosen user identities and have no central user identity directory by design http://rxcare.net/gen...
- Scalable, handling unlimited numbers of peers.
- Support asynchronous and synchronous messaging.
- Support simple packet streaming.
- Support all NAT traversals.
- Have a reliable handshake and message delivery protocol.
- Have its own logical addressing on top of IP.
- Support private, isolated realms (circles).
- Encrypt peer to peer sessions (ad-hock keys, packet level).
The network are designed for low user visibility, none meta-data storage and logging and are based on the simplest component of the Internet, the UDP packet transport.
UDP send messages one by one with no session control and are more reliable for low intercept and none user disclosure tactics than the session based TCP protocol.
The thin addressing layer of m2 are designed and operate on the principle of exist when alive, gone when dead meaning that dead peers or identities do not exist on the network either on any servers or in any persisted logs. When alive, the peer only exists as a temporary neutral address and any IP address/port in some server’s memory.
The basic design of the m2 network is peer communicating directly (peer to peer) using a cloud (sky) of services (supporters) to make a connection to each other. This service is an undefined number of services located around on the Internet in various clouds and on single servers.
The Look-up services are called KA server’s and their are cooperating together to inform peers about the physical IP addresses to each other. The core look-up task.
The look-up have the following characteristics
- Look-up is based on a common truth (the address of all services) shared dynamically by all services and peers in combination with a non-structured algorithm for locating the other peer’s.
- Peer real identities, including addressing realms, must be agreed from outside the m2 network.
- The peers identify them-self with a calculated hashed id to a set of KA services when starting.
- The peer identify disappear permanently from the services while peer stops.
- The size of the hash is so big that the network does not need a central identity register to operate. For all practical purposes, any hash is unique (like a GUID/UUID).
- All look-up’s are ad-hock and operate in service memory.
Peer to peer sessions
- A session send data between two peers using UDP messages.
- A session encrypt the data between two peers. Each session is encrypted on a UDP packet level with a session initiated private / public RSA keys and AES keys.
- A data transport are reliable with a handshake and re-send (up to 1MB message size recommended).
- Speed is variable based on physical line speed and quality, based on measuring of success-rate of transport UDP packets.
- A session TTL (time to live) is when connected and 30 second when no ping response (10 second ping between the peers for timeout), and 2 minutes when no data is sent between the parties.
- When a session is dead, the m2 message level enables a new session seamless and invisible to the supported application, and the application ‘thinks’ there is one long communication session between open and close.
See also M2 middle-man theory
A sessions between two peers are encrypted with the following procedure
- When client register on KA, a temporary RSA 2048 key is created on the client and the public part is sent to the KA server.
- Client keeps the private part of the key stored in local memory.
- At look-up time (start of session) the KA distribute the other party key to each peer. Each peer, then gets the other party public RSA key.
- A random AES 128 key are created for each client, and sent to the other party, encrypted with the other party public RSA key
- When keys are negotiated, each party decrypts the other party AES key with his own private RSA key
- Each party, then uses the other party AES key to encrypt the data sent to the other party
UDP packet communication
UDP packet’s on the Internet takes whatever route possible and are simply dropped if any obstacle comes in its way. To compensate for this unreliability M2 contains its own handshaking protocol for sending and re-send to obtain reliable message delivery.
The UDP protocol are more discreet and also make NAT traversal more simple and the m2 network, allowing peers to address and communicate from any sub-net (like a home network).
If two peers are located on the same internal network, physical addressing is done directly, otherwise addressing is via the NAT public address. This makes the peer’s in m2 network transparent to each other, regardless of network location.
M2 need UDP access in/out of certain ports. One application needs one port open for service. For minimizing problems with FW’s a process (one application) uses only one physical UDP port for inbound and out-bound communication.