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

From: Angela Hennessy <[email-masked]>
Date: Sun, 27 Jan 2013 16:42:18 -0500

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,  <[email-masked]> 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
>         [email-masked]
>
> 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
>         [email-masked]
>
> You can reach the person managing the list at
>         [email-masked]
>
> 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 <[email-masked]>
> To: "Birrane, Edward J." <[email-masked]>
> Cc: "[email-masked]" <[email-masked]>
> 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." <[email-masked]> 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, "[email-masked]" <[email-masked]> 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,  <[email-masked]> 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
>>>>        [email-masked]
>>>>
>>>> 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
>>>>        [email-masked]
>>>>
>>>> You can reach the person managing the list at
>>>>        [email-masked]
>>>>
>>>> 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.]"
>>>> <[email-masked]>
>>>> To: "Burleigh, Scott C" <[email-masked]>,
>>>> "[email-masked]" <[email-masked]>
>>>> 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: [email-masked] [[email-masked]] On Behalf
>>>> Of Burleigh, Scott C (313B) [[email-masked]]
>>>> Sent: Tuesday, January 22, 2013 5:37 PM
>>>> To: [email-masked]
>>>> 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'; [email-masked]
>>>> Cc: Amy Alford; [email-masked]; 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:[email-masked]]
>>>> Sent: Monday, October 22, 2012 1:28 PM
>>>> To: Burleigh, Scott C (313B); [email-masked]
>>>> Cc: Amy Alford; [email-masked]; Howard Weiss; Peter Lovell
>>>> Subject: Re(19): [dtn-security] Implementing Security Destinations in DTN2
>>>>
>>>> On Wed, Oct 24, 2012, Burleigh, Scott C (313B)
>>>> <[email-masked]> 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.]"
>>>> <[email-masked]>
>>>> To: "Burleigh, Scott C" <[email-masked]>,
>>>> "[email-masked]" <[email-masked]>
>>>> 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) [[email-masked]]
>>>> Sent: Tuesday, January 22, 2013 6:35 PM
>>>> To: Eddy, Wesley M. (GRC-MS00)[MTI SYSTEMS, INC.]; [email-masked]
>>>> 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:[email-masked]]
>>>> Sent: Tuesday, January 22, 2013 3:20 PM
>>>> To: Burleigh, Scott C (313B); [email-masked]
>>>> 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: [email-masked] [[email-masked]] On Behalf
>>>> Of Burleigh, Scott C (313B) [[email-masked]]
>>>> Sent: Tuesday, January 22, 2013 5:37 PM
>>>> To: [email-masked]
>>>> 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'; [email-masked]
>>>> Cc: Amy Alford; [email-masked]; 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:[email-masked]]
>>>> Sent: Monday, October 22, 2012 1:28 PM
>>>> To: Burleigh, Scott C (313B); [email-masked]
>>>> Cc: Amy Alford; [email-masked]; Howard Weiss; Peter Lovell
>>>> Subject: Re(19): [dtn-security] Implementing Security Destinations in DTN2
>>>>
>>>>
>>>>
>>>> On Wed, Oct 24, 2012, Burleigh, Scott C (313B)
>>>> <[email-masked]> 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
>>>> [email-masked]
>>>> https://www.irtf.org/mailman/listinfo/dtn-security
>>> _______________________________________________
>>> dtn-security mailing list
>>> [email-masked]
>>> https://www.irtf.org/mailman/listinfo/dtn-security
>>
>> _______________________________________________
>> dtn-security mailing list
>> [email-masked]
>> https://www.irtf.org/mailman/listinfo/dtn-security
>
>
> _______________________________________________
> dtn-security mailing list
> [email-masked]
> https://www.irtf.org/mailman/listinfo/dtn-security
>

---

