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

Ian Glennon <> Mon, 03 September 2012 16:54 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 69A5421F8419 for <>; Mon, 3 Sep 2012 09:54:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -3.598
X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id bAIG-XT5Q9UX for <>; Mon, 3 Sep 2012 09:54:58 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 4712D21F866D for <>; Mon, 3 Sep 2012 09:54:58 -0700 (PDT)
Received: by lbbgg13 with SMTP id gg13so3229007lbb.13 for <>; Mon, 03 Sep 2012 09:54:57 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=AHzJXvlstqezB/+F/iC9a8r+yJDTeB42KJhjnPeX5ao=; b=jZFMXYFLXQN4j4pauQvfSxvmNrPiRFakz+BIEkHAe7g/ybz2COOImcMy/jd2pofoI7 KlHzm/V38/l1pnhCxXovxDAOXEVD34lXSImBhSyJf4EnEgWsHb+3EmW5cLkC0kmG9WbU Vijdjmw0SUPjPKYd6/vcLVlB1iX2525boY4xn4FphFux4gRss7Q2MFQS9jWeIRGL3Qp9 ufDBU0hoBQCL8NcLpfSx4Gx8SES6g9jbnTqDLCmPEffRhKDliVlVwBOFHSwsVht8zTkq A/fov04POOMsfVu7FLfLiWrFx0Chz5RIVaVMkW5NUv35xQ8TjyaEMvMRF7KCtH4zYicC NkZA==
MIME-Version: 1.0
Received: by with SMTP id td9mr14367962lab.42.1346691297102; Mon, 03 Sep 2012 09:54:57 -0700 (PDT)
Received: by with HTTP; Mon, 3 Sep 2012 09:54:56 -0700 (PDT)
In-Reply-To: <>
References: <>
Date: Mon, 3 Sep 2012 17:54:56 +0100
Message-ID: <>
From: Ian Glennon <>
Content-Type: multipart/alternative; boundary=e89a8f23458962cc5b04c8cf006b
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: Mon, 03 Sep 2012 16:54:59 -0000

If the security destination did not handle the bundle would the bundle
payload not still be encrypted, or sigs needing verification?

If the security dest is defined then it should be preferred simply because
the contents have not yet been handled (data not decrypted, sigs not
verified, etc) and the payload would be useless or untrusted, but would the
bundle dest not forward it on to the security dest anyway so that the
operations can be completed?

The final bundle can then be sent on to the bundle destination, assuming of
course that it is different to the security destination.



On 3 September 2012 14:38, <> wrote:

> 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
> value.
> Any comments/feedback would be appreciated.
> thanks,
> Angela
> _______________________________________________
> dtn-security mailing list