Re: [dtn-security] dtn-security Digest, Vol 9, Issue 9

Hi Will,

The work that we did was pretty basic, getting a signature generated
by DTN2 to verify correctly in IBR-DTN, and getting the payload to
decrypt correctly, etc. I think we were able to get encryption and
authentication working together as well. We haven't released the
version of DTN2 that interoperates with IBR-DTN, the main difference
is the DTN2 implementation of BSP uses the Cryptographic Message
Syntax (CMS), which I believe is required in the default ciphersuites.
It's used for interoperability, but since neither IBR-DTN nor ION
implement it (I assume because it adds quite a bit of overhead),
that's something to keep in mind for future drafts.

thanks,
Angela

On Mon, Jan 28, 2013 at 2:46 PM, Ivancic, William D. (GRC-RHN0)
<william.d.ivancic@nasa.gov> wrote:
> 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>,
>>>>>>>> "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>,
>>>>>>>> "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
>>>
>