Delivery-Date: Sun, 29 Nov 2015 19:32:08 -0500
Return-Path: <tor-talk-bounces@lists.torproject.org>
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on moria.seul.org
X-Spam-Level: 
X-Spam-Status: No, score=-4.2 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_MED,
	T_RP_MATCHES_RCVD,UNPARSEABLE_RELAY autolearn=ham version=3.3.1
X-Original-To: archiver@seul.org
Delivered-To: archiver@seul.org
Received: from eugeni.torproject.org (eugeni.torproject.org [38.229.72.13])
	(using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits))
	(No client certificate requested)
	by khazad-dum.seul.org (Postfix) with ESMTPS id 92C761E093E;
	Sun, 29 Nov 2015 19:32:06 -0500 (EST)
Received: from eugeni.torproject.org (localhost [127.0.0.1])
	by eugeni.torproject.org (Postfix) with ESMTP id 333693718A;
	Mon, 30 Nov 2015 00:32:01 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by eugeni.torproject.org (Postfix) with ESMTP id 28F5D36F9F
 for <tor-talk@lists.torproject.org>; Mon, 30 Nov 2015 00:31:57 +0000 (UTC)
X-Virus-Scanned: Debian amavisd-new at 
Received: from eugeni.torproject.org ([127.0.0.1])
 by localhost (eugeni.torproject.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id G-003UFjWIR1 for <tor-talk@lists.torproject.org>;
 Mon, 30 Nov 2015 00:31:57 +0000 (UTC)
Received: from mx1.riseup.net (mx1.riseup.net [198.252.153.129])
 (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
 (Client CN "*.riseup.net",
 Issuer "COMODO RSA Domain Validation Secure Server CA" (not verified))
 by eugeni.torproject.org (Postfix) with ESMTPS id F1D0F36CF6
 for <tor-talk@lists.torproject.org>; Mon, 30 Nov 2015 00:31:56 +0000 (UTC)
Received: from piha.riseup.net (unknown [10.0.1.163])
 (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits))
 (Client CN "*.riseup.net",
 Issuer "COMODO RSA Domain Validation Secure Server CA" (verified OK))
 by mx1.riseup.net (Postfix) with ESMTPS id D9B021A1E0E
 for <tor-talk@lists.torproject.org>; Sun, 29 Nov 2015 16:31:53 -0800 (PST)
Received: from [127.0.0.1] (localhost [127.0.0.1]) (Authenticated sender: phw)
 with ESMTPSA id 86FFE1C01A8
Date: Sun, 29 Nov 2015 19:31:52 -0500
From: Philipp Winter <phw@nymity.ch>
To: tor-talk@lists.torproject.org
Message-ID: <20151130003152.GE3146@nymity.ch>
Mail-Followup-To: tor-talk@lists.torproject.org
References: <CAPrtOHP7CGRmrcsHNc7KtSA2Cm1NJ=Af1i5CMf7y=LN3H5q2_g@mail.gmail.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <CAPrtOHP7CGRmrcsHNc7KtSA2Cm1NJ=Af1i5CMf7y=LN3H5q2_g@mail.gmail.com>
X-PGP-Fpr: B369 E7A2 18FE CEAD EB96  8C73 CF70 89E3 D7FD C0D0
X-Virus-Scanned: clamav-milter 0.98.7 at mx1.riseup.net
X-Virus-Status: Clean
Subject: Re: [tor-talk] TOR and Obfsproxy packet size
X-BeenThere: tor-talk@lists.torproject.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: tor-talk@lists.torproject.org
List-Id: "all discussion about theory, design,
 and development of Onion Routing" <tor-talk.lists.torproject.org>
List-Unsubscribe: <https://lists.torproject.org/cgi-bin/mailman/options/tor-talk>, 
 <mailto:tor-talk-request@lists.torproject.org?subject=unsubscribe>
List-Archive: <http://lists.torproject.org/pipermail/tor-talk/>
List-Post: <mailto:tor-talk@lists.torproject.org>
List-Help: <mailto:tor-talk-request@lists.torproject.org?subject=help>
List-Subscribe: <https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk>, 
 <mailto:tor-talk-request@lists.torproject.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Errors-To: tor-talk-bounces@lists.torproject.org
Sender: "tor-talk" <tor-talk-bounces@lists.torproject.org>

On Sun, Nov 29, 2015 at 06:35:12PM +0330, Amin s wrote:
>    1. TOR cell size is 512 bytes but most TOR packets have size of 586
>    bytes [1].
> 
> My question is that why there is such difference in size (74 bytes
> difference)?

The difference is caused by the protocol headers that are wrapped around
Tor cells; IP, TCP, and TLS.

>    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 link [1] ?

How did you run your test?  543 sounds like the TCP segment length and
not like the length of the IP packet.

Also, obfsproxy is just a framework.  Which obfuscation protocol did you
run?  Obfs3?

>    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?)

First, Tor has static-length and variable-length cells, so it's not
entirely fixed.  Second, what actually ends up on the wire isn't only up
to the tor client.  It depends on TCP, which tries to fill the link MTU
if there's enough data in the send buffer.

> [1] http://arxiv.org/pdf/1305.3199.pdf

You should read the peer-reviewed version of this paper instead:
<http://www.cs.kau.se/philwint/pdf/wpes2013.pdf>

Cheers,
Philipp
-- 
tor-talk mailing list - tor-talk@lists.torproject.org
To unsubscribe or change other settings go to
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk

