[freenet-dev] SSK packet sizes quick fix

Fri Mar 7 14:40:08 UTC 2008

On Friday 07 March 2008 14:13, Matthew Toseland wrote:
> One of the problems alluded to in the other mail was that SSK inserts and 
> successful SSK requests are traceable to a global traffic analyst capable of 
> detecting freenet traffic and packet sizes. Specifically, this is true 
> because of the huge size of the messages. Which also exacerbates MTU 
> problems. Details:
> SSK insert reques: 1274 bytes
> SSK data found: 1168 bytes
> 
> Even with padding, these become extremely obvious, unless there is a vast 
> amount of small messages coalesced with them and concealing them. Which is 
> not normally the case, and IMHO is not a reliable cloak even on high traffic 
> nodes.
> 
> So our profile currently looks like this:
> 
> 64+64:  37 (lots of stuff)
> 128+64: 101 (CHK request, SSK request, swap reply, most opennet stuff, data 
> insert, offers, get offered CHK, CHK insert request[, SSKInsertRequestNew])
> 192+64: 165 (get offered SSK[, SSKDataFoundNew, SSKInsertRequestHeaders])
> 256+64: 197 (swap commit/complete)
> 320+64: 229 (nothing)
> 1088+64: 1061 (bulk transmit, block transmit, time deltas, SSK pubkey[, 
> SSKData, SSKDataInsert])
> 1152+64: 1125 (nothing)
> 1216+64: 1189 (SSK data found)
> 1280+64: 1253 (nothing)
> 1344+64: 1317 (SSK insert request)
> 
> Formatting:
> <payload size including overhead of 27 bytes>+<average random padding and 
hash 
> size>: <size of message> (messages). Note that the [] above refer to my 
> proposed new messages. Also the above demonstrates why I am unwilling to use 
> multiples of 32 instead of 64 for padding.
> 
> We are therefore reasonably safe from packet size analysis ... except for 
SSK 
> data found and SSK insert, which are *easily* identifiable. And the latter's 
> size is a problem.
> 
> I propose to split up SSKInsertRequest and SSKDataFound as follows:
> 
> SSKDataFoundNew: UID(8) + headers(136) = 144
> SSKData: UID(8) + data (1024) = 1032
> SSKInsertRequestNew: UID (8) + key (66) + htl (2) = 76
> SSKInsertRequestHeaders: UID (8) + headers (136) = 144
> SSKDataInsert: UID (8) + data (1024)
> 
> So:
> 
> For an SSK insert, we have a 76 byte insert request (could be a lot of 
> things), which is then Accepted (8 bytes, again could be almost anything, 
but 
> requests are accepted too). Then we send the data and the headers (144 and 
> 1032).
> 
> Right now, only certain messages are subject to congestion control and 
> bandwidth limiting: bulk transmit packets and block transmit packets. We 
> could send SSKData/SSKDataInsert as throttled packets (we might need to 
> increase the timeout to compensate for this). If we do, the 1032 byte packet 
> and the 144 byte packet will not usually be combined, so the former will not 
> be distinguishable from a bulk/block transfer (if one is going on), and the 
> latter could be a get-offered-SSK, or an offer-SSK combined with one or more 
> other messages if we're lucky. Thus hopefully as soon as the attacker 
reaches 
> a busy node he will lose the trail.
> 
> We could further improve things by making 1088 the biggest packet payload we 
> send. This would prevent the 1032 and 144 being combined into a signature 
> 1176 byte packet when there is low traffic. It would cost a small amount of 
> efficiency on links with high MTUs, but it would prevent major problems on 
> links with low MTUs.
> 
> So:
> 5 new messages.
> 2 of which go through PeerNode.sendThrottled().
> Some rewriting of the SSK requestors/insertors code. Which can be tested 
using 
> freenet/node/simulator/.
> Timeouts may need tweaking, we can allocate fairly generous ones to start 
> with.
> 

Here are my notes on packet sizes. They might interest some folk here, and 
they should be archived somewhere other than my TODO file!

Base internal overhead: 27
Hash overhead: 32
Average padding overhead: 32

