Re: [dtn-interest] DTN architecture issues for handling Huge Content Objects

[Eric Travis <[e-mail]>]

Will,

I think you might have misinterpreted my query as "why" rather than the
intended "how"...



> * If you could clarify - where do you believe the responsibility (and
> more importantly, the mechanisms) reside to authenticate the source of the
> bundle? (And by "source", do you mean what is in the bundle header or the
> node that is currently attempting to hand-off the bundle to you?)
>
> *
>
> What is in the Bundle Header, What entity sourced the data?  That is why
> something like BBNs idea of adding FEC in the middle will likely not work
> in resource protected system.  Multi-hop  store and forward systems are
> different than connected systems.  One should have the capability to
> protect your resources.
>


My intent was not to question the need/value of protecting the resources, I
was merely wondering *how* you wanted to achieve that in a bundle-protocol
based DTN.  I'm not seeing how to authenticate the bundle source in a
timely manner within environments that do necessarily provide timely
communications.

The "timely" is important because you will be storing the bundle at least
as long as it takes to authenticate the bundle source...

My understanding was/is that the intent is to the authenticate at every
intermediate node, I ruled out something involving "pre-shared secrets",
key-management systems or certificate authorities - hence my curiosity in
how to do this.  It's a really cool problem.

If the intent was to accept bundles only from trusted/authenticated
neighbors then I believe I can understand the intended approach.

*
> *
>>
>> * The protection of the local *resources* supporting bundle operation is
>> *not* the responsibility of the bundle protocol.  Replace "bundle protocol"
>> with another comparable DTN protocol and it still applies.*
>>
> *
> *

It is the responsibility of the policy engine that resides that must make a
> determination on what resources are allocated and how.  Failure to do so
> opens up the system for very simple and effective DOS attacks.  I simply
> deplete your resources.
>
>
Again, no disagreement in principle, but *that* policy engine is *not*
something to be made integral to the bundle protocol - it is something that
is exercised *prior* to submitting something to the bundle protocol
handling - or even better, prior to committing resources to receiving the
bundle.

This seems like functionality that is best placed in the CLA...

*

*
>
> * The issue of resource allocation is a separate area (and to me), far
> more complex one.  Peering agreements between mythical bundle operators
> would likely be interesting...  Even within a single operational network,
> the service policies are likely to vary on a node-by-node basis - the well
> connected bundle nodes having a differing demands on local resources than
> the more sparsely connected nodes.*
>
*
*

Yes indeed. But not really a separate issue.  Failure to recognize and
> address this up front is the same old story.  Adding security as an
> afterthought tends to no work very well.  Lots of things break.
>

OK - I can see your reasoning behind the coupling and you are preaching to
the faithful regarding security.  But the role that the bundle protocol
should play in securing the system is limited to ensuring the integrity of
the bundles.  Securing the resources of the nodes hosting the bundle
protocol belongs to some other component of the system.


Think of this as a firewall.  Storage systems on wireless platforms are a
> much different beast than a router in a connected network.  The latter has
> short-term storage for buffering.  The former can store information for a
> long long time and also has to receive and transmit, both which use power.
>

I see the reasoning to be absolutely consistent with the deployment of a
firewall.  A firewall exercises policies prior to the protocol processing.