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

[[e-mail]]

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.


> 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]>,
>>>>>>>> "[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]>,
>>>>>>>> "[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
>>>
>
> _______________________________________________
> dtn-security mailing list
> [e-mail]
> https://www.irtf.org/mailman/listinfo/dtn-security
>


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