Re: [dtn-interest] Question Regarding Custodial Transfer
Eric Travis <eric.dot.travis@gmail.com> Fri, 13 July 2012 19:30 UTC
Return-Path: <eric.dot.travis@gmail.com>
X-Original-To: dtn-interest@ietfa.amsl.com
Delivered-To: dtn-interest@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B98A321F8838 for <dtn-interest@ietfa.amsl.com>; Fri, 13 Jul 2012 12:30:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.599
X-Spam-Level:
X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Muur5AAFkzAV for <dtn-interest@ietfa.amsl.com>; Fri, 13 Jul 2012 12:30:44 -0700 (PDT)
Received: from mail-wg0-f50.google.com (mail-wg0-f50.google.com [74.125.82.50]) by ietfa.amsl.com (Postfix) with ESMTP id 069D321F8833 for <dtn-interest@irtf.org>; Fri, 13 Jul 2012 12:30:43 -0700 (PDT)
Received: by wgbds11 with SMTP id ds11so1243893wgb.19 for <dtn-interest@irtf.org>; Fri, 13 Jul 2012 12:31:12 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=EILu0xrI6df2dsKhjAF+E8ABvg2morP8AIEJD8kW7RM=; b=p8KH92VtfZGmTb3y+vh9jDJGUw9vhc0t8xFf2+f35tCFxZFJKSwKj8/T+zqupYyxf3 da70HF6rQqdQAVMmx7esNEZAfJRmm+nklCHWbuXMhO0CTJRBYQny5STEnuUoCZJJq/vb uiPByVSia6TPnJtGf5OwSjK9XB4dNQYDG3ejKTpToyz/u7ZMOsyLXtKRBdbHLqqBKJ64 kdVzD83co1iX4T4pQPpNFR+NbIVEk/rpj20LQo8ZuRfT+k/Pnrs46UJR0fA3cdOYiHJR dr3o1ECRtC2Qr2RGlVe4WjWRt33KkX6I3Kw2FAfGRFpUTsqQjy8geS2AvYX8P43GlDNA zzpQ==
MIME-Version: 1.0
Received: by 10.180.109.195 with SMTP id hu3mr96951wib.8.1342207872101; Fri, 13 Jul 2012 12:31:12 -0700 (PDT)
Received: by 10.194.38.6 with HTTP; Fri, 13 Jul 2012 12:31:11 -0700 (PDT)
In-Reply-To: <4FFFF4EF.70107@cs.tcd.ie>
References: <CAKovV0yaS7cjJ+JdEKs3SNpaX5FCp5-Oiss0aFpWG=R0BaYS1g@mail.gmail.com> <4FFEA38E.3010804@bbn.com> <42CAC1E3-7480-4C39-81C5-1E5504FEC8C5@nasa.gov> <CAKovV0zzvB8NR1TKR96GBvrLWvJBzed8nEvoz_mBaigD-P==2A@mail.gmail.com> <4FFFF4EF.70107@cs.tcd.ie>
Date: Fri, 13 Jul 2012 15:31:11 -0400
Message-ID: <CAKovV0wgqHOaA1EZ_d6s3wh-LwWdqZA9NTKEMn3mBy6Tw89bZA@mail.gmail.com>
From: Eric Travis <eric.dot.travis@gmail.com>
To: Stephen Farrell <stephen.farrell@cs.tcd.ie>
Content-Type: multipart/alternative; boundary="e89a8f3ba7fb6e6bc604c4bb1f86"
Cc: "dtn-interest@irtf.org" <dtn-interest@irtf.org>
Subject: Re: [dtn-interest] Question Regarding Custodial Transfer
X-BeenThere: dtn-interest@irtf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "The Delay-Tolerant Networking Research Group \(DTNRG\) - Announce." <dtn-interest.irtf.org>
List-Unsubscribe: <https://www.irtf.org/mailman/options/dtn-interest>, <mailto:dtn-interest-request@irtf.org?subject=unsubscribe>
List-Archive: <http://www.irtf.org/mail-archive/web/dtn-interest>
List-Post: <mailto:dtn-interest@irtf.org>
List-Help: <mailto:dtn-interest-request@irtf.org?subject=help>
List-Subscribe: <https://www.irtf.org/mailman/listinfo/dtn-interest>, <mailto:dtn-interest-request@irtf.org?subject=subscribe>
X-List-Received-Date: Fri, 13 Jul 2012 19:30:48 -0000
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 <stephen.farrell@cs.tcd.ie>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 > > dtn-interest@irtf.org > > https://www.irtf.org/mailman/listinfo/dtn-interest > > > > > >
- [dtn-interest] Question Regarding Custodial Trans… Eric Travis
- Re: [dtn-interest] Question Regarding Custodial T… Daniel Ellard
- Re: [dtn-interest] Question Regarding Custodial T… Ivancic, William D. (GRC-RHN0)
- Re: [dtn-interest] Question Regarding Custodial T… Eric Travis
- Re: [dtn-interest] Question Regarding Custodial T… Stephen Farrell
- Re: [dtn-interest] Question Regarding Custodial T… Vint Cerf
- Re: [dtn-interest] Question Regarding Custodial T… l.wood
- Re: [dtn-interest] Question Regarding Custodial T… l.wood
- Re: [dtn-interest] Question Regarding Custodial T… Stephen Farrell
- Re: [dtn-interest] Question Regarding Custodial T… l.wood
- Re: [dtn-interest] Question Regarding Custodial T… Fall, Kevin
- Re: [dtn-interest] Question Regarding Custodial T… Eric Travis
- Re: [dtn-interest] Question Regarding Custodial T… Eric Travis
- Re: [dtn-interest] Question Regarding Custodial T… Burleigh, Scott C (313B)
- Re: [dtn-interest] Question Regarding Custodial T… Eric Travis
- Re: [dtn-interest] Question Regarding Custodial T… Burleigh, Scott C (313B)
- Re: [dtn-interest] Question Regarding Custodial T… l.wood
- Re: [dtn-interest] Question Regarding Custodial T… l.wood