Subject: Re: [dtn-security] Re(4): Including fragment offset in the correlator doesn't prevent all fragment collisions.

From: Elwyn Davies <[email-masked]>
Date: Sat, 13 Apr 2013 19:10:32 +0100

Hi.

It just occurred to me that the way DTN2 handles fragment payloads
probably gets very screwed up if two paths either with different
encrypted security tunnels or with one encrypted and one unencrypted 
converge at some point after fragmentation.  I haven't looked in detail
into the code, but I suspect that there are some cases in which order
of delivery via the two different paths might lead to  the payload
getting a mix of data from the two sources and becoming unintelligible.

Not certaim if I am right, but may be another argument for using b-i-b
encapsulation.

Regards,
Elwyn  

On Mon, 2013-03-25 at 15:58 -0400, Amy Alford wrote:
> 
> 
> On Sat, Mar 23, 2013 at 5:32 PM, Peter Lovell <[email-masked]> wrote:
>         Hi Amy,
>         
>         Amy Alford <[email-masked]> wrote:
>         
>         >Yes, my example was assuming a PIB ciphersuite that used two
>         blocks
>         >(similar to BAB).  That case is the most problematic, because
>         when the
>         >bundle is fragmented, the two blocks will end up in separate
>         fragments.
>         > Otherwise, the correlator collision isn't a problem as long
>         as reassembly
>         >happens at the destination.
>         
>         PIB is, in some ways, a more difficult scenario than PCB. When
>         a bundle with PCB arrives at the security-dest, the payload is
>         decrypted (and other blocks as appropriate) and the PCB itself
>         is deleted. But some folks want to have PIBs remain even after
>         verification, as evidence I guess. That is messy.
> Leaving PIBs on after verification is problematic anyway, if the PIB
> was added after a PCB.  Once the PCB reaches it's security
> destination, the PIB is invalid anyhow.
>  
>         
>         Is there a specific reason for a two-block PIB?
>  
> 6257 mentions the idea of PIB ciphersuites that use a trailing block
> similar to BAB.  I assume you'd still want an up front block to warn
> nodes that are doing one pass processing that they need to start
> hashing.
>  
>         
>         >> As you can see, this is a quite involved process. A couple
>         of things are
>         >> worthy of note:
>         >> 1. correlators are local to their bundle
>         >> 2. a block with a correlator may be encapsulated, with PCB
>         for example.
>         >> The original correlator is hidden until decapsulation
>         occurs (not shown
>         >> above for sake of brevity :)
>         >> 3. reassembly is a very, very complex process.
>         >>
>         >I was pondering how to support these sorts of cases (which
>         end up needing
>         >validation and reassembly interleaved somehow).  In thinking
>         about it, I
>         >started running into scenarios that aren't supportable.  The
>         example I gave
>         >is one (which I think shows that bundles with two block PIBs
>         need to have
>         >the do not fragment flag set).  
>         It may be sufficient to apply the
>         replicate-key-info-in-every-block rule. I don't know without
>         thinking about it some more.
> 
> 
> I think it would fix the example I gave.  The last fragment would
> contain both the leading and trailing PIB blocks.  The leading block
> could be used to match this up with the corresponding fragment (which
> also has a leading PIB block but is missing the trailing one).  It
> would be a pain in terms of processing, since defragmentation would
> need to match up the corresponding fragments by comparing their
> leading PIB blocks.
> 
> 
>  
>         
>         >Additionally, in general, if an intermediate node reassembles
>         fragments
>         >that have had BSP blocks added after fragmentation, we can't
>         validate.  Too
>         >much information is lost on reassembly (even if it's done
>         sensibly).  5050
>         >allows intermediate nodes to reassemble, but doesn't mandate
>         a procedure
>         >for reassembling the extension blocks (so it may not be done
>         sensibly).
>         
>         It's not just an issue of reassembling/reordering extension
>         blocks. As the final example shows, any attempt to
>         reassemble-first is doomed to failure because the two parts
>         were encrypted under different second-stage keys.
>         
>         It's clear to me that reassembly of bundles containing
>         security blocks must be done in concert with security
>         processing. This needs to be incorporated into any update to
>         5050. And, as you say, there are cases that aren't supportable
>         with the capabilities we now have.
>  
> Yes.  In general, nodes shouldn't reassemble a bundle if they don't
> understand all the extension blocks.  BSP aware nodes shouldn't
> reassemble fragments except in concert with security processing.
> 
> 
>  
>         
>         Regards.....Peter
>         
> 
> _______________________________________________
> dtn-security mailing list
> [email-masked]
> https://www.irtf.org/mailman/listinfo/dtn-security

