Re: [dtn-security] Traffic Analysis Protection

"Weiss, Howard" <Howard.Weiss@sparta.com> Thu, 13 March 2008 21:33 UTC

Received: from M4.sparta.com (M4.sparta.com [157.185.61.2]) by maillists.intel-research.net (8.13.8/8.13.7) with ESMTP id m2DLXu83007398 for <dtn-security@mailman.dtnrg.org>; Thu, 13 Mar 2008 14:33:57 -0700
Received: from Beta5.sparta.com (beta5.sparta.com [157.185.63.21]) by M4.sparta.com (8.13.5/8.13.5) with ESMTP id m2DLcUaK015782 for <dtn-security@mailman.dtnrg.org>; Thu, 13 Mar 2008 16:38:31 -0500
Received: from nemo.columbia.ads.sparta.com (nemo.columbia.sparta.com [157.185.80.75]) by Beta5.sparta.com (8.12.11/8.13.1) with ESMTP id m2DLcV2s014608 for <dtn-security@mailman.dtnrg.org>; Thu, 13 Mar 2008 16:38:31 -0500
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C88552.947BDBAE"
Date: Thu, 13 Mar 2008 17:38:31 -0400
Message-ID: <5ABE30CE099A524CBF95C715D37BCACC01AD363B@nemo.columbia.ads.sparta.com>
In-Reply-To: <676D5FD21A8EEC4591C13839BF2A14B9F166D6@EVS-EC1-NODE4.surrey.ac.uk>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [dtn-security] Traffic Analysis Protection
Thread-Index: AciEWxiWFb6hus6WQ2mKuscYFTMMBQA9ujkg
References: <676D5FD21A8EEC4591C13839BF2A14B9F166D6@EVS-EC1-NODE4.surrey.ac.uk>
From: "Weiss, Howard" <Howard.Weiss@sparta.com>
To: "DTN Security Discussion" <dtn-security@mailman.dtnrg.org>
X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0 (M4.sparta.com [157.185.61.2]); Thu, 13 Mar 2008 16:38:31 -0500 (CDT)
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 21:33:59 -0000

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