1

I have some questions about TOR and Obfsproxy packet size.

  1. TOR cell size is 512 bytes but most TOR packets have size of 586 bytes.

My question is that why there is such difference in size (74 bytes difference)?

  1. In my own testing, instead of TOR packets with size of 586 bytes, there are packets with size of 543 bytes in TOR traffic and packets with size of 565 bytes in Obfsproxy traffic.

My question here is that why doesn't TOR or Obfsproxy generate 586 bytes? the size that reported in lots of papers like this one ?

  1. In my own testing on TOR traffic, from 9939 packets that were sent from client to server, there were 2648 packets with different sizes than 543, like 126,1086,1629,4101,612 and so on.

If TOR cell size is fixed, then why are there packets with different sizes than 543? (why don't all of the packets have the same 543 bytes in size?)

Relating to above question, there are lots of packets with size of 1460 bytes in backward direction (from server to client). So what happens to the fixed cell size?

  • In your first question, is the size of 586 something you have read about, or something you've seen in your testing? (I've deleted my previous answer because I agree that it doesn't answer the specifics of what you're asking.) – Richard Horrocks Nov 29 '15 at 14:45
  • Size of 586 is the size that were mentioned in some papers, but in my testing, there are no packets with this size, instead there are packets with size 543 (in tor traffic) and size 565 (in obfsproxy traffic). – amin Nov 29 '15 at 14:51
  • When you say the packets are 543 bytes, are you using Wireshark or something similar to determine that? If so, are you looking at the overall packet size, or the data size? – Richard Horrocks Nov 29 '15 at 17:51
  • Yes i am using wireshark . i get the same packet size when using tcpdump. In wireshark there are 5 layers. Application,Transport,IP,Ethernet and physical layer. For the application layer it shows 543 bytes. Overall packet size (including all layers) is 597 bytes. – amin Nov 29 '15 at 19:14
2

TOR cell size is 512 bytes but most TOR packets have size of 586 bytes. My question is that why there is such difference in size (74 bytes difference)?

The 586-byte packet being referenced in the papers is Tor's 512-byte cell wrapped in the headers of three different protocols: TLS, TCP, IP.

In my set up, using Wireshark, I'm seeing lots of outgoing packets with an overall length of 609 bytes. (This is equivalent to your 597 bytes.) This is the "on the wire" size, meaning it also takes into account the Ethernet frame header (which is 14 bytes).

Looking inside the frame, I have the following, in bytes:

Ethernet   size 609  (including header, 14 bytes)
IP         size 595  (including header, 20 bytes)
TCP        size 575  (including header, 32 bytes)
Data       size 543

The size of my 595-byte IP packet is the equivalent to the 586-byte packet referenced in the documents - their number doesn't include the Ethernet header (I think). The difference between these two sizes could be accounted for by noting that TCP and IP headers can vary in size, depending on the type of traffic, what options are used in the headers, and any padding. (I don't have a solid answer for this part - someone else might know better. This could also be where variable-length Tor cells come into play.)

In my own testing, instead of TOR packets with size of 586 bytes, there are packets with size of 543 bytes in TOR traffic and packets with size of 565 bytes in Obfsproxy traffic.

Once the Ethernet, IP and TCP headers are stripped off, we're left with the "data". This is Tor's 512-byte cell together with TLS Application Data, which is used to make Tor traffic look like HTTPS traffic. (This is basically the TLS header and encryption, on which there's a brief discussion in this ticket). On my set up I'm also seeing 543 bytes for the size of this data.

The greater size of data in the Obfsproxy case can probably be explained by padding of some sort.

Relating to above question, there are lots of packets with size of 1460 bytes in backward direction (from server to client). So what happens to the fixed cell size?

The lower-level protocols don't care what data is in the layers above them. They just get passed the data and package it up themselves. Tor's cell size doesn't come into play as this isn't what gets put on the wire.

The data in the outgoing packets will likely be HTTP requests, which are small and will fit into a single Tor cell. Bundle this up with the required headers, and you still have quite a small (i.e. 586/609-byte) packet. This will all fit into a single Ethernet frame, which is what gets sent.

The data in the incoming packets will likely be much larger - e.g. the data associated with a webpage, a file, etc. This data won't fit into a single Tor cell, and has to be split across several. The data from several of these cells can themselves be bundled into a single Ethernet frame. On my set up I'm seeing 1506-byte Ethernet frames (presumably the MTU), which stripped of the Ethernet/IP/TCP headers gives 1440 bytes of data. In this 1440 bytes there is the TLS layer data together with the Tor data. (Where the Tor data is likely two complete cells together with a fragment.)

In my own testing on TOR traffic, from 9939 packets that were sent from client to server, there were 2648 packets with different sizes than 543, like 126,1086,1629,4101,612 and so on.

These are probably fragmentation artefacts, or the ends of particular streams of data. Those that are greater than ~1500 bytes are probably Ethernet jumbo frames. They may also contain parts of different TCP streams combined into the same Ethernet frame (Wireshark should be able to show you this). Either way, the same general point applies: the idea of Tor's cells have been abstracted away by the point the data is put on the line in the form of Ethernet frames.

  • 1
    Fantastic and very comprehensive answer. thanks a lot. maybe later i will ask you some questions about your answer. – amin Nov 30 '15 at 13:38

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.