Most recent edit on 2008-02-27 01:57:26 by MatthewToseland [delay time]
Additions:
In the current code, hold acknowledgements and messages for up to 100ms before sending. In future it would be useful to be able to make this a function of the round-trip time, so we need an accurate delay time in the packets. Also, some messages may be less urgent than others.
Deletions:
In the current code, hold acknowledgements and messages for up to 100ms before sending. In future it would be useful to be able to make this a function of the round-trip time, so we need an accurate round-trip time in the packets. Also, some messages may be less urgent than others.
Edited on 2007-07-28 20:20:55 by MatthewToseland [reference OldPacketFormat]
Additions:
See OldPacketFormat for details of the current packet format and why it needs to change!
Edited on 2007-06-08 18:55:17 by MatthewToseland [note on coalescing and RTT]
Additions:
Coalescing
In the current code, hold acknowledgements and messages for up to 100ms before sending. In future it would be useful to be able to make this a function of the round-trip time, so we need an accurate round-trip time in the packets. Also, some messages may be less urgent than others.
Edited on 2007-06-08 18:53:28 by MatthewToseland [we need to be able to get an accurate RTT!]
Additions:
- For each ack, the time in milliseconds that the ack was queued for, so we can accurately determine the round-trip time (2 bytes each).
Edited on 2007-03-06 19:33:09 by MatthewToseland
Additions:
- These are encoded as follows: The first (lowest) ack is a full 4-byte unsigned value; subsequent acks are 2 byte unsigned offsets from this (add to the first to get the ack number).
Deletions:
- These are encoded as follows: The first (lowest) ack is a full 4-byte unsigned value; subsequent acks are 2 byte offsets from this (add to the first one to get the ack number).
Edited on 2007-03-06 19:32:45 by MatthewToseland
Additions:
- These are encoded as follows: The first (lowest) ack is a full 4-byte unsigned value; subsequent acks are 2 byte offsets from this (add to the first one to get the ack number).
Edited on 2007-03-06 19:29:30 by MatthewToseland [support multiple acks, a bit more efficient]
Additions:
Each packet contains:
- A count of the number of acks (unsigned byte).
- Zero or more acks. Each ack echoes the payload number of a packet received in the other direction.
- A count of the number of payload messages (unsigned byte). If there are no payload messages, skip the following.
- A 4-byte payload number. This number will be used by the receiver to acknowledge receipt of the packet, and unlike the unique sequence number it will not change if the packet is retransmitted. However, apart from retransmissions the payload number should be unique and non-wrapping.
- Freenet messages follow the payload number. Each message starts with 2 bytes indicating its type followed by 2 bytes indicating its length. Messages are never split across more than one packet.
Deletions:
Each packet contains an ack, a payload number, and zero or more Freenet messages. The ack echoes the payload number (not the unique sequence number) of a packet received in the other direction. A value of -1 indicates that the packet does not contain an ack.
Following the ack there is a 4-byte payload number. This number will be used by the receiver to acknowledge receipt of the packet, and unlike the unique sequence number it will not change if the packet is retransmitted. However, apart from retransmissions the payload number should be unique and non-wrapping. A value of -1 indicates that the packet does not contain a payload and does not need to be acknowledged.
Freenet messages follow the payload number. Each message starts with 2 bytes indicating its type followed by 2 bytes indicating its length. Messages are never split across more than one packet.
Edited on 2007-02-27 13:22:58 by MichaelRogers
Additions:
Each plaintext packet starts with a unique, non-wrapping sequence number. This is distinct from the payload number described below - if a packet is retransmitted, it will have the same payload number as the original, but a new sequence number.
Each packet contains an ack, a payload number, and zero or more Freenet messages. The ack echoes the payload number (not the unique sequence number) of a packet received in the other direction. A value of -1 indicates that the packet does not contain an ack.
Following the ack there is a 4-byte payload number. This number will be used by the receiver to acknowledge receipt of the packet, and unlike the unique sequence number it will not change if the packet is retransmitted. However, apart from retransmissions the payload number should be unique and non-wrapping. A value of -1 indicates that the packet does not contain a payload and does not need to be acknowledged.
Deletions:
This is a summary of some low-level protocol changes that MatthewToseland and MichaelRogers discussed over the summer. Please review them and comment if you have time - it's important to identify bugs before this gets implemented, especially for the crypto parts.
Each plaintext packet starts with a unique, non-wrapping sequence number. This is distinct from the payload number described below - if a packet is retransmitted, it will have the same payload number as the original, but a new sequence number.
Each packet contains zero or more acks and zero or more Freenet messages. After the unique sequence number, there is one byte indicating the number of acks and one byte indicating the number of messages.
Each ack echoes the payload number (not the unique sequence number) of a packet received in the other direction. The first ack in a packet is 4 bytes long, echoing the complete payload number of the acknowledged packet. Each subsequent ack is 2 bytes long and should be interpreted as a positive offset relative to the first ack. As described above, the range of outstanding payload numbers should never exceed 2^16, so a 16-bit offset is adequate.
Following the acks, if the number of messages is greater than zero there is a 4-byte payload number. This number will be used by the receiver to acknowledge receipt of the packet, and unlike the unique sequence number it will not change if the packet is retransmitted. However, apart from retransmissions the payload number should be unique and non-wrapping.
Oldest known version of this page was edited on 2006-11-14 10:30:16 by MichaelRogers []
Page view:
This is a summary of some low-level protocol changes that
MatthewToseland and
MichaelRogers discussed over the summer. Please review them and comment if you have time - it's important to identify bugs before this gets implemented, especially for the crypto parts.
Encryption and Authentication
During handshaking, the peers establish three keys for each direction of the connection: the encryption key, the authentication key, and the IV key. Different keys
must be used in each direction.
Each plaintext packet starts with a unique, non-wrapping sequence number. This is distinct from the payload number described below - if a packet is retransmitted, it will have the same payload number as the original, but a new sequence number.
The IV for encryption is obtained by encrypting the unique sequence number with the IV key. This is equivalent to using a block cipher in CTR mode as a pseudo-random number generator to generate the IVs. The IVs are guaranteed to be unique.
The packet is encrypted in CFB mode using its unique IV and the encryption key. A MAC is then calculated over the encrypted packet using the authentication key, and the MAC is prepended to the encrypted packet.
There is no need to send the packet's unique sequence number in plaintext - the receiver can calculate the IV in advance and the packet is encrypted using a stream cipher, so the receiver can calculate the
ciphertext sequence number in advance. The receiver simply looks for the ciphertext sequence numbers of the next few expected packets instead of looking for the plaintext sequence numbers. This makes it harder for eavesdroppers to identify Freenet traffic, because no part of the packet is in plaintext. A window of 64 sequence numbers should be sufficient to cope with reordering at the IP layer (IPSec uses 32). Note that it is possible, though unlikely, for two packets in the window to have the same ciphertext sequence number due to the random nature of the IVs - the receiver
must detect this case and try both possibilities.
Duplicate Detection
The receiver detects duplicate packets by keeping a bitmap of received payload numbers. The bitmap contains up to 2^16 entries, starting with the lowest payload number not yet received. The sender
must not send payload number n+2^16 until payload number n has been acknowledged - however, it must still send acks when necessary (packets that contain acks but no Freenet messages do not require payload numbers).
Packet Format
Each packet contains zero or more acks and zero or more Freenet messages. After the unique sequence number, there is one byte indicating the number of acks and one byte indicating the number of messages.
Each ack echoes the payload number (not the unique sequence number) of a packet received in the other direction. The first ack in a packet is 4 bytes long, echoing the complete payload number of the acknowledged packet. Each subsequent ack is 2 bytes long and should be interpreted as a positive offset relative to the first ack. As described above, the range of outstanding payload numbers should never exceed 2^16, so a 16-bit offset is adequate.
Following the acks, if the number of messages is greater than zero there is a 4-byte payload number. This number will be used by the receiver to acknowledge receipt of the packet, and unlike the unique sequence number it will not change if the packet is retransmitted. However, apart from retransmissions the payload number should be unique and non-wrapping.
Freenet messages follow the payload number. Each message starts with 2 bytes indicating its type followed by 2 bytes indicating its length. Messages are never split across more than one packet.