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
>