Re: [dtn-security] Traffic Analysis Protection

"HUANG, CHIN-TSER" <HUANGCT@engr.sc.edu> Thu, 13 March 2008 22:14 UTC

Received: from HUB0.engr.sc.edu (hub0.engr.sc.edu [129.252.21.22]) by maillists.intel-research.net (8.13.8/8.13.7) with ESMTP id m2DMEGxG009766 for <dtn-security@mailman.dtnrg.org>; Thu, 13 Mar 2008 15:14:16 -0700
Received: from MAIL.engr.sc.edu ([129.252.21.20]) by HUB0.engr.sc.edu ([129.252.21.22]) with mapi; Thu, 13 Mar 2008 18:18:50 -0400
From: "HUANG, CHIN-TSER" <HUANGCT@engr.sc.edu>
To: DTN Security Discussion <dtn-security@mailman.dtnrg.org>
Date: Thu, 13 Mar 2008 18:18:49 -0400
Thread-Topic: [dtn-security] Traffic Analysis Protection
Thread-Index: AciEWxiWFb6hus6WQ2mKuscYFTMMBQA9ujkgAAE3pjg=
Message-ID: <037FDAC816CE034CAB1AD5F7321B32E364BC3F733C@MAIL.engr.sc.edu>
References: <676D5FD21A8EEC4591C13839BF2A14B9F166D6@EVS-EC1-NODE4.surrey.ac.uk>, <5ABE30CE099A524CBF95C715D37BCACC01AD363B@nemo.columbia.ads.sparta.com>
In-Reply-To: <5ABE30CE099A524CBF95C715D37BCACC01AD363B@nemo.columbia.ads.sparta.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by maillists.intel-research.net id m2DMEGxG009766
Subject: Re: [dtn-security] Traffic Analysis Protection
X-BeenThere: dtn-security@mailman.dtnrg.org
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: DTN Security Discussion <dtn-security@mailman.dtnrg.org>
List-Id: DTN Security Discussion <dtn-security.mailman.dtnrg.org>
List-Unsubscribe: <http://maillists.intel-research.net/mailman/listinfo/dtn-security>, <mailto:dtn-security-request@mailman.dtnrg.org?subject=unsubscribe>
List-Archive: <http://maillists.intel-research.net/pipermail/dtn-security>
List-Post: <mailto:dtn-security@mailman.dtnrg.org>
List-Help: <mailto:dtn-security-request@mailman.dtnrg.org?subject=help>
List-Subscribe: <http://maillists.intel-research.net/mailman/listinfo/dtn-security>, <mailto:dtn-security-request@mailman.dtnrg.org?subject=subscribe>
X-List-Received-Date: Thu, 13 Mar 2008 22:14:17 -0000

I think I really agree with Howie on this point. DTN itself, along with the ferry and throwbox model in particular, achieves the effect similar to the mix cascade network. Therefore it can be resistant to traffic analysis inherently.

Chin-Tser
________________________________________
From: dtn-security-bounces@mailman.dtnrg.org [dtn-security-bounces@mailman.dtnrg.org] On Behalf Of Weiss, Howard [Howard.Weiss@sparta.com]
Sent: Thursday, March 13, 2008 5:38 PM
To: DTN Security Discussion
Subject: Re: [dtn-security] Traffic Analysis Protection

Hmmm, its not at all clear that there is an intersection between DTN and protection against traffic analysis - at least not in terms of full-period traffic-flow-security where the presence or absence of traffic is totally masked on the wire.

Traffic analysis is prevented by making all parts of the radiated bits opaque - not an easy thing to do in a DTN environment.  And since bundles are forwarded in an opportunistic manner, without necessarily having an end-2-end connection established, how could one continally send dummy traffic to keep the "pipe" filled when there really isn't a pipe to fill.  If one tried to do this on a hop-by-hop basis between bundle nodes, it would create a massive denial of service attack.

Howie

From: dtn-security-bounces@mailman.dtnrg.org [mailto:dtn-security-bounces@mailman.dtnrg.org] On Behalf Of M.Bhutta@surrey.ac.uk
Sent: Wednesday, March 12, 2008 12:07 PM
To: dtn-security@mailman.dtnrg.org
Subject: [dtn-security] Traffic Analysis Protection


Hello,
I am working on traffic analysis protection for DTN networks. From the "DTN Security Internet Draft" there are some
questions about this which I wanted to be discussed on the DTNRG security mailing list.

1. To what extent there is a real need for a generic scheme for protection against traffic analysis.
2. How to define such generic scheme for delay and disruption tolerant networks and should not consume too much resources like for Sensors.
3. Should Traffic analysis protection be left on underlying network layers than DTN layer.

To completely stop the traffic analysis, following counter-measures should be taken into account to avoid the traffic analysis:
1. Encryption
2. Masking (sending dummy traffic like encrypted message to show channedl 100% busy)
3. Hiding time and size information of traffic

taking into considerations the above questions and the counter-measures, we can go towards how we should provide such a solution for
DTN Networks and which counter-measures are realy important for DTN based networks while considering the internet networks and non-internetnetworks like sensor networks and the solution should use less resources as possible.

best regards
Nasir