Re: [dtn-security] How do you feel about Bonjour/Avahi?

"Graham Keellings (Leonix Solutions Pte Ltd)" <Graham@LeonixSolutions.com> Fri, 10 July 2009 06:48 UTC

Received: from sky.fastbighost.net (sky.fastbighost.net [76.76.22.153]) by maillists.intel-research.net (8.13.8/8.13.8) with ESMTP id n6A6m07R015382 for <dtn-security@maillists.intel-research.net>; Thu, 9 Jul 2009 23:48:01 -0700
Received: from dyn98-b60-access.superdsl.com.sg ([202.73.60.98] helo=[192.9.200.103]) by sky.fastbighost.net with esmtpa (Exim 4.69) (envelope-from <Graham@LeonixSolutions.com>) id 1MP9su-0003x2-ET; Fri, 10 Jul 2009 02:47:05 -0400
Message-ID: <4A56E3E5.6010304@LeonixSolutions.com>
Date: Fri, 10 Jul 2009 14:47:01 +0800
From: "Graham Keellings (Leonix Solutions Pte Ltd)" <Graham@LeonixSolutions.com>
Organization: Leonix Solutions Pte Ltd
User-Agent: Thunderbird 2.0.0.22 (X11/20090608)
MIME-Version: 1.0
To: Kamal Srinivasan <kamal.srini@gmail.com>, "dtn-security@maillists.intel-research.net" <dtn-security@maillists.intel-research.net>
References: <89E48AE60E64EF4E8EB32B0B7EC74920A1B0F5@EVS-EC1-NODE2.surrey.ac.uk> <4A46C257.3040006@LeonixSolutions.com> <4A46FBB2.3080205@LeonixSolutions.com> <4A470CD7.4010502@LeonixSolutions.com> <4A4878A6.7010707@LeonixSolutions.com> <20090629123400.1726285002@smtp.mac.com> <C304DB494AC0C04C87C6A6E2FF5603DB2217B29183@NDJSSCC01.ndc.nasa.gov> <4A497B04.3070909@LeonixSolutions.com> <20090630122842.1049441707@smtp.mac.com> <4A556063.2010305@LeonixSolutions.com> <845de72a0907082029x46d47e89r6c46093c78d11ad5@mail.gmail.com>
In-Reply-To: <845de72a0907082029x46d47e89r6c46093c78d11ad5@mail.gmail.com>
Content-Type: multipart/mixed; boundary="------------060402000400060801090208"
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - sky.fastbighost.net
X-AntiAbuse: Original Domain - maillists.intel-research.net
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - LeonixSolutions.com
X-Source:
X-Source-Args:
X-Source-Dir:
Subject: Re: [dtn-security] How do you feel about Bonjour/Avahi?
X-BeenThere: dtn-security@maillists.intel-research.net
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: DTN Security Discussion <dtn-security.maillists.intel-research.net>
List-Unsubscribe: <http://maillists.intel-research.net/mailman/listinfo/dtn-security>, <mailto:dtn-security-request@maillists.intel-research.net?subject=unsubscribe>
List-Archive: <http://maillists.intel-research.net/pipermail/dtn-security>
List-Post: <mailto:dtn-security@maillists.intel-research.net>
List-Help: <mailto:dtn-security-request@maillists.intel-research.net?subject=help>
List-Subscribe: <http://maillists.intel-research.net/mailman/listinfo/dtn-security>, <mailto:dtn-security-request@maillists.intel-research.net?subject=subscribe>
X-List-Received-Date: Fri, 10 Jul 2009 06:48:01 -0000

Kamal Srinivasan wrote:
> Graham,
> Our research group @ Univ. of Wisconsin have been working on Anonymous
> communication and Key Management in DTN.
>   
There is a whole Venn-digram of terminology overlap here. Althogu I 
mention DTN, ad-hoc is also a defining phrase for me - which means that 
I can't have a dedicated node as a DNS or key server, since talking out 
hat node makes my network useless.


> Short ans: Our perspective is...it boils down as to how paranoid the app.
> developer over DTN is with security.  
As paranoid as possible, in my case - military grade or more - but of 
course there is a trade-off in terms of time & resources needed to add 
this security


> This really drives where the ACL policies reside in the stack.
>
>   
All over, I think ...

> A not so short ans:
>
> In DTNs, if the connectivity is sparse enough you want to exploit as many
> opportunities as you could. 
That seems to imply an open and trusting network, whereas I am thinking 
of a closed and mistrusting one.

> In such scenarios it would benefit from blaring
> out than hard coding and relying on meeting the hard coded IP devices.  This
> becomes a serious concern when you have unplanned mobility scenarios, where
> you know lesser about the network. So it really depends on what class of DTN
> you are looking into.
>   
"Secure" whatever that means - enough to satisfy banking, the military, 
etc - closed and suspicious, if not paranoid.  But I think we are 
missing an overall discussion of this sort f thing - maybe even just a 
table - showing the trade off between how much security you want and 
what it will cost you.

> If you were to blare out and have approp. policies in place at the BP layer,
> that can be controlled by the app. then you could blare out and still be
> secure. Even if you were not to broadcast, many underlying comm. methods
> would in common scenarios (for ex. in 802.11).
But there are many layers of worry - even bog-standard DOS attacks could 
give grief to my network.

>  We tried to develop an
> anonymous communication sub-layer on top of the sensor nodes (motes), but
> the underlying layers were revealing enough entropy of information.
>
> The above two observations, led us to think of designs that would let the
> user control broadcast, but enable such comm. if the developer thinks it
> would benefit for them to use such blaring for their app.
>
> thanks,
> kamal
>   
Thanks _very_ much for taking the time to send such a long and well 
formulated answer.

/graham


>
> On Wed, Jul 8, 2009 at 10:13 PM, Graham Keellings (Leonix Solutions Pte Ltd)
> <Graham@leonixsolutions.com> wrote:
>
>   
>> From a security standpoint?
>>
>> How secure is it to have all of my nodes blaring "here I am, bad guys, come
>> and try to connect to me"?
>>
>> Would I be safer just using hard coded IP address?
>>
>> Thanks in advance for any opinions.
>>
>> ~graham();
>>
>> _______________________________________________
>> dtn-security mailing list
>> dtn-security@maillists.intel-research.net
>> http://maillists.intel-research.net/mailman/listinfo/dtn-security
>>
>>
>>     
>
>   


-- 
Technical Director
Leonix Solutions (Pte) Ltd
18 Boon Lay Way
#09-95 TradeHub 21
Singapore 609966
Telephone:+65 6316 9968
Fax: +65 6316 9208