Re: [dtn-security] Implementing Security Destinations in DTN2 Wed, 05 September 2012 20:56 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 8CEE921F86D4 for <>; Wed, 5 Sep 2012 13:56:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.185
X-Spam-Status: No, score=-4.185 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, RCVD_IN_DNSWL_MED=-4]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id OShtIgQ2dJTX for <>; Wed, 5 Sep 2012 13:56:43 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 319FA21F86B7 for <>; Wed, 5 Sep 2012 13:56:43 -0700 (PDT)
X-ASG-Debug-ID: 1346878601-04739d1032a50d0001-NoPDhg
Received: from ([]) by with ESMTP id iSe29kh3OiFGz608; Wed, 05 Sep 2012 16:56:41 -0400 (EDT)
Received: by (Postfix, from userid 48) id 702866FC83; Wed, 5 Sep 2012 16:56:41 -0400 (EDT)
Received: from by with HTTP; Wed, 5 Sep 2012 16:56:41 -0400
Message-ID: <>
In-Reply-To: <A5BEAD028815CB40A32A5669CF737C3B0D72DE@ap-embx-sp20.RES.AD.JPL>
References: <> <> <A5BEAD028815CB40A32A5669CF737C3B0D72DE@ap-embx-sp20.RES.AD.JPL>
Date: Wed, 5 Sep 2012 16:56:41 -0400
X-ASG-Orig-Subj: RE: [dtn-security] Implementing Security Destinations in DTN2
To: "Burleigh, Scott C (313B)" <>
User-Agent: SquirrelMail/1.4.20
MIME-Version: 1.0
Content-Type: text/plain;charset=iso-8859-1
Content-Transfer-Encoding: 8bit
X-Priority: 3 (Normal)
Importance: Normal
X-Barracuda-Connect: UNKNOWN[]
X-Barracuda-Start-Time: 1346878601
X-Virus-Scanned: by bsmtpd at
X-Barracuda-Spam-Score: 0.00
X-Barracuda-Spam-Status: No, SCORE=0.00 using per-user scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=7.0 KILL_LEVEL=1000.0 tests=BSF_SC0_MISMATCH_TO, NO_REAL_NAME
X-Barracuda-Spam-Report: Code version 3.2, rules version Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.00 NO_REAL_NAME From: does not include a real name 0.00 BSF_SC0_MISMATCH_TO Envelope rcpt doesn't match header
Cc: "" <>
Subject: Re: [dtn-security] Implementing Security Destinations in DTN2
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "The Delay-Tolerant Networking Research Group \(DTNRG\) - Security." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 05 Sep 2012 20:56:44 -0000

I think this push/pop idea makes the most sense of anything we've talked
about. It seems like it would require some modification to the spec,
however, and maybe a flag to set when the bundle-dest is being stored


> Actually ION exercises something like this push/pop mechanism, internally,
> in route computation, and I suspect other implementations do it as well:
> in the course of computing the route to the final destination, the
> forwarder may select an interim endpoint to forward the bundle to and may
> then re-enter route computation in order to figure out how to route the
> bundle to that interim endpoint.  So long as all the routers along the
> path follow the same strategy, there's no need to record the interim
> endpoint in the bundle; it's an internal procedure.
> None of the ION forwarders currently pay attention to security
> destinations when computing routes, so security destinations are never
> chosen as interim endpoints, but that modification seems plausible.  You'd
> want to be sure that the block citing a given security destination was
> always removed as soon as the bundle arrives at that destination, though,
> and we would want some sort of extension block ordering convention (or
> whatever) for nesting security destinations in a standardized way.
> Scott
> -----Original Message-----
> From: []
> On Behalf Of Peter Lovell
> Sent: Tuesday, September 04, 2012 10:25 AM
> To:;
> Subject: Re: [dtn-security] Implementing Security Destinations in DTN2
>>We're working on adding support for defining security
>>source/destinations in DTN2 (which could be different than the bundle
>> src/dest).
>>This raised the issue of whether or not we should route the bundle to
>>the security destination (if defined), rather than the bundle
>>destination. If we don't route the bundle through the security dest,
>>then it may be discarded at the bundle dest if it did not pass through
>>the security dest in transit.
>>There are also some practical issues that are raised. There can be a
>>security destination for PIB/PCB, and a (possibly different) security
>>dest for ESB, and we'd have to decide which one to choose.
>>Also, the routers in DTN2 access the bundle destination themselves, i.e.
>>bundle->dest(). They would each have to be corrected to use some other
> Hi Angela,
> a problem indeed!  We did discuss this during development of BSP ...
>>Specification of a security-destination other than the bundle-
>>destination creates a routing requirement that the bundle somehow be
>>directed to the security-destination node on its way to the final
>>destination.  This requirement is presently private to the ciphersuite,
>>since routing nodes are not required to implement security processing.
> At one point I suggested that addition of PCB should adjust the
> bundle-dest to be the new security-dest, saving the previous bundle-dest
> for later restoration. This would certainly cause the bundle to be
> properly processed with regard to decryption. Although there might be
> other side-effects, no-one proposed any, however the plan was not adopted.
> The "nesting" characteristic of PCBs would mean that nodes were visited in
> correct order in the case of super-encryption.
> I am not sure how this might interact with ESBs. I think that adopting the
> same approach (use security-dest as bundle-dest, save bundle-dest for
> later restoration) should work and produce a correct result. However I
> will admit that I haven't pondered the ESB/PCB interaction very much. I
> think it should "just work".
> There might be other ways to adjust routing to ensure that the bundle
> visits the appropriate nodes. But those would require extensive changes to
> both BP and routing schemes -- neither of which seem likely. So the
> push/pop idea for bundle-dest seems to be the only realistic solution. Of
> course, there needs to be an EID-ref maintained in an EID-list somewhere
> so that dictionary compression/adjustment doesn't break things. That would
> be something like the plan for the list in the ESB.
> Cheers.....Peter
> _______________________________________________
> dtn-security mailing list