Re: [dtn-interest] Question Regarding Custodial Transfer

[<[e-mail]>]

http://tools.ietf.org/html/draft-irtf-dtnrg-bundle-checksum 
was adopted as a workgroup draft in September 2007.

(The workgroup did not like the earlier proposed approach in 
http://tools.ietf.org/html/draft-eddy-dtnrg-checksum-00
that we had presented at the July 2007 IETF.)

Comments from the workgroup after being taken up as a workgroup
draft were minimal, as the group focused on new and exciting-to-it
security matters. The workgroup did not progress this draft, much 
as it did not progress the TCP convergence layer, ttl fixes, etc.
Since the draft wasn't getting attention, we wrote our
'A Bundle of Problems' paper, which covered that ground and
more.

We kept the draft alive until May 2011, then gave up.

We spent over four years on this, while demonstrating some
of the problems we explain in experiments on the ground and in space.
(Oh, videos on that at http://sat-net.com/L.Wood/video )

No further work on this effort is planned; fixing the bundle protocol
is not my problem.

(Stephen: your IMO is trolling, not leadership - imo.
 It would be a little late now for constructive edits, though.)

Lloyd Wood
http://sat-net.com/L.Wood/dtn


On 13 Jul 2012, at 20:14, Stephen Farrell wrote:

> On 07/13/2012 05:52 AM, Eric Travis wrote:
>> Dan,
>> 
>> Thanks!
>> 
>> While BSP would be a non-starter (key management issues), including
>> something *similar to* a PIB (payload integrity block) wouldn't be
>> terrible; My hangup on such approach is that custody transfer can't be
>> predicated on the new custodian implementing (and thus validating) the
>> optional integrity check block. It would be better than nothing, until
>> it wasn't.
> 
> There was a draft for that [1] but its not progressed and I don't
> know of any implementations. The basic idea is sound, though IMO
> without all the argumentative bits of the draft it'd much more
> likely to be implemented (and a lot shorter;-)
> 
> S.
> 
> [1] http://tools.ietf.org/html/draft-irtf-dtnrg-bundle-checksum
> 
>> 
>> Oh well...
>> 
>> 
>> Will,
>> 
>> For my scenario, time-sync would be a non-issue.
>> 
>> The lifespan of the bundles would be to some ridiculous (14-28 days?)
>> value as they need to be considered valid until the problem is
>> resolved.  If the potential clock drift isn't insignificant compared
>> to such lifespans then the system is utterly doomed.
>> 
>> Eric