Re: [dtn-security] Implementing Security Destinations in DTN2

Peter Lovell <> Tue, 04 September 2012 17:25 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 20DC621E804E for <>; Tue, 4 Sep 2012 10:25:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -3.599
X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id COlelToGRFYK for <>; Tue, 4 Sep 2012 10:25:02 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 2FAD211E809A for <>; Tue, 4 Sep 2012 10:25:01 -0700 (PDT)
MIME-version: 1.0
Content-transfer-encoding: 7BIT
Content-type: text/plain; CHARSET=US-ASCII
Received: from [] ( []) by (Oracle Communications Messaging Server 7u4-23.01( 64bit (built Aug 10 2011)) with ESMTPSA id <> for; Tue, 04 Sep 2012 17:25:00 +0000 (GMT)
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.7.7855, 1.0.431, 0.0.0000 definitions=2012-09-04_06:2012-09-04, 2012-09-04, 1970-01-01 signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 suspectscore=0 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=6.0.2-1203120001 definitions=main-1209040169
From: Peter Lovell <>
Date: Tue, 04 Sep 2012 13:24:58 -0400
Message-id: <>
In-reply-to: <>
References: <>
X-Mailer: CTM PowerMail version 6.1.3 build 4650 English (intel) <>
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: Tue, 04 Sep 2012 17:25:03 -0000

>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.