Re: [dtn-security] Newbie seeking some security related advice

[Armando Caro <[e-mail]>]

Ivancic, William D. (GRC-RHN0) wrote:
> ->Armando Caro wrote:
> ->What about "transiently" disconnected nodes? Can we accept loss of
> ->transmission for a fraction of a second? Or even a few seconds?
> ->
> 
> That is up to the acceptability of the end user.  For example, I prefer the grainy ghost of analog TV to Digital TV with interrupted voice bits and pixilation during signal fades.
> 
> ->If I stipulate a network that carries primarily voice traffic (albeit
> ->as VoIP), then what does DTN bring me? I could argue that it adds a
> ->degree of complexity that brings no gain.  
> 
> I would agree.
> 
> ->I suppose that the gain is
> ->that the network is distributed and has no central infrastructure
> ->(although, to split hairs, that is an ah-hoc network, which not all DTN
> ->need to be); I can see that that would be attractive to DARPA.
> 
> A DTN can be an overlay on an Ad Hoc network or an overlay on a fixed fully connected network or an overlay on a predictive network like a deep space network or a combination.  My personal view of a DTN to date is an application level store-and-forward gateway and/or potentially a secure content storage and distribution network.  Until we get some type of scalable naming structure, I don't see this scaling very well.
> 

I'm confused, because I don't remember writing the words above that you 
quoted me as saying.

I did say the following paragraph:
> ->> One important take-away from this work... the motivation of DTN is to
> ->> support delay/disrupted scenarios and apps that can operate in that
> ->> regime, but it is possible to implement a DTN stack that can also
> ->deal with time-sensitive traffic.

> One thing I see is that many non-technical or even technical, but uninformed/misinformed people think DTN is a magic box that you put in front of applications that require a connected network and it makes them work in a disconnected, store-and-forward, environment.  

I agree that there are many people who are uninformed about what exactly 
DTN is and how it works.

> 
> I think we need to educate people that this is not the case.

I agree.

> However, I think that sometimes we don't in order to obtain/retain funding.

It's always important to educate the customer funding a project, because 
otherwise the customer will have unrealistic expectations. I think (at 
least I would hope) that people involved in acquiring funding understand 
that it is critical to ensure that a customer maintains realistic 
expectations. Otherwise the end result will be a failure in the eyes of 
the customer, and that is detrimental to future funding prospects from 
that same customer.

There is nothing dishonest about the claim that BBN's DTN stack is able 
to handle time-sensitive VoIP traffic. In Dec 2008, we demo'd this 
capability for small multihop wireless networks. The point we are trying 
to make in the WNaN program is that there should be a single network 
stack and it should include DTN functionality. The applications should 
specify whether or not their traffic should tolerate delays/disruptions. 
Then when disruptions occur, the "DTN functionality" is invoked only for 
the app traffic that is declared to be delay/disruption tolerant.

Armando