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

ahennes1@math.umd.edu Wed, 05 September 2012 20:56 UTC

Return-Path: <ahennes1@math.umd.edu>
X-Original-To: dtn-security@ietfa.amsl.com
Delivered-To: dtn-security@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8CEE921F86D4 for <dtn-security@ietfa.amsl.com>; Wed, 5 Sep 2012 13:56:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.185
X-Spam-Level:
X-Spam-Status: No, score=-4.185 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OShtIgQ2dJTX for <dtn-security@ietfa.amsl.com>; Wed, 5 Sep 2012 13:56:43 -0700 (PDT)
Received: from mailfilter.ece.umd.edu (mailfilter.ece.umd.edu [129.2.90.4]) by ietfa.amsl.com (Postfix) with ESMTP id 319FA21F86B7 for <dtn-security@irtf.org>; Wed, 5 Sep 2012 13:56:43 -0700 (PDT)
X-ASG-Debug-ID: 1346878601-04739d1032a50d0001-NoPDhg
Received: from svr4.math.umd.edu ([129.2.56.14]) by mailfilter.ece.umd.edu with ESMTP id iSe29kh3OiFGz608; Wed, 05 Sep 2012 16:56:41 -0400 (EDT)
X-Barracuda-Envelope-From: ahennes1@math.umd.edu
X-Barracuda-Apparent-Source-IP: 129.2.56.14
Received: by svr4.math.umd.edu (Postfix, from userid 48) id 702866FC83; Wed, 5 Sep 2012 16:56:41 -0400 (EDT)
Received: from 65.127.220.136 by webmail.math.umd.edu with HTTP; Wed, 5 Sep 2012 16:56:41 -0400
Message-ID: <6af37e4869b76826d4d2108e3eef82b3.squirrel@webmail.math.umd.edu>
In-Reply-To: <A5BEAD028815CB40A32A5669CF737C3B0D72DE@ap-embx-sp20.RES.AD.JPL>
References: <2665b4bca07d1e0d3d9de88844cc02e9.squirrel@webmail.math.umd.edu> <20120904172458.1767559740@smtp.mail.me.com> <A5BEAD028815CB40A32A5669CF737C3B0D72DE@ap-embx-sp20.RES.AD.JPL>
Date: Wed, 5 Sep 2012 16:56:41 -0400
From: ahennes1@math.umd.edu
X-ASG-Orig-Subj: RE: [dtn-security] Implementing Security Destinations in DTN2
To: "Burleigh, Scott C (313B)" <scott.c.burleigh@jpl.nasa.gov>
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[129.2.56.14]
X-Barracuda-Start-Time: 1346878601
X-Barracuda-URL: http://mailfilter.ece.umd.edu:8000/cgi-mod/mark.cgi
X-Virus-Scanned: by bsmtpd at ece.umd.edu
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 3.2.2.107710 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: "dtn-security@irtf.org" <dtn-security@irtf.org>
Subject: Re: [dtn-security] Implementing Security Destinations in DTN2
X-BeenThere: dtn-security@irtf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "The Delay-Tolerant Networking Research Group \(DTNRG\) - Security." <dtn-security.irtf.org>
List-Unsubscribe: <https://www.irtf.org/mailman/options/dtn-security>, <mailto:dtn-security-request@irtf.org?subject=unsubscribe>
List-Archive: <http://www.irtf.org/mail-archive/web/dtn-security>
List-Post: <mailto:dtn-security@irtf.org>
List-Help: <mailto:dtn-security-request@irtf.org?subject=help>
List-Subscribe: <https://www.irtf.org/mailman/listinfo/dtn-security>, <mailto:dtn-security-request@irtf.org?subject=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
somewhere.


Thanks,
Angela

> 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: dtn-security-bounces@irtf.org [mailto:dtn-security-bounces@irtf.org]
> On Behalf Of Peter Lovell
> Sent: Tuesday, September 04, 2012 10:25 AM
> To: ahennes1@math.umd.edu; dtn-security@irtf.org
> 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
>>value.
>>
>
>
> 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
> dtn-security@irtf.org
> https://www.irtf.org/mailman/listinfo/dtn-security
>