Re: [dtn-security] dtn-security Digest, Vol 9, Issue 9
"Ivancic, William D. (GRC-RHN0)" <william.d.ivancic@nasa.gov> Mon, 28 January 2013 19:46 UTC
Return-Path: <william.d.ivancic@nasa.gov>
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 B7A7621F8786 for <dtn-security@ietfa.amsl.com>;
Mon, 28 Jan 2013 11:46:01 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.499
X-Spam-Level:
X-Spam-Status: No, score=-6.499 tagged_above=-999 required=5 tests=[AWL=0.100,
BAYES_00=-2.599, 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 rxF+Cpv4g0rm for
<dtn-security@ietfa.amsl.com>; Mon, 28 Jan 2013 11:45:58 -0800 (PST)
Received: from ndmsnpf03.ndc.nasa.gov (ndmsnpf03.ndc.nasa.gov [198.117.0.123])
by ietfa.amsl.com (Postfix) with ESMTP id 9523A21F87B9 for
<dtn-security@irtf.org>; Mon, 28 Jan 2013 11:45:57 -0800 (PST)
Received: from ndjsppt02.ndc.nasa.gov (ndjsppt02.ndc.nasa.gov [198.117.1.101])
by ndmsnpf03.ndc.nasa.gov (Postfix) with ESMTP id BABD42D8328;
Mon, 28 Jan 2013 13:45:56 -0600 (CST)
Received: from ndjshub01.ndc.nasa.gov (ndjshub01-pub.ndc.nasa.gov
[198.117.1.160]) by ndjsppt02.ndc.nasa.gov (8.14.5/8.14.5) with ESMTP id
r0SJjuP9011360; Mon, 28 Jan 2013 13:45:56 -0600
Received: from NDJSSCC07.ndc.nasa.gov ([198.117.4.178]) by
ndjshub01.ndc.nasa.gov ([198.117.1.160]) with mapi;
Mon, 28 Jan 2013 13:45:56 -0600
From: "Ivancic, William D. (GRC-RHN0)" <william.d.ivancic@nasa.gov>
To: Angela Hennessy <ahennes1@math.umd.edu>
Date: Mon, 28 Jan 2013 13:46:24 -0600
Thread-Topic: [dtn-security] dtn-security Digest, Vol 9, Issue 9
Thread-Index: Ac39jUOImD8eLYagSvSLHKV0Lzi2mQAAuPAS
Message-ID: <CD2C3FC0.FA47%william.d.ivancic@nasa.gov>
In-Reply-To: <CACbuvat855dSz6s5KFO7tU2Oneyq4owBYOUTd7kHmOLgH2Y38Q@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-Entourage/13.11.0.110726
acceptlanguage: en-US
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.9.8327, 1.0.431,
0.0.0000 definitions=2013-01-28_03:2013-01-28, 2013-01-28,
1970-01-01 signatures=0
Cc: "dtn-security@irtf.org" <dtn-security@irtf.org>
Subject: Re: [dtn-security] dtn-security Digest, Vol 9, Issue 9
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: Mon, 28 Jan 2013 19:46:02 -0000
There must be hundreds (if not thousands) of combinations and permutations. Is there a publically available document that lists what was tested? And, perhaps just as important, what was not? Will ****************************** William D. Ivancic Phone 216-433-3494 Fax 216-433-8705 Networking Lab 216-433-2620 Mobile 440-503-4892 http://roland.grc.nasa.gov/~ivancic > From: Angela Hennessy <ahennes1@math.umd.edu> > Date: Mon, 28 Jan 2013 13:25:39 -0600 > To: "Ivancic, William D. (GRC-RHN0)" <william.d.ivancic@nasa.gov> > Cc: "dtn-security@irtf.org" <dtn-security@irtf.org> > Subject: Re: [dtn-security] dtn-security Digest, Vol 9, Issue 9 > > Hi Will, > > We had done some work on interoperability testing between DTN2 and > IBR-DTN, which turned up some places where the BSP spec was somewhat > vague (and as a result was implemented differently in DTN2 and > IBR-DTN). I believe we addressed most of these in the proposed errata > list for BSP. We haven't done any interoperability testing with the > ION implementation, since this uses different cryptographic algorithms > for the PIB and PCB ciphersuites. > > thanks, > Angela > > On Mon, Jan 28, 2013 at 10:46 AM, Ivancic, William D. (GRC-RHN0) > <william.d.ivancic@nasa.gov> wrote: >> Angela, >> >> I believe your group was performing interoperability testing between various >> DTN implementations. If so, Can you summarize the results and perhaps point >> to the test plan or any reports. >> >> IMHO, as is, the BSP would be very difficult to achieve full >> interoperability over all option and parameters due to the complexity. >> >> Simplifying would be a good thing, but perhaps premature if the overall >> protocol is to be revised. In other words, is this still research or will >> there be a move to operational deployment (a minimum of 1000s of agents). >> >> Will >> >> ****************************** >> William D. Ivancic >> Phone 216-433-3494 >> Fax 216-433-8705 >> Networking Lab 216-433-2620 >> Mobile 440-503-4892 >> http://roland.grc.nasa.gov/~ivancic >> >> >> >>> From: Angela Hennessy <ahennes1@math.umd.edu> >>> Date: Sun, 27 Jan 2013 15:42:18 -0600 >>> To: "dtn-security@irtf.org" <dtn-security@irtf.org> >>> Subject: Re: [dtn-security] dtn-security Digest, Vol 9, Issue 9 >>> >>> Hi Ed, >>> >>> I definitely agree that things can get pretty complicated dealing with >>> the security src/dest, and we've run into some issues when >>> implementing them. I think the idea of using bundle-in-bundle >>> encapsulation is an interesting alternative, and I'll be interested to >>> read all the details. >>> >>> >>> thanks, >>> Angela >>> >>> On Sat, Jan 26, 2013 at 9:09 PM, <dtn-security-request@irtf.org> wrote: >>>> If you have received this digest without all the individual message >>>> attachments you will need to update your digest options in your list >>>> subscription. To do so, go to >>>> >>>> https://www.irtf.org/mailman/listinfo/dtn-security >>>> >>>> Click the 'Unsubscribe or edit options' button, log in, and set "Get >>>> MIME or Plain Text Digests?" to MIME. You can set this option >>>> globally for all the list digests you receive at this point. >>>> >>>> >>>> >>>> Send dtn-security mailing list submissions to >>>> dtn-security@irtf.org >>>> >>>> To subscribe or unsubscribe via the World Wide Web, visit >>>> https://www.irtf.org/mailman/listinfo/dtn-security >>>> or, via email, send a message with subject or body 'help' to >>>> dtn-security-request@irtf.org >>>> >>>> You can reach the person managing the list at >>>> dtn-security-owner@irtf.org >>>> >>>> When replying, please edit your Subject line so it is more specific >>>> than "Re: Contents of dtn-security digest..." >>>> >>>> Today's Topics: >>>> >>>> 1. Re: dtn-security Digest, Vol 9, Issue 4 (Stephen Farrell) >>>> >>>> >>>> ---------- Forwarded message ---------- >>>> From: Stephen Farrell <stephen.farrell@cs.tcd.ie> >>>> To: "Birrane, Edward J." <Edward.Birrane@jhuapl.edu> >>>> Cc: "dtn-security@irtf.org" <dtn-security@irtf.org> >>>> Date: Sun, 27 Jan 2013 02:08:27 +0000 >>>> Subject: Re: [dtn-security] dtn-security Digest, Vol 9, Issue 4 >>>> >>>> >>>> On 27 Jan 2013, at 01:18, "Birrane, Edward J." <Edward.Birrane@jhuapl.edu> >>>> wrote: >>>> >>>>> Angela, >>>>> >>>>> I see (at least) two issues independent enough that they should not be >>>>> conflated. The first is whether simplifying the BSP specification, to >>>>> omit >>>>> tight routing coupling, is beneficial. The second is the utility of the >>>>> bundle-in-bundle encapsulation mechanism in a security context. >>>>> >>>>> 1. Simplifying BSP >>>>> What we have found is that the concept of a security destination, >>>>> separate from a bundle destination, places a burden on any routing >>>>> mechanism >>>>> to guarantee delivery through one or more "waypoints" before the bundle >>>>> reaches its destination. Since routing mechanisms cannot make this >>>>> guarantee in any type of opportunistic network (and may struggle to make >>>>> this guarantee in structured networks) we need to find a way to relax this >>>>> language and the implementation hurdles it imposes. Removing security >>>>> sources and destinations from the specification and deferring tunneling >>>>> and >>>>> multi-point behavior to some other mechanism (or mechanisms) seems like a >>>>> promising way to go for BSP. >>>>> >>>>> I think most folks on this list agree with the above, but before we get >>>>> too deeply into specifics surrounding encapsulation, it is probably a good >>>>> idea to check that assumption. >>>>> >>>>> ---> Do we agree that (provided we can meet necessary use cases) this is a >>>>> desired simplification of BSP? >>>> >>>> That's neither needed nor necessarily desirable. Just write the draft that >>>> says how to do it, then ask if people like it. Abstract argument in advance >>>> doesn't seem useful. >>>> >>>> S >>>> >>>>> >>>>> >>>>> 2. Bundle-in-Bundle (BiB) encapsulation >>>>> >>>>> BiB is a useful way to create a tunnel in a network at the BP layer. With >>>>> any tunneled packet, it should be protected from misuse while in the >>>>> tunnel, >>>>> and encapsulation is a way to do that. IMO, it should be used exactly in >>>>> those situations where we need a security destination that is different >>>>> than >>>>> the bundle destination; i.e. When we need to make a security tunnel. >>>>> >>>>> Actions such as adding a signature to a bundle or encrypting a bundle, >>>>> would not require encapsulation if the security destinations remain the >>>>> bundle destinations. The only exception here would be BAB, which is the >>>>> special case of next-hop neighbors, which would still not require an >>>>> encapsulation, but the security destination would be understood to be the >>>>> next immediate BP hop which is knowable by the routing subsystem (arguably >>>>> the only thing knowable by the routing subsystem). >>>>> >>>>> If we have extension blocks that have security destinations different >>>>> from >>>>> the payload security destinations, then it sounds like we are treating >>>>> extension blocks as "extra" independent payloads and that may cause >>>>> identity >>>>> problems beyond these BSP issues. >>>>> >>>>> It would probably be helpful to specify a concrete use-case surrounding >>>>> the signing and encrypting of payloads and extension blocks along the >>>>> traversed path of a bundle. Could you propose such a use case? >>>>> >>>>> -Ed >>>>> >>>>> On 1/23/13 1:03 PM, "ahennes1@math.umd.edu" <ahennes1@math.umd.edu> wrote: >>>>> >>>>>> Hi Scott, >>>>>> >>>>>> I like how this approach simplifies the routing and gets rid of the >>>>>> security src/dest and EID refs. I was a little confused though about >>>>>> how this would work with some of the combinations of security blocks: >>>>>> >>>>>> If a node just wants to add a signature to a bundle, would this >>>>>> require the bundle to be encapsulated? One of the advantages of BSP is >>>>>> that non security-aware nodes can still access the payload by just >>>>>> ignoring the PIB block. Wouldn't we lose that feature if the bundle >>>>>> were encapsulated? >>>>>> >>>>>> If a node wants to sign and then encrypt the bundle, does this require >>>>>> the bundle to be encapsulated twice? >>>>>> >>>>>> How would we handle signing/encrypting extension blocks? Would this >>>>>> require a third encapsulation? Wouldn't we still need correlators in >>>>>> case multiple extension blocks are encrypted with the same key, or >>>>>> would we not allow different extension blocks to be encrypted with >>>>>> different keys? >>>>>> >>>>>> >>>>>> Thanks, >>>>>> Angela >>>>>> >>>>>> >>>>>> >>>>>> On Tue, Jan 22, 2013 at 6:49 PM, <dtn-security-request@irtf.org> wrote: >>>>>>> If you have received this digest without all the individual message >>>>>>> attachments you will need to update your digest options in your list >>>>>>> subscription. To do so, go to >>>>>>> >>>>>>> https://www.irtf.org/mailman/listinfo/dtn-security >>>>>>> >>>>>>> Click the 'Unsubscribe or edit options' button, log in, and set "Get >>>>>>> MIME or Plain Text Digests?" to MIME. You can set this option >>>>>>> globally for all the list digests you receive at this point. >>>>>>> >>>>>>> >>>>>>> >>>>>>> Send dtn-security mailing list submissions to >>>>>>> dtn-security@irtf.org >>>>>>> >>>>>>> To subscribe or unsubscribe via the World Wide Web, visit >>>>>>> https://www.irtf.org/mailman/listinfo/dtn-security >>>>>>> or, via email, send a message with subject or body 'help' to >>>>>>> dtn-security-request@irtf.org >>>>>>> >>>>>>> You can reach the person managing the list at >>>>>>> dtn-security-owner@irtf.org >>>>>>> >>>>>>> When replying, please edit your Subject line so it is more specific >>>>>>> than "Re: Contents of dtn-security digest..." >>>>>>> >>>>>>> Today's Topics: >>>>>>> >>>>>>> 1. Re: FW: Re(19): Implementing Security Destinations inDTN2 >>>>>>> (Eddy, Wesley M. (GRC-MS00)[MTI SYSTEMS, INC.]) >>>>>>> 2. Re: FW: Re(19): Implementing Security Destinations inDTN2 >>>>>>> (Eddy, Wesley M. (GRC-MS00)[MTI SYSTEMS, INC.]) >>>>>>> >>>>>>> >>>>>>> ---------- Forwarded message ---------- >>>>>>> From: "Eddy, Wesley M. (GRC-MS00)[MTI SYSTEMS, INC.]" >>>>>>> <wesley.m.eddy@nasa.gov> >>>>>>> To: "Burleigh, Scott C" <scott.c.burleigh@jpl.nasa.gov>ov>, >>>>>>> "dtn-security@irtf.org" <dtn-security@irtf.org> >>>>>>> Cc: >>>>>>> Date: Tue, 22 Jan 2013 17:19:48 -0600 >>>>>>> Subject: Re: [dtn-security] FW: Re(19): Implementing Security >>>>>>> Destinations >>>>>>> inDTN2 >>>>>>> It looks like basically a good idea to me. >>>>>>> >>>>>>> I recall sometime in 2006 or 2007ish pointing out that security >>>>>>> destinations >>>>>>> needed to work more like IPsec tunnel-mode endpoints in order to make >>>>>>> the >>>>>>> routing work correctly, and I think what you're proposing here >>>>>>> accomplishes >>>>>>> that in a better way. >>>>>>> >>>>>>> Though I think cycles would be better spent on KMP issues that are >>>>>>> actually >>>>>>> HARD, and *then* circling back to see what could be tweaked in the BSP, >>>>>>> I >>>>>>> definitely think this proposed change is something that would improve >>>>>>> the >>>>>>> BSP >>>>>>> a bit in the meantime. >>>>>>> >>>>>>> I don't think it can be done in a way that's friendly to the existing >>>>>>> codebase like Stephen suggests shooting for. >>>>>>> >>>>>>> ________________________________ >>>>>>> From: dtn-security-bounces@irtf.org [dtn-security-bounces@irtf.org] On >>>>>>> Behalf >>>>>>> Of Burleigh, Scott C (313B) [scott.c.burleigh@jpl.nasa.gov] >>>>>>> Sent: Tuesday, January 22, 2013 5:37 PM >>>>>>> To: dtn-security@irtf.org >>>>>>> Subject: [dtn-security] FW: Re(19): Implementing Security Destinations >>>>>>> inDTN2 >>>>>>> >>>>>>> Hi. Late last September, several of us spun off a sub-thread talking >>>>>>> about >>>>>>> how the processing of bundles with multiple security destinations could >>>>>>> be >>>>>>> handled in DTN implementations. I won¹t try to recreate all of the >>>>>>> arguments >>>>>>> on all sides, but I think we did converge on agreement that the current >>>>>>> BSP >>>>>>> mechanism for complex, multi-destination security could be difficult to >>>>>>> realize in coherent fashion across the network. After puzzling over >>>>>>> this >>>>>>> for >>>>>>> a while, I came up with a concept (below) that I think would be simpler, >>>>>>> safer, and even more powerful than the current protocol design. How do >>>>>>> we >>>>>>> all feel about this? Would it be worthwhile for DTNRG to invest in a >>>>>>> 6257bis >>>>>>> RFC along these lines? >>>>>>> >>>>>>> Scott >>>>>>> _____________________________________________ >>>>>>> From: Burleigh, Scott C (313B) >>>>>>> Sent: Friday, November 16, 2012 5:05 PM >>>>>>> To: 'Peter Lovell'; ahennes1@math.umd.edu >>>>>>> Cc: Amy Alford; Cherita.Corbett@jhuapl.edu; Howard Weiss >>>>>>> Subject: RE: Re(19): [dtn-security] Implementing Security Destinations >>>>>>> in >>>>>>> DTN2 >>>>>>> >>>>>>> >>>>>>> Hi, Peter. At the risk (I know) of getting a lot of people severely >>>>>>> ticked >>>>>>> off at me, I am going to offer a modest proposal for improving the >>>>>>> Bundle >>>>>>> Security Protocol, inspired by this thread. >>>>>>> I propose to adopt a new design principle for Bundle Security Protocol: >>>>>>> the >>>>>>> routing element of a bundle protocol agent should never need to inspect >>>>>>> a >>>>>>> bundle¹s BSP extension blocks in order to select the node(s) to forward >>>>>>> the >>>>>>> bundle to. >>>>>>> That is, BSP should provide security, not dictate routes. >>>>>>> My rationale for proposing this principle is that I believe it would: >>>>>>> >>>>>>> Simplify BSP, thereby reducing the incidence of bugs and making Bundle >>>>>>> Security significantly less expensive to implement and sustain. >>>>>>> Broaden the scope of BSP deployment by eliminating its dependence on >>>>>>> specific, BSP-aware routing implementations, thereby increasing the >>>>>>> overall >>>>>>> security of DTN. >>>>>>> Reduce the cost of developing and improving routing implementations by >>>>>>> removing any requirement that they be BSP-aware, and broaden the scope >>>>>>> of >>>>>>> deployment of non-BSP-aware routing implementations by enabling them to >>>>>>> be >>>>>>> used in environments requiring arbitrarily powerful security. Thereby, >>>>>>> improve DTN operational performance. >>>>>>> >>>>>>> Here's how I would apply this principle: >>>>>>> >>>>>>> Eliminate security sources and security destinations from all BSP >>>>>>> blocks. >>>>>>> The security source of a BSP block would always be the bundle¹s source. >>>>>>> The >>>>>>> security destination of a BSP block would always be the bundle¹s >>>>>>> destination. >>>>>>> Add a new Administrative Record type for Bundle-in-Bundle encapsulation. >>>>>>> When additional security must be applied to a bundle on some segment of >>>>>>> its >>>>>>> end-to-end path, encapsulate the bundle in a Bundle-in-Bundle >>>>>>> Encapsulation >>>>>>> Administrative Record that is the payload of a new bundle whose source >>>>>>> is >>>>>>> the >>>>>>> security source of the path segment and whose destination is the >>>>>>> security >>>>>>> destination of the path segment. Apply the additional bundle >>>>>>> transmission >>>>>>> security measures to the encapsulating bundle: encrypt its payload (the >>>>>>> Administrative Record, containing the encapsulated bundle), encrypt >>>>>>> extension >>>>>>> blocks as copied from the encapsulated bundle, etc. Then forward the >>>>>>> encapsulating bundle. >>>>>>> When route service uncertainty forces a bundle to be routed over >>>>>>> multiple >>>>>>> parallel additionally secured segments of its end-to-end path, >>>>>>> encapsulate >>>>>>> it >>>>>>> as above but within multiple different encapsulating bundles, one for >>>>>>> each >>>>>>> of >>>>>>> the parallel segments, and forward all of them. >>>>>>> At the destination of a bundle, apply all relevant bundle reception >>>>>>> security >>>>>>> measures and then, if the payload is an encapsulation Administrative >>>>>>> Record, >>>>>>> extract the encapsulated bundle from the Administrative Record and >>>>>>> simply >>>>>>> forward it. >>>>>>> >>>>>>> I believe this would have the following impacts on DTN security: >>>>>>> >>>>>>> No EID references in BSP, simplifying canonicalization. >>>>>>> PCBs only encrypt payloads, never PIBs or PCBs (encrypting the >>>>>>> encapsulated >>>>>>> bundle encrypts all three at once), so no correlators in BSP. (Except >>>>>>> for >>>>>>> BABs, no bundle ever has more than one occurrence of any type of BSP >>>>>>> block. >>>>>>> And there will never be more than two BABs, one immediately following >>>>>>> the >>>>>>> primary block and one that is the final block in the bundle, so that >>>>>>> correlation is structural.) >>>>>>> No delicate ³replacement² process for unraveling PCB nesting at the >>>>>>> destination. >>>>>>> No possible confusion about the correct order of application of BSP >>>>>>> blocks. >>>>>>> No possible conflict among security destinations of different BSP >>>>>>> blocks. >>>>>>> Security paths can never overlap. >>>>>>> Any routing implementation can always accommodate any security regime: >>>>>>> routes >>>>>>> that must be followed to ensure security are encoded into routing >>>>>>> information >>>>>>> at the forwarding node, not into the bundle. (A little like the late >>>>>>> binding >>>>>>> principle.) >>>>>>> Any routing environment can always be made arbitrarily secure no need >>>>>>> to >>>>>>> require specially BSP-aware routing elements. >>>>>>> Ciphersuite design is simplified, so a wider array of useful >>>>>>> ciphersuites >>>>>>> can >>>>>>> be developed without imposing bug-prone complexity. Minimizes possible >>>>>>> security problems. >>>>>>> >>>>>>> As an example of how I think this could work, see the attached diagram: >>>>>>> >>>>>>> Node A is sending a bundle to node K. Nodes A, B, J, and K are within >>>>>>> the >>>>>>> low-risk ³W² security region; nodes C and G are gateways between region >>>>>>> W >>>>>>> and >>>>>>> the more hazardous region X; node D is another node in X; nodes E and F >>>>>>> are >>>>>>> gateways between region X and even more hazardous region Y; nodes H and >>>>>>> I >>>>>>> are >>>>>>> gateways between X and hazardous region Z. >>>>>>> At A the bundle is simply forwarded to B. >>>>>>> At B the routing element realizes that the bundle has to traverse region >>>>>>> X >>>>>>> in >>>>>>> order to get to K, so it forwards the bundle to C. >>>>>>> The routing element at C encapsulates the bundle in an Admin Record, >>>>>>> creates >>>>>>> a new bundle destined for G (the egress from region X) whose source is C >>>>>>> and >>>>>>> whose payload is that Admin Record, encrypts the payload, attaches a >>>>>>> PCB, >>>>>>> and >>>>>>> forwards the bundle to D. >>>>>>> D realizes that the bundle has to traverse region Y in order to get to >>>>>>> G, >>>>>>> so >>>>>>> it forwards the bundle to E. >>>>>>> E encapsulates the bundle in an Admin Record, creates a new bundle >>>>>>> destined >>>>>>> for F (the egress from region Y) whose source is E and whose payload is >>>>>>> that >>>>>>> Admin Record, encrypts the payload, attaches a PCB, and forwards the >>>>>>> bundle >>>>>>> to F. >>>>>>> The bundle protocol agent at F receives the bundle, decrypts it, and >>>>>>> passes >>>>>>> the payload (an Admin Record) to the application agent. The >>>>>>> administrative >>>>>>> element of the application agent at F receives the Admin Record, >>>>>>> extracts >>>>>>> the >>>>>>> encapsulated bundle destined for G, and queues it to be forwarded. The >>>>>>> routing element at F sees this bundle and forwards it to G. >>>>>>> The bundle protocol agent at G receives the bundle, decrypts it, and >>>>>>> passes >>>>>>> the payload (an Admin Record) to the application agent. The >>>>>>> administrative >>>>>>> element of the application agent at G receives the Admin Record, >>>>>>> extracts >>>>>>> the >>>>>>> encapsulated bundle destined for K, and queues it to be forwarded. The >>>>>>> routing element at G sees this bundle, realizes that the bundle has to >>>>>>> traverse region Z in order to get to K, and therefore forwards the >>>>>>> bundle >>>>>>> to >>>>>>> H. >>>>>>> H encapsulates the bundle in an Admin Record, creates a new bundle >>>>>>> destined >>>>>>> for I (the egress from region Z) whose source is H and whose payload is >>>>>>> that >>>>>>> Admin Record, encrypts the payload, attaches a PCB, and forwards the >>>>>>> bundle >>>>>>> to I. >>>>>>> The bundle protocol agent at I receives the bundle, decrypts it, and >>>>>>> passes >>>>>>> the payload (an Admin Record) to the application agent. The >>>>>>> administrative >>>>>>> element of the application agent at I receives the Admin Record, >>>>>>> extracts >>>>>>> the >>>>>>> encapsulated bundle destined for K, and queues it to be forwarded. The >>>>>>> routing element at I sees this bundle and forwards it to J. >>>>>>> At J the bundle is simply forwarded to K. >>>>>>> At K the bundle¹s payload is passed to the application. >>>>>>> >>>>>>> I think this approach would combine simplicity with quite a lot of >>>>>>> operational power, making everything cheaper and safer. >>>>>>> So, having now stirred the hornet¹s nest, I will beat a hasty retreat >>>>>>> for >>>>>>> a >>>>>>> week while I am on vacation. I¹ll try to follow up when I get back. >>>>>>> Have a nice Thanksgiving, everybody. >>>>>>> Scott >>>>>>> >>>>>>> -----Original Message----- >>>>>>> From: Peter Lovell [mailto:plovell@mac.com] >>>>>>> Sent: Monday, October 22, 2012 1:28 PM >>>>>>> To: Burleigh, Scott C (313B); ahennes1@math.umd.edu >>>>>>> Cc: Amy Alford; Cherita.Corbett@jhuapl.edu; Howard Weiss; Peter Lovell >>>>>>> Subject: Re(19): [dtn-security] Implementing Security Destinations in >>>>>>> DTN2 >>>>>>> >>>>>>> On Wed, Oct 24, 2012, Burleigh, Scott C (313B) >>>>>>> <scott.c.burleigh@jpl.nasa.gov> wrote: >>>>>>> >>>>>>>> In view of which, I've now become a bigger fan of bundle-in-bundle >>>>>>>> tunneling than I've been in the past. >>>>>>> >>>>>>> Hi Scott, >>>>>>> >>>>>>> I agree. I'm also a big fan, for a bunch of reasons. However, as I >>>>>>> mentioned >>>>>>> to Angela, the current [i.e. latest, expired] draft seems a bit "funky" >>>>>>> to >>>>>>> me. There's no indication in the bundle that it's BiB and you need some >>>>>>> special EID to perform the decapsulation. Maybe that's just like an >>>>>>> assigned >>>>>>> port in TCP but we don't yet have such a mechanism. The multiple-bundle >>>>>>> thing >>>>>>> is OK, I guess, but I don't see much use for it other than volume >>>>>>> gateway-to-gateway traffic and I think that such heavy-duty tunnels >>>>>>> could >>>>>>> be >>>>>>> specially optimized. >>>>>>> >>>>>>> I need to go back and review all the discussions about BiB -- we worked >>>>>>> it >>>>>>> quite a bit but the spec never gained enough consensus to move forward. >>>>>>> I >>>>>>> think it would be a good idea to revisit it now and get a solid draft >>>>>>> that >>>>>>> has wider support. Maybe the email discussions will help us get there. >>>>>>> >>>>>>> Thanks.....Peter >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> ---------- Forwarded message ---------- >>>>>>> From: "Eddy, Wesley M. (GRC-MS00)[MTI SYSTEMS, INC.]" >>>>>>> <wesley.m.eddy@nasa.gov> >>>>>>> To: "Burleigh, Scott C" <scott.c.burleigh@jpl.nasa.gov>ov>, >>>>>>> "dtn-security@irtf.org" <dtn-security@irtf.org> >>>>>>> Cc: >>>>>>> Date: Tue, 22 Jan 2013 17:47:47 -0600 >>>>>>> Subject: Re: [dtn-security] FW: Re(19): Implementing Security >>>>>>> Destinations >>>>>>> inDTN2 >>>>>>> Agreed; that makes sense. >>>>>>> >>>>>>> ________________________________ >>>>>>> From: Burleigh, Scott C (313B) [scott.c.burleigh@jpl.nasa.gov] >>>>>>> Sent: Tuesday, January 22, 2013 6:35 PM >>>>>>> To: Eddy, Wesley M. (GRC-MS00)[MTI SYSTEMS, INC.]; dtn-security@irtf.org >>>>>>> Subject: RE: [dtn-security] FW: Re(19): Implementing Security >>>>>>> Destinations >>>>>>> inDTN2 >>>>>>> >>>>>>> Wes, I agree that some code change would be entailed in implementing >>>>>>> this >>>>>>> proposal, but I think a large proportion of the code the general flow >>>>>>> of >>>>>>> processing the extension blocks, the canonicalization, the ciphersuites, >>>>>>> really almost everything that would have been implemented to handle the >>>>>>> simple case of security source/destination being identical to bundle >>>>>>> source/destination would be preserved. I suspect that much of what I >>>>>>> was >>>>>>> proposing here involves removing functionality that most developers >>>>>>> haven¹t >>>>>>> implemented yet anyway, because of the potential pitfalls. >>>>>>> >>>>>>> >>>>>>> >>>>>>> Scott >>>>>>> >>>>>>> >>>>>>> >>>>>>> From: Eddy, Wesley M. (GRC-MS00)[MTI SYSTEMS, INC.] >>>>>>> [mailto:wesley.m.eddy@nasa.gov] >>>>>>> Sent: Tuesday, January 22, 2013 3:20 PM >>>>>>> To: Burleigh, Scott C (313B); dtn-security@irtf.org >>>>>>> Subject: RE: [dtn-security] FW: Re(19): Implementing Security >>>>>>> Destinations >>>>>>> inDTN2 >>>>>>> >>>>>>> >>>>>>> >>>>>>> It looks like basically a good idea to me. >>>>>>> >>>>>>> >>>>>>> >>>>>>> I recall sometime in 2006 or 2007ish pointing out that security >>>>>>> destinations >>>>>>> needed to work more like IPsec tunnel-mode endpoints in order to make >>>>>>> the >>>>>>> routing work correctly, and I think what you're proposing here >>>>>>> accomplishes >>>>>>> that in a better way. >>>>>>> >>>>>>> >>>>>>> >>>>>>> Though I think cycles would be better spent on KMP issues that are >>>>>>> actually >>>>>>> HARD, and *then* circling back to see what could be tweaked in the BSP, >>>>>>> I >>>>>>> definitely think this proposed change is something that would improve >>>>>>> the >>>>>>> BSP >>>>>>> a bit in the meantime. >>>>>>> >>>>>>> >>>>>>> >>>>>>> I don't think it can be done in a way that's friendly to the existing >>>>>>> codebase like Stephen suggests shooting for. >>>>>>> >>>>>>> >>>>>>> >>>>>>> ________________________________ >>>>>>> >>>>>>> From: dtn-security-bounces@irtf.org [dtn-security-bounces@irtf.org] On >>>>>>> Behalf >>>>>>> Of Burleigh, Scott C (313B) [scott.c.burleigh@jpl.nasa.gov] >>>>>>> Sent: Tuesday, January 22, 2013 5:37 PM >>>>>>> To: dtn-security@irtf.org >>>>>>> Subject: [dtn-security] FW: Re(19): Implementing Security Destinations >>>>>>> inDTN2 >>>>>>> >>>>>>> Hi. Late last September, several of us spun off a sub-thread talking >>>>>>> about >>>>>>> how the processing of bundles with multiple security destinations could >>>>>>> be >>>>>>> handled in DTN implementations. I won¹t try to recreate all of the >>>>>>> arguments >>>>>>> on all sides, but I think we did converge on agreement that the current >>>>>>> BSP >>>>>>> mechanism for complex, multi-destination security could be difficult to >>>>>>> realize in coherent fashion across the network. After puzzling over >>>>>>> this >>>>>>> for >>>>>>> a while, I came up with a concept (below) that I think would be simpler, >>>>>>> safer, and even more powerful than the current protocol design. How do >>>>>>> we >>>>>>> all feel about this? Would it be worthwhile for DTNRG to invest in a >>>>>>> 6257bis >>>>>>> RFC along these lines? >>>>>>> >>>>>>> >>>>>>> >>>>>>> Scott >>>>>>> >>>>>>> _____________________________________________ >>>>>>> From: Burleigh, Scott C (313B) >>>>>>> Sent: Friday, November 16, 2012 5:05 PM >>>>>>> To: 'Peter Lovell'; ahennes1@math.umd.edu >>>>>>> Cc: Amy Alford; Cherita.Corbett@jhuapl.edu; Howard Weiss >>>>>>> Subject: RE: Re(19): [dtn-security] Implementing Security Destinations >>>>>>> in >>>>>>> DTN2 >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> Hi, Peter. At the risk (I know) of getting a lot of people severely >>>>>>> ticked >>>>>>> off at me, I am going to offer a modest proposal for improving the >>>>>>> Bundle >>>>>>> Security Protocol, inspired by this thread. >>>>>>> >>>>>>> I propose to adopt a new design principle for Bundle Security Protocol: >>>>>>> the >>>>>>> routing element of a bundle protocol agent should never need to inspect >>>>>>> a >>>>>>> bundle¹s BSP extension blocks in order to select the node(s) to forward >>>>>>> the >>>>>>> bundle to. >>>>>>> >>>>>>> That is, BSP should provide security, not dictate routes. >>>>>>> >>>>>>> My rationale for proposing this principle is that I believe it would: >>>>>>> >>>>>>> · Simplify BSP, thereby reducing the incidence of bugs and >>>>>>> making >>>>>>> Bundle Security significantly less expensive to implement and sustain. >>>>>>> >>>>>>> · Broaden the scope of BSP deployment by eliminating its >>>>>>> dependence >>>>>>> on specific, BSP-aware routing implementations, thereby increasing the >>>>>>> overall security of DTN. >>>>>>> >>>>>>> · Reduce the cost of developing and improving routing >>>>>>> implementations >>>>>>> by removing any requirement that they be BSP-aware, and broaden the >>>>>>> scope >>>>>>> of >>>>>>> deployment of non-BSP-aware routing implementations by enabling them to >>>>>>> be >>>>>>> used in environments requiring arbitrarily powerful security. Thereby, >>>>>>> improve DTN operational performance. >>>>>>> >>>>>>> Here's how I would apply this principle: >>>>>>> >>>>>>> 1. Eliminate security sources and security destinations from all >>>>>>> BSP >>>>>>> blocks. The security source of a BSP block would always be the bundle¹s >>>>>>> source. The security destination of a BSP block would always be the >>>>>>> bundle¹s >>>>>>> destination. >>>>>>> >>>>>>> 2. Add a new Administrative Record type for Bundle-in-Bundle >>>>>>> encapsulation. >>>>>>> >>>>>>> 3. When additional security must be applied to a bundle on some >>>>>>> segment >>>>>>> of its end-to-end path, encapsulate the bundle in a Bundle-in-Bundle >>>>>>> Encapsulation Administrative Record that is the payload of a new bundle >>>>>>> whose >>>>>>> source is the security source of the path segment and whose destination >>>>>>> is >>>>>>> the security destination of the path segment. Apply the additional >>>>>>> bundle >>>>>>> transmission security measures to the encapsulating bundle: encrypt its >>>>>>> payload (the Administrative Record, containing the encapsulated bundle), >>>>>>> encrypt extension blocks as copied from the encapsulated bundle, etc. >>>>>>> Then >>>>>>> forward the encapsulating bundle. >>>>>>> >>>>>>> 4. When route service uncertainty forces a bundle to be routed >>>>>>> over >>>>>>> multiple parallel additionally secured segments of its end-to-end path, >>>>>>> encapsulate it as above but within multiple different encapsulating >>>>>>> bundles, >>>>>>> one for each of the parallel segments, and forward all of them. >>>>>>> >>>>>>> 5. At the destination of a bundle, apply all relevant bundle >>>>>>> reception >>>>>>> security measures and then, if the payload is an encapsulation >>>>>>> Administrative >>>>>>> Record, extract the encapsulated bundle from the Administrative Record >>>>>>> and >>>>>>> simply forward it. >>>>>>> >>>>>>> I believe this would have the following impacts on DTN security: >>>>>>> >>>>>>> · No EID references in BSP, simplifying canonicalization. >>>>>>> >>>>>>> · PCBs only encrypt payloads, never PIBs or PCBs (encrypting the >>>>>>> encapsulated bundle encrypts all three at once), so no correlators in >>>>>>> BSP. >>>>>>> (Except for BABs, no bundle ever has more than one occurrence of any >>>>>>> type >>>>>>> of >>>>>>> BSP block. And there will never be more than two BABs, one immediately >>>>>>> following the primary block and one that is the final block in the >>>>>>> bundle, >>>>>>> so >>>>>>> that correlation is structural.) >>>>>>> >>>>>>> · No delicate ³replacement² process for unraveling PCB nesting >>>>>>> at >>>>>>> the >>>>>>> destination. >>>>>>> >>>>>>> · No possible confusion about the correct order of application >>>>>>> of >>>>>>> BSP >>>>>>> blocks. >>>>>>> >>>>>>> · No possible conflict among security destinations of different >>>>>>> BSP >>>>>>> blocks. >>>>>>> >>>>>>> · Security paths can never overlap. >>>>>>> >>>>>>> · Any routing implementation can always accommodate any security >>>>>>> regime: routes that must be followed to ensure security are encoded into >>>>>>> routing information at the forwarding node, not into the bundle. (A >>>>>>> little >>>>>>> like the late binding principle.) >>>>>>> >>>>>>> · Any routing environment can always be made arbitrarily secure >>>>>>> >>>>>>> no >>>>>>> need to require specially BSP-aware routing elements. >>>>>>> >>>>>>> · Ciphersuite design is simplified, so a wider array of useful >>>>>>> ciphersuites can be developed without imposing bug-prone complexity. >>>>>>> Minimizes possible security problems. >>>>>>> >>>>>>> As an example of how I think this could work, see the attached diagram: >>>>>>> >>>>>>> 1. Node A is sending a bundle to node K. Nodes A, B, J, and K are >>>>>>> within the low-risk ³W² security region; nodes C and G are gateways >>>>>>> between >>>>>>> region W and the more hazardous region X; node D is another node in X; >>>>>>> nodes >>>>>>> E and F are gateways between region X and even more hazardous region Y; >>>>>>> nodes >>>>>>> H and I are gateways between X and hazardous region Z. >>>>>>> >>>>>>> 2. At A the bundle is simply forwarded to B. >>>>>>> >>>>>>> 3. At B the routing element realizes that the bundle has to >>>>>>> traverse >>>>>>> region X in order to get to K, so it forwards the bundle to C. >>>>>>> >>>>>>> 4. The routing element at C encapsulates the bundle in an Admin >>>>>>> Record, >>>>>>> creates a new bundle destined for G (the egress from region X) whose >>>>>>> source >>>>>>> is C and whose payload is that Admin Record, encrypts the payload, >>>>>>> attaches a >>>>>>> PCB, and forwards the bundle to D. >>>>>>> >>>>>>> 5. D realizes that the bundle has to traverse region Y in order to >>>>>>> get >>>>>>> to G, so it forwards the bundle to E. >>>>>>> >>>>>>> 6. E encapsulates the bundle in an Admin Record, creates a new >>>>>>> bundle >>>>>>> destined for F (the egress from region Y) whose source is E and whose >>>>>>> payload >>>>>>> is that Admin Record, encrypts the payload, attaches a PCB, and forwards >>>>>>> the >>>>>>> bundle to F. >>>>>>> >>>>>>> 7. The bundle protocol agent at F receives the bundle, decrypts >>>>>>> it, >>>>>>> and >>>>>>> passes the payload (an Admin Record) to the application agent. The >>>>>>> administrative element of the application agent at F receives the Admin >>>>>>> Record, extracts the encapsulated bundle destined for G, and queues it >>>>>>> to >>>>>>> be >>>>>>> forwarded. The routing element at F sees this bundle and forwards it to >>>>>>> G. >>>>>>> >>>>>>> 8. The bundle protocol agent at G receives the bundle, decrypts >>>>>>> it, >>>>>>> and >>>>>>> passes the payload (an Admin Record) to the application agent. The >>>>>>> administrative element of the application agent at G receives the Admin >>>>>>> Record, extracts the encapsulated bundle destined for K, and queues it >>>>>>> to >>>>>>> be >>>>>>> forwarded. The routing element at G sees this bundle, realizes that the >>>>>>> bundle has to traverse region Z in order to get to K, and therefore >>>>>>> forwards >>>>>>> the bundle to H. >>>>>>> >>>>>>> 9. H encapsulates the bundle in an Admin Record, creates a new >>>>>>> bundle >>>>>>> destined for I (the egress from region Z) whose source is H and whose >>>>>>> payload >>>>>>> is that Admin Record, encrypts the payload, attaches a PCB, and forwards >>>>>>> the >>>>>>> bundle to I. >>>>>>> >>>>>>> 10. The bundle protocol agent at I receives the bundle, decrypts it, >>>>>>> and >>>>>>> passes the payload (an Admin Record) to the application agent. The >>>>>>> administrative element of the application agent at I receives the Admin >>>>>>> Record, extracts the encapsulated bundle destined for K, and queues it >>>>>>> to >>>>>>> be >>>>>>> forwarded. The routing element at I sees this bundle and forwards it to >>>>>>> J. >>>>>>> >>>>>>> 11. At J the bundle is simply forwarded to K. >>>>>>> >>>>>>> 12. At K the bundle¹s payload is passed to the application. >>>>>>> >>>>>>> I think this approach would combine simplicity with quite a lot of >>>>>>> operational power, making everything cheaper and safer. >>>>>>> >>>>>>> So, having now stirred the hornet¹s nest, I will beat a hasty retreat >>>>>>> for >>>>>>> a >>>>>>> week while I am on vacation. I¹ll try to follow up when I get back. >>>>>>> >>>>>>> Have a nice Thanksgiving, everybody. >>>>>>> >>>>>>> Scott >>>>>>> >>>>>>> >>>>>>> >>>>>>> -----Original Message----- >>>>>>> From: Peter Lovell [mailto:plovell@mac.com] >>>>>>> Sent: Monday, October 22, 2012 1:28 PM >>>>>>> To: Burleigh, Scott C (313B); ahennes1@math.umd.edu >>>>>>> Cc: Amy Alford; Cherita.Corbett@jhuapl.edu; Howard Weiss; Peter Lovell >>>>>>> Subject: Re(19): [dtn-security] Implementing Security Destinations in >>>>>>> DTN2 >>>>>>> >>>>>>> >>>>>>> >>>>>>> On Wed, Oct 24, 2012, Burleigh, Scott C (313B) >>>>>>> <scott.c.burleigh@jpl.nasa.gov> wrote: >>>>>>> >>>>>>> >>>>>>> >>>>>>>> In view of which, I've now become a bigger fan of bundle-in-bundle >>>>>>> >>>>>>>> tunneling than I've been in the past. >>>>>>> >>>>>>> >>>>>>> >>>>>>> Hi Scott, >>>>>>> >>>>>>> >>>>>>> >>>>>>> I agree. I'm also a big fan, for a bunch of reasons. However, as I >>>>>>> mentioned >>>>>>> to Angela, the current [i.e. latest, expired] draft seems a bit "funky" >>>>>>> to >>>>>>> me. There's no indication in the bundle that it's BiB and you need some >>>>>>> special EID to perform the decapsulation. Maybe that's just like an >>>>>>> assigned >>>>>>> port in TCP but we don't yet have such a mechanism. The multiple-bundle >>>>>>> thing >>>>>>> is OK, I guess, but I don't see much use for it other than volume >>>>>>> gateway-to-gateway traffic and I think that such heavy-duty tunnels >>>>>>> could >>>>>>> be >>>>>>> specially optimized. >>>>>>> >>>>>>> >>>>>>> >>>>>>> I need to go back and review all the discussions about BiB -- we worked >>>>>>> it >>>>>>> quite a bit but the spec never gained enough consensus to move forward. >>>>>>> I >>>>>>> think it would be a good idea to revisit it now and get a solid draft >>>>>>> that >>>>>>> has wider support. Maybe the email discussions will help us get there. >>>>>>> >>>>>>> >>>>>>> >>>>>>> Thanks.....Peter >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> dtn-security mailing list >>>>>>> dtn-security@irtf.org >>>>>>> https://www.irtf.org/mailman/listinfo/dtn-security >>>>>> _______________________________________________ >>>>>> dtn-security mailing list >>>>>> dtn-security@irtf.org >>>>>> https://www.irtf.org/mailman/listinfo/dtn-security >>>>> >>>>> _______________________________________________ >>>>> dtn-security mailing list >>>>> dtn-security@irtf.org >>>>> https://www.irtf.org/mailman/listinfo/dtn-security >>>> >>>> >>>> _______________________________________________ >>>> dtn-security mailing list >>>> dtn-security@irtf.org >>>> https://www.irtf.org/mailman/listinfo/dtn-security >>>> >>> _______________________________________________ >>> dtn-security mailing list >>> dtn-security@irtf.org >>> https://www.irtf.org/mailman/listinfo/dtn-security >>
- Re: [dtn-security] dtn-security Digest, Vol 9, Is… Angela Hennessy
- Re: [dtn-security] dtn-security Digest, Vol 9, Is… Ivancic, William D. (GRC-RHN0)
- Re: [dtn-security] dtn-security Digest, Vol 9, Is… Angela Hennessy
- Re: [dtn-security] dtn-security Digest, Vol 9, Is… Ivancic, William D. (GRC-RHN0)
- Re: [dtn-security] dtn-security Digest, Vol 9, Is… s.shukla
- Re: [dtn-security] dtn-security Digest, Vol 9, Is… Angela Hennessy