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

["Ivancic, William D. (GRC-RHN0)" <[e-mail]>]

IMHO, protecting the content is not the responsibility of the Bundle Agent
but rather the user or application.  Think of email.  Email is encrypted by
the user, not the IP layer.

On the other hand, I would like to authenticate the source of the bundle,
because I am not going to let just anyone use my resources (battery,
storage, bandwidth, etc...).  IMHO, this is the major issue in deploying
Store, Carry, and Forwarding distributed applications across domains owned
and operated by various entities.  It is not an issue if you own the entire
network (Military, US Space).  But, if you want to move across domains, the
agreement to share some amount of resource is of major importance.

- Will


On 12/7/12 1:32 AM, "[e-mail]" <[e-mail]> wrote:

> Good to see the BP's lack of recognition of end-to-end considderation being
> addressed - even if it takes a higher layer to do it.
> 
> "functionality that applies only in pairwise fashion between two neighboring
> nodes in the network belongs at that layer too"
> 
> Question: with adding a higher layer, why bother with security in the bundle
> protocol? Implement end-to-end payload encryption in DTCP, you're done. That
> would greatly simplify bundling implementations across the network.
> 
> Lloyd Wood
> http://sat-net.com/L.Wood/dtn
> 
> 
> ________________________________________
> From: [e-mail] [[e-mail]] On Behalf
> Of Burleigh, Scott C (313B) [[e-mail]]
> Sent: 07 December 2012 01:50
> To: John Zinky; [e-mail]
> Subject: Re: [dtn-interest] DTN architecture issues for handling Huge Content
> Objects
> 
> We may diverge a little bit on this, John.  I am a big fan of the layer-free
> extension of BP (and, to a lesser extent, LTP) that we can do in DTN, but I
> think there's still a place for layering.  In my earlier email I suggested
> that anything that has to do with operating the BP network itself belongs in
> extension blocks rather than in additional layers -- but that there are still
> application protocols that shouldn't be made part of BP, so they're at a
> different layer, and there are still underlying transport protocols that
> shouldn't be made part of BP, so they're also at a different layer.  The new
> application services we're looking at in DTPC seem to me to belong at an
> application layer above BP, not within BP itself.
> 
> The analogy with TCP/IP is actually pretty close, I believe.  BP's functions
> need to be invoked at every forwarding agent along the end-to-end path, just
> like the IP functions.  But DTPC's functions are end-to-end only; they need to
> be invoked at the source and destination and nowhere else, just like the
> functions of TCP.
> 
> That is, there's a sort of topological isomorphism that I find myself using in
> thinking about when it makes sense to layer and when it doesn't.
> 
> Suppose we've got a chain of four nodes, A->B->C->D and we're sending a bundle
> from A to D.  Bundle protocol itself needs to operate at all four nodes:
> receiving the bundle, storing it, computing the route to forward it on, and
> forwarding it to the next node along that route.  We also want
> operator-specified class of service to be honored at every forwarding point,
> so something like ECOS belongs inside BP as an extension.  The metadata that
> describes the bundle might be consulted in route computation, so it too
> operates at every node and therefore belongs inside BP as an extension.  And
> so on.
> 
> But the link between A and B is a space link, reinforced by LTP, while the
> B->C link is DCCP/UDP and the C->D link is TCP.  Since LTP runs only between
> nodes A and B it shouldn't be a BP extension; it belongs at the underlying
> convergence layer.  And other functionality that applies only in pairwise
> fashion between two neighboring nodes in the network belongs at that layer
> too, such as retransmission timeout interval computation that needs to be done
> in entirely different ways on different segments of the end-to-end path.
> 
> The functions that are included in DTPC are things like end-to-end
> acknowledgment, end-to-end retransmission, resequencing received data into
> transmission order, that can only be done at the source and the destination.
> They're not functions that need to operate at all four nodes, so they don't
> belong inside BP as extensions.  These are functions that operate on a common
> topology, but it's not the topology that functions like route computation and
> class of service operate at -- it's the A<->D topology, not the A->B->C->D
> topology.  They belong at a different layer.
> 
> Scott
> 
> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On
> Behalf Of John Zinky
> Sent: Thursday, December 06, 2012 2:30 PM
> To: [e-mail]
> Subject: Re: [dtn-interest] DTN architecture issues for handling Huge Content
> Objects
> 
> Scott,
> I hope that your new application services will put their headers as extension
> blocks and not layer them inside the bundle payload. I was really encouraged
> by your previous posts about non-layered protocols!
> 
> On Dec 6, 2012, at 3:46 PM, "Burleigh, Scott C (313B)"
> <[e-mail]> wrote:
> 
>> It would be a standardized application service layer -- similar to a
>> transport layer -- running immediately above BP.
> 
> On Dec 5, 2012, at 1:53 PM, "Burleigh, Scott C (313B)"
> <[e-mail]> wrote:
> 
>> Which it already has, to some extent, because additional features such as QoS
>> are added in extension blocks (e.g., BSP and Extended Class of Service)
>> rather than in additional layers.
> 
>> The only DTN extension blocks that can be said to nest are the BSP
>> extensions, and I there's a strong argument for removing that nesting as
>> well.
> _______________________________________________
> dtn-interest mailing list
> [e-mail]
> https://www.irtf.org/mailman/listinfo/dtn-interest
> _______________________________________________
> dtn-interest mailing list
> [e-mail]
> https://www.irtf.org/mailman/listinfo/dtn-interest
> _______________________________________________
> dtn-interest mailing list
> [e-mail]
> https://www.irtf.org/mailman/listinfo/dtn-interest


******************************
William D. Ivancic
Phone [phone]
Fax [phone]
Networking Lab 216-433-2620
Mobile [phone]
http://roland.grc.nasa.gov/~ivancic