Current:

64+64:  37 (lots of stuff)
128+64: 101 (CHK request, SSK request, swap reply, most opennet stuff, data 
insert, offers, get offered CHK, CHK insert request[, SSKInsertRequestNew])
192+64: 165 (get offered SSK[, SSKDataFoundNew, SSKInsertRequestAltNew])
256+64: 197 (swap commit/complete)
320+64: 229 (nothing)
1088+64: 1061 (bulk transmit, block transmit, time deltas, SSK pubkey[, 
SSKData, SSKDataInsert])
1152+64: 1125 (nothing)
1216+64: 1189 (SSK data found)
1280+64: 1253 (nothing)
1344+64: 1317 (SSK insert request)

That last one really sucks!

Multiples of 32:

32+48: 5 (nothing)
64+48: 37 (lots)
96+48: 69 (CHK request, CHK insert, opennet announcement, CHK offer, swap 
reply)
128+48: 101 (SSK request, get offered CHK, offer SSK[, SSKInsertRequestNew)
160+48: 133 (get offered SSK)
192+48: 165 ([SSKDataFoundNew, SSKInsertRequestAltNew)
224+48: 197 (swap commit/complete)
256+48: 229 (nothing)
1056+48: 1029 (nothing)
1088+48: 1061 (bulk transmit, block transmit, time deltas, SSK pubkey[, 
SSKData, SSKDataInsert])

Computation: (size + acks etc (one byte each) + 2 per message + 27) -> round 
up to next 64, add random 0...63 bytes. Then add the 32 bytes hash.

So... lots is shorter than 14, for example. 14 + 2 + 27 -> 43 -> 64 -> 96 -> 
128

64-29 = 35. Anything up to 35 fits in a minimal packet (128).

For a CHK request, a data insert, an announcement, a CHK found, we have 50 (44 
if we drop the 8 in the CHK request for nearest-so-far)
50 + 2 + 27 -> 79 -> 128 -> 160 -> 192

Anything up to 99 fits in a normal packet. Including a request, a lot of acks, 
etc.

Size 3: 192 -> 160. 192-59 = 

bulk transmit: 1036
block transmit: 1024+8+4+4+4=1044
CHK request: 50*
SSK request: 83*
Rejected Overload: 9
Accepted: 8
Data Not Found: 8
Recently Failed: 12
CHK found: 44
Route Not Found: 10
Insert request: 52
Insert reply: 8
Data insert: 44 (only used for CHKs)
Transfers completed: 9
Insert rejected timeout: 8
DataInsert rejected: 10
SSK insert request: 1024+32+136+8+64+2+8=1274 (ouch!)
SSK data found: 8+136+1024=1168
SSK accepted: 9
SSK pubkey: 1032
SSK pubkey accepted: 8
Opennet completed ack: 8
Opennet connect destination: 24
Opennet connect reply: 24
Opennet announcement: 42
Opennet announce reply: 24
Announce completed: 8
Opennet disabled: 8
Opennet noderef rejected: 12
Opennet node not wanted: 8
Offer key: 32(auth)+34 or 32(auth)+66 = 66 or 98
Get offered key: 9+32+34 or 9+32+66 = 75 or 107
Get offered key invalid: 10
Swap request: 14
Swap rejected: 8
Swap reply: 44
Swap commit: 24+#peers*8 (so typically 188)
Swap complete: 24+#peers*8 (so typically 188)
Location change: 8
Detected IP: 11 (IPv4, no hostname) or 23 (IPv6, no hostname)
Time: 8
Time deltas: up to 64*8*2+8 = 1032
Void: 0
Disconnect: 8 + attached message length

Suppose we split the big messages:
SSKDataFoundNew: 8+136 (just the headers and the UID)
SSKData: 8+1024
SSKInsertRequestNew: 8(uid)+66(key)+2(htl)
SSKInsertRequestAltNew: 8(uid)+136(headers)
SSKDataInsert: 8(uid)+1024(data)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://emu.freenetproject.org/pipermail/devl/attachments/20080307/5d6d9510/attachment.pgp 