---

From: Amy Alford <[email-masked]>
Date: Sat, 13 Apr 2013 18:12:38 -0400

If you think about a "fragmentation path" similar to a security path,
whenever fragmentation paths and security paths overlap (instead of one
nesting inside the other), Bad Things (TM) are probably going to happen in
DTN2.

If it's fragment -> add bsp -> defragment -> remove bsp, you're up against
the fact that defragmentation doesn't necessarily preserve enough info to
validate the BSP blocks.  Even if it does, DTN2 currently doesn't recognize
that a set of valid BSP blocks that cover the payload are enough to satisfy
policy requirements.

If it's add bsp -> fragment -> remove bsp -> defragment, you're obviously
sunk because you can't validate the BSP blocks which apply to the whole
payload when you only have a fragment.  In this case, you obviously need to
reconstitute the bundle before you remove the BSP blocks.

This doesn't even touch the headaches involved with multiple BSP instances
and multiple fragmentation.

BiB will need to deal with the second case (the easy one - DTN2 will
probably handle this with no changes), but avoids the first case because an
encapsulated fragment is not itself a fragment (so it can't be
reconstituted until after it's been decapsulated).

The new BSP draft may not sidestep these problems though, because it still
allows security sources and hop-by-hop ciphersuites still need to be able
to handle non-security-aware nodes in the middle.

---

From: "Burleigh, Scott C (313B)" <[email-masked]>
Date: Sun, 14 Apr 2013 00:25:03 +0000

Amy, I certainly agree on the potential for Bad Things happening when fragmentation and security aren't cleanly nested.  Can you say a little more about how the proposed new BSP draft's support for security sources could expose nodes to these problems?

Scott
________________________________
From: [email-masked] [[email-masked]] on behalf of Amy Alford [[email-masked]]
Sent: Saturday, April 13, 2013 3:12 PM
To: Elwyn Davies
Cc: dtn-security
Subject: Re: [dtn-security] Re(4): Including fragment offset in the correlator doesn't prevent all fragment collisions.

If you think about a "fragmentation path" similar to a security path, whenever fragmentation paths and security paths overlap (instead of one nesting inside the other), Bad Things (TM) are probably going to happen in DTN2.

If it's fragment -> add bsp -> defragment -> remove bsp, you're up against the fact that defragmentation doesn't necessarily preserve enough info to validate the BSP blocks.  Even if it does, DTN2 currently doesn't recognize that a set of valid BSP blocks that cover the payload are enough to satisfy policy requirements.

If it's add bsp -> fragment -> remove bsp -> defragment, you're obviously sunk because you can't validate the BSP blocks which apply to the whole payload when you only have a fragment.  In this case, you obviously need to reconstitute the bundle before you remove the BSP blocks.

This doesn't even touch the headaches involved with multiple BSP instances and multiple fragmentation.

BiB will need to deal with the second case (the easy one - DTN2 will probably handle this with no changes), but avoids the first case because an encapsulated fragment is not itself a fragment (so it can't be reconstituted until after it's been decapsulated).

The new BSP draft may not sidestep these problems though, because it still allows security sources and hop-by-hop ciphersuites still need to be able to handle non-security-aware nodes in the middle.

On Sat, Apr 13, 2013 at 2:10 PM, Elwyn Davies <[email-masked]<mailto:[email-masked]>> wrote:
Hi.

Regards,
Elwyn

On Mon, 2013-03-25 at 15:58 -0400, Amy Alford wrote:
>
>
> On Sat, Mar 23, 2013 at 5:32 PM, Peter Lovell <[email-masked]<mailto:[email-masked]>> wrote:
>         Hi Amy,
>
>         Amy Alford <[email-masked]<mailto:[email-masked]>> wrote:
>
> [email-masked]<mailto:[email-masked]>

---

From: Amy Alford <[email-masked]>
Date: Sun, 14 Apr 2013 16:50:43 -0400

5050 allows any node to reassemble fragments.  So, if fragmentation occurs
before security blocks are added, any subsequent node may then reassemble
the bundle.

Additionally, hop-by-hop ciphersuites may have intermediate non-security
aware nodes.  These can potentially fragment/reassemble, creating the same
overlapping fragmentation path/security path scenarios.

The example I sent out earlier in response to Peter Lovell is still a
possibility if you have a PIB ciphersuite that uses two blocks (one before
the payload and one after).  BIBE does mitigate this, since we can use the
"DO_NOT_FRAGMENT" flag whenever we add a two block PIB, and then
encapsulate.  Once we've encapsulated, we can fragment again.

There's a problem with enforcing the one logical security block of each
type/target per bundle rule if a bundle is reassembled by an intermediate
node. Security blocks may have been applied to different fragments which
are then recombined in such a way that there is more than one logical
security block of the same type/target.  These may apply to overlapping
payload regions, or even the same payload region (depending on how the
recombining node handles receiving duplicate fragments over different
links).

These are the cases I've thought of.  I'm nervous that there's enough
complexity in the intersection of fragmentation/encapsulation/BSP that it's
hard to be confident that all the possible combinations will work correctly.

- Amy

On Sat, Apr 13, 2013 at 8:25 PM, Burleigh, Scott C (313B) <
[email-masked]> wrote:

>  Amy, I certainly agree on the potential for Bad Things happening when
> fragmentation and security aren't cleanly nested.  Can you say a little
> more about how the proposed new BSP draft's support for security sources
> could expose nodes to these problems?
>
>  Scott
>  ------------------------------
> *From:* [email-masked] [[email-masked]] on
> behalf of Amy Alford [[email-masked]]
> *Sent:* Saturday, April 13, 2013 3:12 PM
> *To:* Elwyn Davies
> *Cc:* dtn-security
> *Subject:* Re: [dtn-security] Re(4): Including fragment offset in the
> correlator doesn't prevent all fragment collisions.
>
>  If it's add bsp -> fragment -> remove bsp -> defragment, you're
> obviously sunk because you can't validate the BSP blocks which apply to the
> whole payload when you only have a fragment.  In this case, you obviously
> need to reconstitute the bundle before you remove the BSP blocks.
>
>  The new BSP draft may not sidestep these problems though, because it
> still allows security sources and hop-by-hop ciphersuites still need to be
> able to handle non-security-aware nodes in the middle.
>
>
>
>

---

From: "Burleigh, Scott C (313B)" <[email-masked]>
Date: Mon, 15 Apr 2013 09:16:25 +0000

Okay, this may or may not be optimal, but here's how I think the proposed new BSP concepts might handle the fragmentation/security combinations:

  *   The key rule we're working with is that you can never have more than one occurrence of any single security activity (logical block, device, structure -- essentially, either a single physical block or two cooperating physical blocks) in any bundle bundle.
  *   This implies that no ciphersuite or policy can require that a PIB or PCB be added to a bundle that is a fragment (that is, a bundle whose payload is a fragment of the payload of some original bundle with the same ID).  That's because the 5050 fragmentation rules require that any extension block that precedes the payload of a bundle that is to be fragmented must be preserved in the FIRST resulting fragment.  That means that it is always possible for a fragment to contain a payload BIB or BCB that pertains to the original bundle -- not to itself -- and therefore in at least one case the addition of a fragment payload BIB would result in the bundle having two payload BIBs, a violation.
  *   Therefore, in the event that you want to protect a fragmentary payload with a BIB or BCB, the only way to do so is to encapsulate the fragment bundle in an encapsulating, non-fragmentary bundle whose payload contains the fragment -- and then attach a payload BIB and/or BCB that protects the encapsulating bundle's payload.
  *   So if fragmentation occurs and you then want to add security blocks, the blocks will be added to encapsulating -- hence non-fragmentary -- bundles.  So in order for reassembly to happen, all of the bundles encapsulating the fragments need to be received at the same node.  That node then necessarily has to be able to extract the fragment bundles from the payloads of the encapsulating bundles, and at that point you've got the pre-security fragments; reassembling the original bundle payload from those fragments should be straightforward.
  *   Since there are no security destinations in the proposed simplified BSP spec, (a) the only hop-by-hop ciphersuites are the ones for BABs and (b) it would be a configuration nightmare (though not impossible, I guess) to have any non-BAB-capable nodes interposed between two nodes that are BAB neighbors.  If you do have a topology where you need any sort of hop-by-hop security association other than adjacency, then you encapsulate; the destination of the encapsulating bundle is the intended "next hop" destination, and now you're back in a non-problematic topology.

I think the same principles address the other cases you identify.

I'll admit that all of this encapsulation does seem a little heavyweight, but in its defense I would argue that:

  *   It's a simple mechanism that handles an unlimited range of cases (including, I think, cases that nobody has thought of yet) in a common, understandable way that is completely compatible with RFC 5050.
  *   The overhead of the extra primary block for the encapsulating bundle can be kept pretty low if you're using CBHE.
  *   The cases we're talking about are entirely plausible for some operational environments, but for the bulk of secure DTN communications activity I think they are not  likely.  It makes more sense, to me, to optimize overhead for the common case so long as there's still a way to support all of the more complex cases.

Scott
________________________________
From: Amy Alford [[email-masked]]
Sent: Sunday, April 14, 2013 1:50 PM
To: Burleigh, Scott C (313B)
Cc: Elwyn Davies; dtn-security
Subject: Re: [dtn-security] Re(4): Including fragment offset in the correlator doesn't prevent all fragment collisions.

5050 allows any node to reassemble fragments.  So, if fragmentation occurs before security blocks are added, any subsequent node may then reassemble the bundle.

Additionally, hop-by-hop ciphersuites may have intermediate non-security aware nodes.  These can potentially fragment/reassemble, creating the same overlapping fragmentation path/security path scenarios.

The example I sent out earlier in response to Peter Lovell is still a possibility if you have a PIB ciphersuite that uses two blocks (one before the payload and one after).  BIBE does mitigate this, since we can use the "DO_NOT_FRAGMENT" flag whenever we add a two block PIB, and then encapsulate.  Once we've encapsulated, we can fragment again.

There's a problem with enforcing the one logical security block of each type/target per bundle rule if a bundle is reassembled by an intermediate node. Security blocks may have been applied to different fragments which are then recombined in such a way that there is more than one logical security block of the same type/target.  These may apply to overlapping payload regions, or even the same payload region (depending on how the recombining node handles receiving duplicate fragments over different links).

These are the cases I've thought of.  I'm nervous that there's enough complexity in the intersection of fragmentation/encapsulation/BSP that it's hard to be confident that all the possible combinations will work correctly.

- Amy

On Sat, Apr 13, 2013 at 8:25 PM, Burleigh, Scott C (313B) <[email-masked]<mailto:[email-masked]>> wrote:
Amy, I certainly agree on the potential for Bad Things happening when fragmentation and security aren't cleanly nested.  Can you say a little more about how the proposed new BSP draft's support for security sources could expose nodes to these problems?

Scott
________________________________
From: [email-masked]<mailto:[email-masked]> [[email-masked]<mailto:[email-masked]>] on behalf of Amy Alford [[email-masked]<mailto:[email-masked]>]
Sent: Saturday, April 13, 2013 3:12 PM
To: Elwyn Davies
Cc: dtn-security
Subject: Re: [dtn-security] Re(4): Including fragment offset in the correlator doesn't prevent all fragment collisions.

Regards,
Elwyn

---

From: <[email-masked]>
Date: Tue, 16 Apr 2013 11:26:25 +0100

You're going to need to pursue this fragment-in-bundle and bundle-in-bundle nesting. 

As well as simplifying the handling, this encapsulation can also solve the reliability problem - outer bundle with reliability check (widely known key) that can be verified at each hop, inner bundle with secured contents readable only by destination. Just like an IPsec EH packet in an Ethernet frame with CRC that is checked by all switches...

Dumping the fragment in a bundle for further transport discourages simply dropping fragments. Though the eventual reassembly and recursive patching together of bundles of fragmented bundles of fragments of... could be interesting and processor-intensive, and identifying fragments that can be reassembled before the destination at an intermediate node is likely a lost cause.

Encapsulation is the only behaviour that is sane, tractable, and debuggable.

Lloyd Wood
http://sat-net.com/L.Wood/dtn/

________________________________________
From: [email-masked] [[email-masked]] On Behalf Of Burleigh, Scott C (313B) [[email-masked]]
Sent: 15 April 2013 10:16
To: Amy Alford
Cc: dtn-security
Subject: Re: [dtn-security] Re(4): Including fragment offset in the correlator doesn't prevent all fragment collisions.

Scott

- Amy

Scott

Regards,
Elwyn

---

From: Amy Alford <[email-masked]>
Date: Tue, 16 Apr 2013 20:54:13 -0400

I like the simplicity of this, but it brings up a concern I had with
encapsulation.  What happens to extension blocks attached to the
encapsulating bundle on decapsulation?  If they are simply thrown out, the
age extension blocks aren't going to work.  If we keep them around somehow,
then we lose the simplicity of this approach.
- Amy

On Mon, Apr 15, 2013 at 5:16 AM, Burleigh, Scott C (313B) <
[email-masked]> wrote:

>  Okay, this may or may not be optimal, but here's how I think the
> proposed new BSP concepts might handle the fragmentation/security
> combinations:
>
>    - The key rule we're working with is that you can never have more than one
>    occurrence of any single security activity (logical block, device,
>    structure -- essentially, either a single physical block or two cooperating
>    physical blocks) in any bundle bundle.
>    - This implies that no ciphersuite or policy can require that a PIB or
>    PCB be added to a bundle that is a fragment (that is, a bundle whose
>    payload is a fragment of the payload of some original bundle with the same
>    ID).  That's because the 5050 fragmentation rules require that any
>    extension block that precedes the payload of a bundle that is to be
>    fragmented must be preserved in the FIRST resulting fragment.  That means
>    that it is always possible for a fragment to contain a payload BIB or BCB
>    that pertains to the original bundle -- not to itself -- and therefore in
>    at least one case the addition of a fragment payload BIB would result in
>    the bundle having two payload BIBs, a violation.
>    - Therefore, in the event that you want to protect a fragmentary
>    payload with a BIB or BCB, the only way to do so is to encapsulate the
>    fragment bundle in an encapsulating, non-fragmentary bundle whose payload
>    contains the fragment -- and then attach a payload BIB and/or BCB that
>    protects the encapsulating bundle's payload.
>    - So if fragmentation occurs and you then want to add security blocks,
>    the blocks will be added to encapsulating -- hence non-fragmentary --
>    bundles.  So in order for reassembly to happen, all of the bundles
>    encapsulating the fragments need to be received at the same node.  That
>    node then necessarily has to be able to extract the fragment bundles from
>    the payloads of the encapsulating bundles, and at that point you've got the
>    pre-security fragments; reassembling the original bundle payload from those
>    fragments should be straightforward.
>    - Since there are no security destinations in the proposed simplified
>    BSP spec, (a) the only hop-by-hop ciphersuites are the ones for BABs and
>    (b) it would be a configuration nightmare (though not impossible, I guess)
>    to have any non-BAB-capable nodes interposed between two nodes that are BAB
>    neighbors.  If you do have a topology where you need any sort of hop-by-hop
>    security association other than adjacency, then you encapsulate; the
>    destination of the encapsulating bundle is the intended "next hop"
>    destination, and now you're back in a non-problematic topology.
>
>  I'll admit that all of this encapsulation does seem a little
> heavyweight, but in its defense I would argue that:
>
>    - It's a simple mechanism that handles an unlimited range of cases
>    (including, I think, cases that nobody has thought of yet) in a common,
>    understandable way that is completely compatible with RFC 5050.
>    - The overhead of the extra primary block for the encapsulating bundle
>    can be kept pretty low if you're using CBHE.
>    - The cases we're talking about are entirely plausible for some
>    operational environments, but for the bulk of secure DTN communications
>    activity I think they are not  likely.  It makes more sense, to me, to
>    optimize overhead for the common case so long as there's still a way to
>    support all of the more complex cases.
>
>  Scott
> *From:* Amy Alford [[email-masked]]
> *Sent:* Sunday, April 14, 2013 1:50 PM
> *To:* Burleigh, Scott C (313B)
> *Cc:* Elwyn Davies; dtn-security
>
>   5050 allows any node to reassemble fragments.  So, if fragmentation
> occurs before security blocks are added, any subsequent node may then
> reassemble the bundle.
>
>> If it's fragment -> add bsp -> defragment -> remove bsp, you're up
>> against the fact that defragmentation doesn't necessarily preserve enough
>> info to validate the BSP blocks.  Even if it does, DTN2 currently doesn't
>> recognize that a set of valid BSP blocks that cover the payload are enough
>> to satisfy policy requirements.
>>
>> On Sat, Apr 13, 2013 at 2:10 PM, Elwyn Davies <[email-masked]>wrote:
>>
>>> Hi.
>>>

---

From: "Burleigh, Scott C (313B)" <[email-masked]>
Date: Wed, 17 Apr 2013 02:44:03 +0000

I may be wrong, but I think the age extension blocks can still work, just because BIBE is a CLA.  On output via BIBE you'd update the encapsulated bundle's age extension block just as if you were sending via TCP, and likewise on "reception"/extraction.  Sure, the encapsulated bundle might expire en route (before extraction) but that's probably no great problem.  You might use its remaining time to live as the TTL for the encapsulating bundle to guard against this.  But overall I think it works; am I overlooking something? 

Scott
Sent: Tuesday, April 16, 2013 5:54 PM

I like the simplicity of this, but it brings up a concern I had with encapsulation.  What happens to extension blocks attached to the encapsulating bundle on decapsulation?  If they are simply thrown out, the age extension blocks aren't going to work.  If we keep them around somehow, then we lose the simplicity of this approach.
- Amy

On Mon, Apr 15, 2013 at 5:16 AM, Burleigh, Scott C (313B) <[email-masked]<mailto:[email-masked]>> wrote:
Okay, this may or may not be optimal, but here's how I think the proposed new BSP concepts might handle the fragmentation/security combinations:

Scott
From: Amy Alford [[email-masked]<mailto:[email-masked]>]

- Amy

Scott

Regards,
Elwyn

---

From: "Burleigh, Scott C (313B)" <[email-masked]>
Date: Wed, 17 Apr 2013 09:54:19 +0000

Thanks, Lloyd, I'm glad we agree on this.  And I think you're right, the "outer packet" mechanism might well make integrity checking more straightforward throughout.

Scott
________________________________________
From: [email-masked] [[email-masked]]
Sent: Tuesday, April 16, 2013 3:26 AM
To: Burleigh, Scott C (313B); [email-masked]
Cc: [email-masked]
Subject: RE: [dtn-security] Re(4): Including fragment offset in the correlator doesn't prevent all fragment collisions.

Lloyd Wood

Scott

- Amy

Scott

Regards,
Elwyn

---

From: Amy Alford <[email-masked]>
Date: Wed, 17 Apr 2013 14:49:56 -0400

Ok, I hadn't read the age block spec before now. The spec says CLA's should
provide BPAs with information to use in updating the age block.  So, you're
saying that BIBE is a CLA, so it should pass along info about how long the
encapsulated bundle was in transit.  It would get that information from
either the creation timestamp on the encapsulating bundle or the age block
attached to the encapsulating bundle.

That makes sense.  Are there any other extension blocks that may be added
to an encapsulating bundle that it would be a problem to just throw out?
- Amy

On Tue, Apr 16, 2013 at 10:44 PM, Burleigh, Scott C (313B) <
[email-masked]> wrote:

> I may be wrong, but I think the age extension blocks can still work, just
> because BIBE is a CLA.  On output via BIBE you'd update the encapsulated
> bundle's age extension block just as if you were sending via TCP, and
> likewise on "reception"/extraction.  Sure, the encapsulated bundle might
> expire en route (before extraction) but that's probably no great problem.
>  You might use its remaining time to live as the TTL for the encapsulating
> bundle to guard against this.  But overall I think it works; am I
> overlooking something?
>
> Scott
> Subject: Re: [dtn-security] Re(4): Including fragment offset in the
> [email-masked]<mailto:[email-masked]>>
> wrote:
> Okay, this may or may not be optimal, but here's how I think the proposed
> new BSP concepts might handle the fragmentation/security combinations:
>
>   *   The key rule we're working with is that you can never have more than
> one occurrence of any single security activity (logical block, device,
>   *   This implies that no ciphersuite or policy can require that a PIB or
>   *   Therefore, in the event that you want to protect a fragmentary
>   *   So if fragmentation occurs and you then want to add security blocks,
>   *   Since there are no security destinations in the proposed simplified
>   *   It's a simple mechanism that handles an unlimited range of cases
>   *   The overhead of the extra primary block for the encapsulating bundle
>   *   The cases we're talking about are entirely plausible for some
> Subject: Re: [dtn-security] Re(4): Including fragment offset in the
> [email-masked]<mailto:[email-masked]>>
> wrote:
> From: [email-masked]<mailto:[email-masked]>
> [[email-masked]<mailto:[email-masked]>] on
> behalf of Amy Alford [[email-masked]<mailto:[email-masked]>]
> Subject: Re: [dtn-security] Re(4): Including fragment offset in the

---

From: "Burleigh, Scott C (313B)" <[email-masked]>
Date: Wed, 17 Apr 2013 22:16:08 +0000

I don't know of any other extension blocks that would be added to an encapsulating bundle that ought to affect the forwarding of the encapsulated (when extracted) -- again, BIBE is acting as a CLA, and we don't normally care much about what happens to CL protocol PDUs.  But maybe somebody else knows of something I'm missing.

Scott
Sent: Wednesday, April 17, 2013 11:49 AM

Ok, I hadn't read the age block spec before now. The spec says CLA's should provide BPAs with information to use in updating the age block.  So, you're saying that BIBE is a CLA, so it should pass along info about how long the encapsulated bundle was in transit.  It would get that information from either the creation timestamp on the encapsulating bundle or the age block attached to the encapsulating bundle.

That makes sense.  Are there any other extension blocks that may be added to an encapsulating bundle that it would be a problem to just throw out?
- Amy

On Tue, Apr 16, 2013 at 10:44 PM, Burleigh, Scott C (313B) <[email-masked]<mailto:[email-masked]>> wrote:
I may be wrong, but I think the age extension blocks can still work, just because BIBE is a CLA.  On output via BIBE you'd update the encapsulated bundle's age extension block just as if you were sending via TCP, and likewise on "reception"/extraction.  Sure, the encapsulated bundle might expire en route (before extraction) but that's probably no great problem.  You might use its remaining time to live as the TTL for the encapsulating bundle to guard against this.  But overall I think it works; am I overlooking something?

Scott

On Mon, Apr 15, 2013 at 5:16 AM, Burleigh, Scott C (313B) <[email-masked]<mailto:[email-masked]><mailto:[email-masked]<mailto:[email-masked]>>> wrote:
Okay, this may or may not be optimal, but here's how I think the proposed new BSP concepts might handle the fragmentation/security combinations:

Scott
From: Amy Alford [[email-masked]<mailto:[email-masked]><mailto:[email-masked]<mailto:[email-masked]>>]

- Amy

On Sat, Apr 13, 2013 at 8:25 PM, Burleigh, Scott C (313B) <[email-masked]<mailto:[email-masked]><mailto:[email-masked]<mailto:[email-masked]>>> wrote:
Amy, I certainly agree on the potential for Bad Things happening when fragmentation and security aren't cleanly nested.  Can you say a little more about how the proposed new BSP draft's support for security sources could expose nodes to these problems?

Scott
________________________________
From: [email-masked]<mailto:[email-masked]><mailto:[email-masked]<mailto:[email-masked]>> [[email-masked]<mailto:[email-masked]><mailto:[email-masked]<mailto:[email-masked]>>] on behalf of Amy Alford [[email-masked]<mailto:[email-masked]><mailto:[email-masked]<mailto:[email-masked]>>]
Sent: Saturday, April 13, 2013 3:12 PM
To: Elwyn Davies
Cc: dtn-security
Subject: Re: [dtn-security] Re(4): Including fragment offset in the correlator doesn't prevent all fragment collisions.

On Sat, Apr 13, 2013 at 2:10 PM, Elwyn Davies <[email-masked]<mailto:[email-masked]><mailto:[email-masked]<mailto:[email-masked]>>> wrote:
Hi.

Regards,
Elwyn

On Mon, 2013-03-25 at 15:58 -0400, Amy Alford wrote:
>
>
> On Sat, Mar 23, 2013 at 5:32 PM, Peter Lovell <[email-masked]<mailto:[email-masked]><mailto:[email-masked]<mailto:[email-masked]>>> wrote:
>         Hi Amy,
>
>         Amy Alford <[email-masked]<mailto:[email-masked]><mailto:[email-masked]<mailto:[email-masked]>>> wrote:
>
> [email-masked]<mailto:[email-masked]><mailto:[email-masked]<mailto:[email-masked]>>