|
|
|
# Packet Structure
|
|
|
|
|
|
|
|
We said multiple times that the transport level has been rewritten and simplified, but what is the result?
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Green == encrypted
|
|
|
|
|
|
|
|
## Connection ID
|
|
|
|
|
|
|
|
As the name implies, this is what identifies the connection. In truth, two endpoints will have different connection IDs for the same connection. That is because during the handshake each enpoint tell the other which connection id it wants to receive.
|
|
|
|
This means that each party has access to the full 2^32 connection space!
|
|
|
|
|
|
|
|
An other very important thing to notice is that we do not use the IP addresses to identify a connection. multihoming, IP mobility are therefore easily supported without additional effort.
|
|
|
|
|
|
|
|
### Reserver connection IDs
|
|
|
|
|
|
|
|
Not the whole 2^32 space can actually be used for connections.
|
|
|
|
There are 3 different connection IDs that have been reserved:
|
|
|
|
* 0: This is used during the handshake, during the connection setup phase.
|
|
|
|
* 1: [Multicast](Multicast): the content of the packet is from a multicast transmission.
|
|
|
|
* 2: [Proxy](Proxy) support: (future use) this is intended to be used and parsed by any node on the network. With this we will implement explicit and transparent secure proxies that will handle encrypted data. No user tracking, just data caches at the network level. Or a secure CDN (Content Delivery Network) if you will.
|
|
|
|
|
|
|
|
## Encryption Header
|
|
|
|
|
|
|
|
Its size is dependent on which algorithm we use for encryption. In its simplest form it can be a 32-bit counter that will enable us to decrypt each packet individually.
|
|
|
|
|
|
|
|
## Encrypted part (green)
|
|
|
|
|
|
|
|
### Rnd , padding
|
|
|
|
|
|
|
|
The very first thing we encounter is some random padding on the packet. This is put at the beginning to help better randomize the output encryption function (depending on the mode used), but more importantly to randomize the structure of the packet, especially where the content is placed.
|
|
|
|
|
|
|
|
Although encryption algorithm should make this step unnecessary, new attacks against TLS, like BEAST and CRIME, have shown us that traffic analysis is very important, so every step towards twarting traffic and packet analysis is well accepted.
|
|
|
|
|
|
|
|
### Streams
|
|
|
|
|
|
|
|
These next 8 bytes can be repeated multiple times in each packet.
|
|
|
|
|
|
|
|
First we have a stream identifier. The identifier lets us use up to 65k streams, each with its own characteristic: unreliable, reliable, ordered, unordered, bytestream, datagram.
|
|
|
|
|
|
|
|
The flags is actually only 2 bits, that are used to signal the beginning and end of the user message in the case of datagram transmissions.
|
|
|
|
|
|
|
|
The counter is therefore a 30-bit unsigned int, that can overflow as needed. This limits the unacknowledged data to 1GB. Which is really enough, counting that there are 65k more additional streams, the total is somewhere in the range of 65PB. That should be enough for a while...
|
|
|
|
|
|
|
|
## Authentication header
|
|
|
|
|
|
|
|
Also known as HMAC. Not used if the encryption algorithm is an AEAD one.
|
|
|
|
|
|
|
|
## Optionally
|
|
|
|
|
|
|
|
An optional ulterior field (in the future) will be an error correcting code to avoid dropping too many packets due to bitflips or small network errors.
|
|
|
|
|
|
|
|
---- |
|
|
|
\ No newline at end of file |
