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 >
- [dtn-security] Implementing Security Destinations… ahennes1
- Re: [dtn-security] Implementing Security Destinat… Ian Glennon
- Re: [dtn-security] Implementing Security Destinat… Peter Lovell
- Re: [dtn-security] Implementing Security Destinat… Burleigh, Scott C (313B)
- Re: [dtn-security] Implementing Security Destinat… ahennes1
- [dtn-security] Re(2): Implementing Security Desti… Peter Lovell
- [dtn-security] Re(2): Implementing Security Desti… Peter Lovell
- [dtn-security] FW: Re(19): Implementing Security … Burleigh, Scott C (313B)
- Re: [dtn-security] FW: Re(19): Implementing Secur… Stephen Farrell
- Re: [dtn-security] FW: Re(19): Implementing Secur… Burleigh, Scott C (313B)
- Re: [dtn-security] FW: Re(19): Implementing Secur… Stephen Farrell
- Re: [dtn-security] FW: Re(19): Implementing Secur… Burleigh, Scott C (313B)
- Re: [dtn-security] FW: Re(19): Implementing Secur… Eddy, Wesley M. (GRC-MS00)[MTI SYSTEMS, INC.]
- Re: [dtn-security] FW: Re(19): Implementing Secur… Eddy, Wesley M. (GRC-MS00)[MTI SYSTEMS, INC.]
- Re: [dtn-security] FW: Re(19): Implementing Secur… Birrane, Edward J.
- Re: [dtn-security] FW: Re(19): Implementing Secur… Pitts, Robert L. (MSFC-EO60)[HOSC SERVICES CONTRACT]