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

["Ivancic, William D. (GRC-RHN0)" <[e-mail]>]

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 [phone]
Fax [phone]
Networking Lab 216-433-2620
Mobile [phone]
http://roland.grc.nasa.gov/~ivancic



> From: Angela Hennessy <[e-mail]>
> Date: Mon, 28 Jan 2013 13:25:39 -0600
> To: "Ivancic, William D. (GRC-RHN0)" <[e-mail]>
> Cc: "[e-mail]" <[e-mail]>
> 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)
> <[e-mail]> 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 [phone]
>> Fax [phone]
>> Networking Lab 216-433-2620
>> Mobile [phone]
>> http://roland.grc.nasa.gov/~ivancic
>>
>>
>>
>>> From: Angela Hennessy <[e-mail]>
>>> Date: Sun, 27 Jan 2013 15:42:18 -0600
>>> To: "[e-mail]" <[e-mail]>
>>> 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,  <[e-mail]> 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
>>>>         [e-mail]
>>>>
>>>> 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
>>>>         [e-mail]
>>>>
>>>> You can reach the person managing the list at
>>>>         [e-mail]
>>>>
>>>> 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 <[e-mail]>
>>>> To: "Birrane, Edward J." <[e-mail]>
>>>> Cc: "[e-mail]" <[e-mail]>
>>>> 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." <[e-mail]>
>>>> 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, "[e-mail]" <[e-mail]> 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,  <[e-mail]> 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
>>>>>>>        [e-mail]
>>>>>>>
>>>>>>> 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
>>>>>>>        [e-mail]
>>>>>>>
>>>>>>> You can reach the person managing the list at
>>>>>>>        [e-mail]
>>>>>>>
>>>>>>> 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.]"
>>>>>>> <[e-mail]>
>>>>>>> To: "Burleigh, Scott C" <[e-mail]>ov>,
>>>>>>> "[e-mail]" <[e-mail]>
>>>>>>> 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: [e-mail] [[e-mail]] On
>>>>>>> Behalf
>>>>>>> Of Burleigh, Scott C (313B) [[e-mail]]
>>>>>>> Sent: Tuesday, January 22, 2013 5:37 PM
>>>>>>> To: [e-mail]
>>>>>>> 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'; [e-mail]
>>>>>>> Cc: Amy Alford; [e-mail]; 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:[e-mail]]
>>>>>>> Sent: Monday, October 22, 2012 1:28 PM
>>>>>>> To: Burleigh, Scott C (313B); [e-mail]
>>>>>>> Cc: Amy Alford; [e-mail]; Howard Weiss; Peter Lovell
>>>>>>> Subject: Re(19): [dtn-security] Implementing Security Destinations in
>>>>>>> DTN2
>>>>>>>
>>>>>>> On Wed, Oct 24, 2012, Burleigh, Scott C (313B)
>>>>>>> <[e-mail]> 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.]"
>>>>>>> <[e-mail]>
>>>>>>> To: "Burleigh, Scott C" <[e-mail]>ov>,
>>>>>>> "[e-mail]" <[e-mail]>
>>>>>>> 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) [[e-mail]]
>>>>>>> Sent: Tuesday, January 22, 2013 6:35 PM
>>>>>>> To: Eddy, Wesley M. (GRC-MS00)[MTI SYSTEMS, INC.]; [e-mail]
>>>>>>> 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:[e-mail]]
>>>>>>> Sent: Tuesday, January 22, 2013 3:20 PM
>>>>>>> To: Burleigh, Scott C (313B); [e-mail]
>>>>>>> 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: [e-mail] [[e-mail]] On
>>>>>>> Behalf
>>>>>>> Of Burleigh, Scott C (313B) [[e-mail]]
>>>>>>> Sent: Tuesday, January 22, 2013 5:37 PM
>>>>>>> To: [e-mail]
>>>>>>> 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'; [e-mail]
>>>>>>> Cc: Amy Alford; [e-mail]; 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:[e-mail]]
>>>>>>> Sent: Monday, October 22, 2012 1:28 PM
>>>>>>> To: Burleigh, Scott C (313B); [e-mail]
>>>>>>> Cc: Amy Alford; [e-mail]; Howard Weiss; Peter Lovell
>>>>>>> Subject: Re(19): [dtn-security] Implementing Security Destinations in
>>>>>>> DTN2
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On Wed, Oct 24, 2012, Burleigh, Scott C (313B)
>>>>>>> <[e-mail]> 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
>>>>>>> [e-mail]
>>>>>>> https://www.irtf.org/mailman/listinfo/dtn-security
>>>>>> _______________________________________________
>>>>>> dtn-security mailing list
>>>>>> [e-mail]
>>>>>> https://www.irtf.org/mailman/listinfo/dtn-security
>>>>>
>>>>> _______________________________________________
>>>>> dtn-security mailing list
>>>>> [e-mail]
>>>>> https://www.irtf.org/mailman/listinfo/dtn-security
>>>>
>>>>
>>>> _______________________________________________
>>>> dtn-security mailing list
>>>> [e-mail]
>>>> https://www.irtf.org/mailman/listinfo/dtn-security
>>>>
>>> _______________________________________________
>>> dtn-security mailing list
>>> [e-mail]
>>> https://www.irtf.org/mailman/listinfo/dtn-security
>>