Re: [dtn-interest] Question Regarding Custodial Transfer

["Burleigh, Scott C (313B)" <[e-mail]>]

Eric, I think suggesting changes to RFC 5050 is perfectly reasonable for this Mountain View meeting.  But I don't understand why you're proposing to link integrity checking to custody transfer: although custody transfer certainly has some utility, I think there are plenty of operational scenarios where custody transfer would be neither needed nor wanted, while integrity checking might be quite important.  And vice versa, actually, as Kevin noted.  I'd decompose a little further.

Scott

From: [e-mail] [mailto:[e-mail]] On Behalf Of Eric Travis
Sent: Friday, July 13, 2012 12:31 PM
To: Stephen Farrell
Cc: [e-mail]
Subject: Re: [dtn-interest] Question Regarding Custodial Transfer

Steven,

I actually liked the draft (the reference to "something *similar to* a PIB) but bolting on an integrity check as an *optional* component to custody transfer defeats the purpose.

My integrity check problem seems easily solvable but requires a change to RFC 5050.  I offer this up as discussion fodder for the Mountain View summit:

       Since the handling of custody transfer and reporting requests
       are optional, why not remove them from the primary bundle block
       and make them extension blocks?  This allows the Primary block
       to be primarily a routing header.

(See block formats below)

Such an approach exploits a nice feature of the bundle protocol design - the decomposition of functionality into blocks. The custodial and reporting blocks would be considered fundamental blocks - required to be supported by every implementation.

Nodes not supporting Custodial or Reporting blocks can simply step over the blocks once determining their length.

This then allows:
       An optional (to the bundle source) integrity check can be added to the
       custody handling procedures.  If intermediate nodes choose not to perform
       the integrity check, they must not take custody of the bundle.

       It also supports the extension of custody handling procedures (say, experimentation with allowing
       a custodian to define the attributes/policies of a downstream custodian)

This does not solve all the issues regarding custody transfer and signaling, but it would be an incremental step forward.

Eric


==========================================================

Primary Block

  ----------------------------------------------------
  |    Version      |     Processing Flags     |
  ----------------------------------------------------
  |              Block Length                          |
  ----------------------------------------------------
  | Destination Length |      Destination    |
  ----------------------------------------------------
  |    Source Length    |       Source          |
  ----------------------------------------------------
  |       Creation Timestamp time             |
  ----------------------------------------------------
  |                 Lifetime                               |
  ----------------------------------------------------
  |            [Fragment Offset ]                    |
  ----------------------------------------------------
  | [ Total application data unit length ]    |
  ----------------------------------------------------

- All fields handled as in RFC 5050
- The bulk of potential compression benefits of omitted dictionary are
  provided by processing flag hints in Custodial and Reporting blocks.

======================================================

Custodial Block
  ---------------------------------------------------------------
  | Block Type = Custody    | Processing Flags *  |
  ---------------------------------------------------------------
  | Block Length                  |       Version *            |
  ---------------------------------------------------------------
  | Custodian Length *        | Current Custodian * |
  ---------------------------------------------------------------
  |  Integrity Length *          |  Integrity Check *     |
  ---------------------------------------------------------------
  | [Fragment Integ Len *]  | [Frag Integ Check *] |
  ----------------------------------------------------------------

* Custodian Length is a SDNV
* When the Current Custodian matches the bundle Source, a processing flag
  indication can save need to include Custodian info here.
* Non-SDNV version number allows incremental refinement of block as
  long as the changes are backward compatible
* Type of check could be signaled within processing flags, choice of:
    - 0 - something weak but relatively cheap (CRC-32)
    - 1 - strong but more resource intense (single, standardized choice)
* Integrity length of 0 indicates integrity check is not required/desired
* If bundle is a fragment, the block will contain a fragment integrity check to
  be used instead of the primary integrity check

All nodes should honor the non-zero integrity check when handling custodial transfer.
Non-custodial transfers MAY use the integrity check and refuse bundle delivery upon failure.

Custody should not be accepted until the bundle is successfully stored locally as indicated by integrity check.
Reassembled bundles should pass the primary integrity check before assuming custody.

========================================================

Reporting Block
  ------------------------------------------------------------------
  | Block Type = Reporting  |  Processing Flags *    |
  ------------------------------------------------------------------
  |                    Block Length                                    |
  ------------------------------------------------------------------
  |   [Report To Length *]     |      [  Report To * ]       |
  ------------------------------------------------------------------

* Processing Flags is an SDNV
* If processing flags indicate that "Report To" is Source,
  then Report To Length and Report To fields need not be included
* If processing flags indicate that "Report To" is Current Custodian,
   then Report To Length and Report To fields need not be included

===========================================================
On Fri, Jul 13, 2012 at 6:14 AM, Stephen Farrell <[e-mail]<mailto:[e-mail]>> 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
> _______________________________________________
> dtn-interest mailing list
> [e-mail]<mailto:[e-mail]>
> https://www.irtf.org/mailman/listinfo/dtn-interest
>
>