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

[Eric Travis <[e-mail]>]

Will,

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?)

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.

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.

Eric


On 12/7/12, Ivancic, William D. (GRC-RHN0) <[e-mail]>
wrote:
> 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 Fri, Dec 7, 2012 at 9:53 AM, Ivancic, William D. (GRC-RHN0) <
[e-mail]> wrote:

> 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
>
>
> _______________________________________________
> dtn-interest mailing list
> [e-mail]
> https://www.irtf.org/mailman/listinfo/dtn-interest
>