gnunet-developers
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [GNUnet-developers] packet size and noise


From: Christian Grothoff
Subject: Re: [GNUnet-developers] packet size and noise
Date: Sat, 15 Jun 2002 20:32:38 -0500

On Saturday 15 June 2002 08:15 pm, you wrote:
> "NOISE must be used to make packets look uniform in size, all packets are
> padded to be 1472 octets long"
>
> I assume the reason for adding noise is to make it harder to determine
> what type of gnunet packet it is.

Yes. But note that any packet can have *multiple* types.

> Is there anything special about 1472, if this size is fairly unique to
> gnunet packets it would be an easy way to detect gnunet on a network.

1472 + UDP header = 1500 octests = Ethernet-frame size = optimal transfer 
size (and thus also always used by TCP!). But note that the 'existance' of 
GNUnet traffic is trivial to detect (port 2086) at the moment; while we have 
plans to tunnel GNUnet-traffic in http and other protocols (and eventually 
hide steganographically), this is far down the road. The goal of the uniform 
size is to make it impossible to say 'this is content', or 'this can not be 
content' for anyone but the 2 nodes involved (read: traffic analysis gets 
very hard).

> Trafic could be further obfuscated by making the packets a fixed size + or
> - some predefined amount, e.g. a random amount of noise is added to make
> its size between 1422 and 1522 bytes (1472 +- 50)

You definitely do not want to go over 1472 octets since the packet will then 
be fragmented on most networks. Also, 'random' padding could still reveil 
some information (since the randomness has still statistical properties). 
Note that this is not as bad as it sounds since GNUnet can for example take a 
1048 octet 'content' message, add two or three 52 octet queries and send this 
in a 'combined' message. Thus 'random' is usually only needed if there is 
nothing else to send - which should also mean that the node is mostly idle. 

Christian




reply via email to

[Prev in Thread] Current Thread [Next in Thread]