From: "Ivancic, William D. (GRC-RHN0)" <[email-masked]>
Date: Mon, 28 Jan 2013 09:46:57 -0600

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 <[email-masked]>
> Date: Sun, 27 Jan 2013 15:42:18 -0600
> To: "[email-masked]" <[email-masked]>
> Subject: Re: [dtn-security] dtn-security Digest, Vol 9, Issue 9
>
> Hi Ed,
>
>> 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
>>
>>>
>>>

---

From: Angela Hennessy <[email-masked]>
Date: Mon, 28 Jan 2013 14:25:39 -0500

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

---

From: "Ivancic, William D. (GRC-RHN0)" <[email-masked]>
Date: Mon, 28 Jan 2013 13:46:24 -0600

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

> Date: Mon, 28 Jan 2013 13:25:39 -0600
> To: "Ivancic, William D. (GRC-RHN0)" <[email-masked]>
>>>>>>> definitely think this proposed change is something that would improve
>>>>>>> the
>>>>>>> BSP
>>>>>>> a bit in the meantime.
>>>>>>>
>>>>>>> realize in coherent fashion across the network.  After puzzling over
>>>>>>> this
>>>>>>> for
>>>>>>> Administrative Record that is the payload of a new bundle whose source
>>>>>>> is
>>>>>>> the
>>>>>>> parallel additionally secured segments of its end-to-end path,
>>>>>>> encapsulate
>>>>>>> it
>>>>>>> as above but within multiple different encapsulating bundles, one for
>>>>>>> each
>>>>>>> of
>>>>>>> Ciphersuite design is simplified, so a wider array of useful
>>>>>>> ciphersuites
>>>>>>> can
>>>>>>> low-risk ³W² security region; nodes C and G are gateways between region
>>>>>>> W
>>>>>>> and
>>>>>>> gateways between region X and even more hazardous region Y; nodes H and
>>>>>>> I
>>>>>>> are
>>>>>>> At B the routing element realizes that the bundle has to traverse region
>>>>>>> X
>>>>>>> in
>>>>>>> whose payload is that Admin Record, encrypts the payload, attaches a
>>>>>>> PCB,
>>>>>>> and
>>>>>>> D realizes that the bundle has to traverse region Y in order to get to
>>>>>>> G,
>>>>>>> so
>>>>>>> element of the application agent at F receives the Admin Record,
>>>>>>> extracts
>>>>>>> the
>>>>>>> element of the application agent at G receives the Admin Record,
>>>>>>> extracts
>>>>>>> the
>>>>>>> traverse region Z in order to get to K, and therefore forwards the
>>>>>>> bundle
>>>>>>> to
>>>>>>> H.
>>>>>>> element of the application agent at I receives the Admin Record,
>>>>>>> extracts
>>>>>>> the
>>>>>>> So, having now stirred the hornet¹s nest, I will beat a hasty retreat
>>>>>>> for
>>>>>>> a
>>>>>>> gateway-to-gateway traffic and I think that such heavy-duty tunnels
>>>>>>> could
>>>>>>> be
>>>>>>> specially optimized.
>>>>>>>
>>>>>>> definitely think this proposed change is something that would improve
>>>>>>> the
>>>>>>> BSP
>>>>>>> a bit in the meantime.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> realize in coherent fashion across the network.  After puzzling over
>>>>>>> this
>>>>>>> for
>>>>>>> by removing any requirement that they be BSP-aware, and broaden the
>>>>>>> scope
>>>>>>> of
>>>>>>> (Except for BABs, no bundle ever has more than one occurrence of any
>>>>>>> type
>>>>>>> of
>>>>>>> following the primary block and one that is the final block in the
>>>>>>> bundle,
>>>>>>> so
>>>>>>> ·         No delicate ³replacement² process for unraveling PCB nesting
>>>>>>> at
>>>>>>> the
>>>>>>> destination.
>>>>>>>
>>>>>>> ·         No possible confusion about the correct order of application
>>>>>>> of
>>>>>>> BSP
>>>>>>> blocks.
>>>>>>>
>>>>>>> ·         Any routing environment can always be made arbitrarily secure
>>>>>>> 
>>>>>>> no
>>>>>>> 7.       The bundle protocol agent at F receives the bundle, decrypts
>>>>>>> it,
>>>>>>> and
>>>>>>> Record, extracts the encapsulated bundle destined for G, and queues it
>>>>>>> to
>>>>>>> be
>>>>>>> 8.       The bundle protocol agent at G receives the bundle, decrypts
>>>>>>> it,
>>>>>>> and
>>>>>>> Record, extracts the encapsulated bundle destined for K, and queues it
>>>>>>> to
>>>>>>> be
>>>>>>> Record, extracts the encapsulated bundle destined for K, and queues it
>>>>>>> to
>>>>>>> be
>>>>>>> So, having now stirred the hornet¹s nest, I will beat a hasty retreat
>>>>>>> for
>>>>>>> a
>>>>>>> gateway-to-gateway traffic and I think that such heavy-duty tunnels
>>>>>>> could
>>>>>>> be
>>>>>>> specially optimized.
>>>>>>>
>>>>>>>
>>>>>>>

---

From: [email-masked]
Date: Tue, 29 Jan 2013 12:33:22 +0530

Hi all,
I have been working in DTN for adhoc network for past two years.I am not
much aware of BiB architecture. If I can get some recent draft on BIB and
DTN security, I will be thankful to you all.

Shailendra.

>>>>> On 27 Jan 2013, at 01:18, "Birrane, Edward J."
>>>>> <[email-masked]>
>>>>> wrote:
>>>>>
>>>>>> Angela,
>>>>>>
>>>>>> conflated.   The first is whether simplifying the BSP specification,
>>>>>> to
>>>>>> omit
>>>>>> sources and destinations from the specification and deferring
>>>>>> tunneling
>>>>>> and
>>>>>> those situations where we need a security destination that is
>>>>>> different
>>>>>> than
>>>>>>  If we have extension blocks that have security destinations
>>>>>> different
>>>>>> from
>>>>>>>> needed to work more like IPsec tunnel-mode endpoints in order to
>>>>>>>> make
>>>>>>>> the
>>>>>>>> HARD, and *then* circling back to see what could be tweaked in the
>>>>>>>> BSP,
>>>>>>>> I
>>>>>>>> From: [email-masked]
>>>>>>>> [[email-masked]] On
>>>>>>>> Behalf
>>>>>>>> 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
>>>>>>>> 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
>>>>>>>> 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
>>>>>>>> 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.
>>>>>>>> specific, BSP-aware routing implementations, thereby increasing
>>>>>>>> the
>>>>>>>> overall
>>>>>>>> security of DTN.
>>>>>>>> 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
>>>>>>>> The security source of a BSP block would always be the bundle¹s
>>>>>>>> source.
>>>>>>>> The
>>>>>>>> When additional security must be applied to a bundle on some
>>>>>>>> segment of
>>>>>>>> its
>>>>>>>> Administrative Record, containing the encapsulated bundle),
>>>>>>>> encrypt
>>>>>>>> extension
>>>>>>>> At the destination of a bundle, apply all relevant bundle
>>>>>>>> reception
>>>>>>>> security
>>>>>>>> measures and then, if the payload is an encapsulation
>>>>>>>> Administrative
>>>>>>>> Record,
>>>>>>>> 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
>>>>>>>> No possible confusion about the correct order of application of
>>>>>>>> BSP
>>>>>>>> blocks.
>>>>>>>> Any routing implementation can always accommodate any security
>>>>>>>> regime:
>>>>>>>> routes
>>>>>>>> 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
>>>>>>>> Node A is sending a bundle to node K.  Nodes A, B, J, and K are
>>>>>>>> within
>>>>>>>> the
>>>>>>>> the more hazardous region X; node D is another node in X; nodes E
>>>>>>>> and F
>>>>>>>> are
>>>>>>>> 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
>>>>>>>> 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 bundle protocol agent at G receives the bundle, decrypts it,
>>>>>>>> and
>>>>>>>> passes
>>>>>>>> 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
>>>>>>>> Subject: Re(19): [dtn-security] Implementing Security Destinations
>>>>>>>> in
>>>>>>>> DTN2
>>>>>>>>
>>>>>>>> to Angela, the current [i.e. latest, expired] draft seems a bit
>>>>>>>> "funky"
>>>>>>>> to
>>>>>>>> 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
>>>>>>>> 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
>>>>>>>> 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
>>>>>>>> source/destination  would be preserved.  I suspect that much of
>>>>>>>> what I
>>>>>>>> was
>>>>>>>> proposing here involves removing functionality that most
>>>>>>>> developers
>>>>>>>> haven¹t
>>>>>>>> needed to work more like IPsec tunnel-mode endpoints in order to
>>>>>>>> make
>>>>>>>> the
>>>>>>>> HARD, and *then* circling back to see what could be tweaked in the
>>>>>>>> BSP,
>>>>>>>> I
>>>>>>>> From: [email-masked]
>>>>>>>> [[email-masked]] On
>>>>>>>> Behalf
>>>>>>>> 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
>>>>>>>> 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
>>>>>>>>
>>>>>>>> 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
>>>>>>>> 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.
>>>>>>>>
>>>>>>>> deployment of non-BSP-aware routing implementations by enabling
>>>>>>>> them to
>>>>>>>> be
>>>>>>>> 1.       Eliminate security sources and security destinations from
>>>>>>>> all
>>>>>>>> BSP
>>>>>>>> source.  The security destination of a BSP block would always be
>>>>>>>> the
>>>>>>>> bundle¹s
>>>>>>>> destination.
>>>>>>>>
>>>>>>>> 3.       When additional security must be applied to a bundle on
>>>>>>>> some
>>>>>>>> segment
>>>>>>>> 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
>>>>>>>> encrypt extension blocks as copied from the encapsulated bundle,
>>>>>>>> etc.
>>>>>>>> Then
>>>>>>>> 4.       When route service uncertainty forces a bundle to be
>>>>>>>> routed
>>>>>>>> over
>>>>>>>> encapsulate it as above but within multiple different
>>>>>>>> encapsulating
>>>>>>>> bundles,
>>>>>>>> Record, extract the encapsulated bundle from the Administrative
>>>>>>>> Record
>>>>>>>> and
>>>>>>>> simply forward it.
>>>>>>>>
>>>>>>>> encapsulated bundle encrypts all three at once), so no correlators
>>>>>>>> in
>>>>>>>> BSP.
>>>>>>>> ·         No possible conflict among security destinations of
>>>>>>>> different
>>>>>>>> BSP
>>>>>>>> blocks.
>>>>>>>>
>>>>>>>> routing information at the forwarding node, not into the bundle.
>>>>>>>> (A
>>>>>>>> little
>>>>>>>> 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
>>>>>>>> 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
>>>>>>>> 5.       D realizes that the bundle has to traverse region Y in
>>>>>>>> order to
>>>>>>>> get
>>>>>>>> 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.
>>>>>>>>
>>>>>>>> forwarded.  The routing element at F sees this bundle and forwards
>>>>>>>> it to
>>>>>>>> G.
>>>>>>>>
>>>>>>>> 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
>>>>>>>> forwarded.  The routing element at I sees this bundle and forwards
>>>>>>>> it to
>>>>>>>> J.
>>>>>>>>
>>>>>>>> Subject: Re(19): [dtn-security] Implementing Security Destinations
>>>>>>>> in
>>>>>>>> DTN2
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> to Angela, the current [i.e. latest, expired] draft seems a bit
>>>>>>>> "funky"
>>>>>>>> to
>>>>>>>> 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
>>>>>>>> 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

###################################################
// Double the Pride,Double the Fall //

---

From: Angela Hennessy <[email-masked]>
Date: Tue, 29 Jan 2013 10:34:34 -0500

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