Subject: Re: [dtn-security] Traffic Analysis Protection
From: "HUANG, CHIN-TSER" <[email-masked]>
To: DTN Security Discussion <[email-masked]>
Date: Thu, 13 Mar 2008 18:18:49 -0400
List-Id: DTN Security Discussion <dtn-security.mailman.dtnrg.org>

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: [email-masked] [[email-masked]] On Behalf Of Weiss, Howard [[email-masked]]
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: [email-masked] [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Wednesday, March 12, 2008 12:07 PM
To: [email-masked]
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

Content-class: urn:content-classes:message
Date: Thu, 13 Mar 2008 17:38:31 -0400
From: "Weiss, Howard" <[email-masked]>
To: "DTN Security Discussion" <[email-masked]>
Subject: Re: [dtn-security] Traffic Analysis Protection
Reply-To: DTN Security Discussion <[email-masked]>

This is a multi-part message in MIME format.

------_=_NextPart_001_01C88552.947BDBAE
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable

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.

=20

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.

=20

Howie

=20

From: [email-masked]
[mailto:[email-masked]] On Behalf Of
[email-masked]
Sent: Wednesday, March 12, 2008 12:07 PM
To: [email-masked]
Subject: [dtn-security] Traffic Analysis Protection

=20

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

------_=_NextPart_001_01C88552.947BDBAE
Content-Type: text/html;
	charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable

<html xmlns:v=3D"urn:schemas-microsoft-com:vml" =
xmlns:o=3D"urn:schemas-microsoft-com:office:office" =
xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" =
xmlns=3D"http://www.w3.org/TR/REC-html40">

<head>
<meta http-equiv=3DContent-Type content=3D"text/html; =
charset=3Dus-ascii">
<meta name=3DGenerator content=3D"Microsoft Word 12 (filtered medium)">
<title>Traffic Analysis Protection</title>
<style>
<!--
 /* Font Definitions */
 @font-face
	{font-family:Calibri;
	panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
	{font-family:Tahoma;
	panose-1:2 11 6 4 3 5 4 4 2 4;}
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:"Times New Roman","serif";}
a:link, span.MsoHyperlink
	{mso-style-priority:99;
	color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{mso-style-priority:99;
	color:purple;
	text-decoration:underline;}
p
	{mso-style-priority:99;
	mso-margin-top-alt:auto;
	margin-right:0in;
	mso-margin-bottom-alt:auto;
	margin-left:0in;
	font-size:12.0pt;
	font-family:"Times New Roman","serif";}
span.EmailStyle18
	{mso-style-type:personal-reply;
	font-family:"Calibri","sans-serif";
	color:#1F497D;}
.MsoChpDefault
	{mso-style-type:export-only;
	font-size:10.0pt;}
@page Section1
	{size:8.5in 11.0in;
	margin:1.0in 1.0in 1.0in 1.0in;}
div.Section1
	{page:Section1;}
-->
</style>
<!--[if gte mso 9]><xml>
 <o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
 <o:shapelayout v:ext=3D"edit">
  <o:idmap v:ext=3D"edit" data=3D"1" />
 </o:shapelayout></xml><![endif]-->
</head>

<body lang=3DEN-US link=3Dblue vlink=3Dpurple>

<div class=3DSection1>

<p class=3DMsoNormal><span =
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>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.<o:p></o:p></span></p>

<p class=3DMsoNormal><span =
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p>&nbsp;</o:p></span></p>

<p class=3DMsoNormal><span =
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>Traffic analysis is prevented by making all parts of the
radiated bits opaque - not an easy thing to do in a DTN =
environment.&nbsp; 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 &quot;pipe&quot; filled when there really isn't a =
pipe to
fill.&nbsp; If one tried to do this on a hop-by-hop basis between bundle =
nodes,
it would create a massive denial of service =
attack.<o:p></o:p></span></p>

<p class=3DMsoNormal><span =
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p>&nbsp;</o:p></span></p>

<p class=3DMsoNormal><span =
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>Howie<o:p></o:p></span></p>

<p class=3DMsoNormal><span =
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p>&nbsp;</o:p></span></p>

<div style=3D'border:none;border-left:solid blue 1.5pt;padding:0in 0in =
0in 4.0pt'>

<div>

<div style=3D'border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt =
0in 0in 0in'>

<p class=3DMsoNormal><b><span =
style=3D'font-size:10.0pt;font-family:"Tahoma","sans-serif"'>From:</span>=
</b><span
style=3D'font-size:10.0pt;font-family:"Tahoma","sans-serif"'> =
[email-masked]
[mailto:[email-masked]] <b>On Behalf Of =
</b>[email-masked]<br>
<b>Sent:</b> Wednesday, March 12, 2008 12:07 PM<br>
<b>To:</b> [email-masked]<br>
<b>Subject:</b> [dtn-security] Traffic Analysis =
Protection<o:p></o:p></span></p>

</div>

</div>

<p class=3DMsoNormal><o:p>&nbsp;</o:p></p>

<p style=3D'margin-bottom:12.0pt'><span =
style=3D'font-size:10.0pt'>Hello,<br>
I am working on traffic analysis protection for DTN networks. From the
&quot;DTN Security Internet Draft&quot; there are some<br>
questions about this which I wanted to be discussed on the DTNRG =
security
mailing list.<br>
<br>
1. To what extent there is a real need for a generic scheme for =
protection
against traffic analysis.<br>
2. How to define such generic scheme for delay and disruption tolerant =
networks
and should not consume too much resources like for Sensors.<br>
3. Should Traffic analysis protection be left on underlying network =
layers than
DTN layer.<br>
<br>
To completely stop the traffic analysis, following counter-measures =
should be
taken into account to avoid the traffic analysis:<br>
1. Encryption<br>
2. Masking (sending dummy traffic like encrypted message to show =
channedl 100%
busy)<br>
3. Hiding time and size information of traffic<br>
<br>
taking into considerations the above questions and the counter-measures, =
we can
go towards how we should provide such a solution for<br>
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.<br>
<br>
best regards<br>
Nasir</span><o:p></o:p></p>

</div>

</div>

</body>

</html>

------_=_NextPart_001_01C88552.947BDBAE--

From: Rajesh Krishnan <[email-masked]>
To: DTN Security Discussion <[email-masked]>
Organization: BBN Technologies
Date: Thu, 13 Mar 2008 17:08:33 -0400
Subject: Re: [dtn-security] Re(2):  Traffic Analysis Protection
Reply-To: [email-masked], DTN Security Discussion <[email-masked]>

Hi Peter,

> As you say, bundle-in-bundle encapsulation is a solution but ... you
> have to have *some* addressing *somewhere*.  

Agreed that this is typically true. Here is a fun thought though.

As a corner case, in small lightly-loaded networks, we could encrypt
messages with no "addresses" and share them epidemically or via other
addressless routing means.  If a node is able to decrypt it, then it is
for a specific endpoint on that node.  Otherwise it just passes it
along.  Extreme case of late binding.

The BP requires the source endpoint ID to be present to create a unique
ID.  By using a common source endpoint ID and by allocating the bundle
sequence space among nodes (doable in lightly loaded, small networks) we
could go "address-less".

Best Regards,
Rajesh

From: "Peter Lovell" <[email-masked]>
To: "dtn security" <[email-masked]>, "Stephen Farrell" <[email-masked]>, <[email-masked]>
Date: Thu, 13 Mar 2008 15:14:14 -0500
Subject: [dtn-security] Re(2):  Traffic Analysis Protection
Reply-To: DTN Security Discussion <[email-masked]>

On Thu, Mar 13, 2008, Stephen Farrell <[email-masked]> wrote:

>The BP's not that good in this respect, since we can't encrypt
>the primary bundle,

Hi Stephen,

minor terminology correction. It's the "primary block" that we can't
encrypt -- the one containing addresses etc.

As you say, bundle-in-bundle encapsulation is a solution but ... you
have to have *some* addressing *somewhere*.  Were I a professor, I'd
assign that as an advanced exercise for the class :)

Cheers.....Peter

p.s. I listened on the audio feed and thought it was a good session --
well done.

Date: Thu, 13 Mar 2008 19:49:53 +0000
From: Stephen Farrell <[email-masked]>
To: DTN Security Discussion <[email-masked]>
Subject: Re: [dtn-security] Traffic Analysis Protection
Reply-To: DTN Security Discussion <[email-masked]>

[email-masked] wrote:
> 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)

I'd be interested in how you would do that without causing
yourself a DoS, i.e in what circumstances would fake traffic
be safe?

> 3. Hiding time and size information of traffic

The BP's not that good in this respect, since we can't encrypt
the primary bundle, so you'd probably have to do bundle in
bundle encapsulation. Again, I'd be interested in what you come
up with,
Regards,
Stephen.

> 
> 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
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> dtn-security mailing list
> [email-masked]
> http://maillists.intel-research.net/mailman/listinfo/dtn-security

Date: Wed, 12 Mar 2008 18:20:26 -0400
From: Urs Hengartner <[email-masked]>
Organization: University of Waterloo
To: DTN Security Discussion <[email-masked]>
Subject: Re: [dtn-security] Traffic Analysis Protection
Reply-To: DTN Security Discussion <[email-masked]>

Hi Nasir,

We very briefly looked at traffic analysis during the design of our 
security and anonymity architecture for DTNs. Please refer to section 
VII.C of our SecureComm paper:
http://www.cs.uwaterloo.ca/~uhengart/securecomm07.1.pdf

Best,
  Urs

[email-masked] wrote:
> 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
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> dtn-security mailing list
> [email-masked]
> http://maillists.intel-research.net/mailman/listinfo/dtn-security

Content-class: urn:content-classes:message
Date: Wed, 12 Mar 2008 16:06:56 -0000
From: <[email-masked]>
To: <[email-masked]>
Subject: [dtn-security] Traffic Analysis Protection
Reply-To: DTN Security Discussion <[email-masked]>

This is a multi-part message in MIME format.

------_=_NextPart_001_01C8845B.189B6980
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

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

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.=20

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=20
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.=20

best regards
Nasir=20

------_=_NextPart_001_01C8845B.189B6980
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
6.5.7652.24">
<TITLE>Traffic Analysis Protection</TITLE>
</HEAD>
<BODY>
<!-- Converted from text/plain format -->

<P><FONT SIZE=3D2>Hello,<BR>
I am working on traffic analysis protection for DTN networks. From the =
&quot;DTN Security Internet Draft&quot; there are some<BR>
questions about this which I wanted to be discussed on the DTNRG =
security mailing list.<BR>
<BR>
1. To what extent there is a real need for a generic scheme for =
protection against traffic analysis.<BR>
2. How to define such generic scheme for delay and disruption tolerant =
networks and should not consume too much resources like for Sensors.<BR>
3. Should Traffic analysis protection be left on underlying network =
layers than DTN layer.<BR>
<BR>
To completely stop the traffic analysis, following counter-measures =
should be taken into account to avoid the traffic analysis:<BR>
1. Encryption<BR>
2. Masking (sending dummy traffic like encrypted message to show =
channedl 100% busy)<BR>
3. Hiding time and size information of traffic<BR>
<BR>
taking into considerations the above questions and the counter-measures, =
we can go towards how we should provide such a solution for<BR>
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.<BR>
<BR>
best regards<BR>
Nasir<BR>
<BR>
</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C8845B.189B6980--