Subject: [dtn] BPSec and bundle fragmentation

From: Brian Sipos <[email-masked]>
Date: Mon, 1 Feb 2021 22:05:43 +0000

All,
There seems to be a slight hole in the relationship between BPSec and BPbis related to a bundle with BCB(s) on extension
blocks which is then fragmented. If a BCB has a target of an extension block it will alter the block type-specific data
so it's no longer decodable as normal. The requirements in BPbis [1] Section 5.8 "Bundle Fragmentation" require
replicating extension blocks with flag indicating to do so. The trouble is that if a BCB-modified block is replicated in
the fragment a receiver of the non-initial fragment has no way to know the block is BCB-targeted. The requirements in
BPSec [2] section 5.2 "Bundle Fragmentation and Reassembly" indicate that the BIB must be replicated only if the target
is a payload block, but really should replicate if the target is either the payload or any extension block with "block
must be replicated in every fragment" flag set.

As an aside, I don't see what the value is in replicating the BIB when the target is the fragmented payload unless there
is an expectation that a payload fragment will be inspected by a node. I suppose that this is just playing safe sice
BPv7 doesn't explicitly prohibit any node from inspecting payload fragment data.

[1] https://tools.ietf.org/html/draft-ietf-dtn-bpbis-31
[2] https://tools.ietf.org/html/draft-ietf-dtn-bpsec-26

---

From: "Birrane, Edward J." <[email-masked]>
Date: Tue, 2 Feb 2021 01:15:21 +0000

Brian,

  I don't think that security on a bundle translates into security on a fragment of that bundle - even with respect to extension blocks.

  Consider a BIB which cryptographically binds a target block to a bundle by concatenating the primary block of the bundle with the type-specific-data of the target when calculating the plain text input to an integrity mechanism. In this circumstance, you will always fail to verify that BIB if the original bundle is ever fragmented, even if both the target and the BIB blocks appear in the same fragment.  This is because a bundle representing a fragment is a different entity than the original bundle and has a different primary block (https://tools.ietf.org/html/draft-ietf-dtn-bpbis-31#section-5.8). 

  There are a host of potential issues with interpreting security over a fragment.  You could overwhelm a small MTU with mandatory extension blocks. Alternatively, if an extension block is replicated in every fragment and you copy a security block in every fragment, and some fragments verify that target and other fragments do not verify the target, how to you perform bundle re-assembly?

  Because a fragment is not the same as the original bundle, any security services inserted on a bundle but run on a fragment of the bundle may fail - which is exactly what should happen because security was on the bundle and the bundle does not exist in the same form after it has been fragmented. 

  It is possible that (in some very constrained networking cases) security acceptors could be known to exist *after* bundle re-assembly points (such as the bundle destination).  More generally, if a BPA needs to fragment a bundle that includes security blocks, some other mechanism should be used to handle this circumstance. The one that comes to mind is to encapsulate the bundle first, and then fragment the encapsulating bundle and re-assemble at its next bundle hop with something like Bundle-in-Bundle Encapsulation.

-Ed

---
Edward J. Birrane, III, Ph.D.
Embedded Applications Group Supervisor
Space Exploration Sector
Johns Hopkins Applied Physics Laboratory
(W) 443-778-7423 / (F) 443-228-3839

> -----Original Message-----
> From: Brian Sipos <[email-masked]>
> Sent: Monday, February 01, 2021 5:06 PM
> To: [email-masked]
> Cc: Birrane, Edward J. <[email-masked]>
> Subject: [EXT] BPSec and bundle fragmentation
> 
> APL external email warning: Verify sender [email-masked] before
> clicking links or attachments
> 
> All,
> There seems to be a slight hole in the relationship between BPSec and BPbis
> related to a bundle with BCB(s) on extension blocks which is then
> fragmented. If a BCB has a target of an extension block it will alter the block
> type-specific data so it's no longer decodable as normal. The requirements in
> BPbis [1] Section 5.8 "Bundle Fragmentation" require replicating extension
> blocks with flag indicating to do so. The trouble is that if a BCB-modified block
> is replicated in the fragment a receiver of the non-initial fragment has no way
> to know the block is BCB-targeted. The requirements in BPSec [2] section 5.2
> "Bundle Fragmentation and Reassembly" indicate that the BIB must be
> replicated only if the target is a payload block, but really should replicate if
> the target is either the payload or any extension block with "block must be
> replicated in every fragment" flag set.
> 
> As an aside, I don't see what the value is in replicating the BIB when the
> target is the fragmented payload unless there is an expectation that a
> payload fragment will be inspected by a node. I suppose that this is just
> playing safe sice

---

From: Brian Sipos <[email-masked]>
Date: Tue, 2 Feb 2021 03:38:06 +0000

Ed,
The issue that I ran into, was really the opposite of the need to decrypt/verify anything. It was creating a valid (according to current requirements) bundle which a receiver would not be able to properly handle.

I had a large bundle to which I applied BCB (okay) to an extension marked "replicate in fragments", a node then fragmented that bundle (okay: first fragment contains encrypted block and BCB, second contains just the replicated block). The problem then becomes that some other node processing the second fragment has no way to know not to decode the type-specific data of the encrypted extension block.  Presumably the reason for having the blocks replicated is that a node should decode and use the block data to inform its processing.

I can see a few solutions, some better than others:

  1.  A node must ignore any replicated extension blocks in fragment bundles (not a good situation, what is the point of replicating blocks then?)
  2.  A node must not fragment a bundle with any BCB targeting an extension block marked "replicate in fragments", or must ignore the block flag (not good because the whole point of fragmenting is to reduce the bundle size for transport)
  3.  Disallow BCB targeting an extension block marked "replicate in fragments" (seems okay though restrictive)
  4.  Require that any BCB targeting such an extension block also be marked "replicate in fragments"

Currently none of these are actual requirements on a node, so it leaves them open to getting into some not-interoperable situations (like what I ran into). The receiving node needs some guarantees about what it can decode.

And I agree that the better solution is to fragment the whole bundle as an opaque byte string (either by BIBE or via CL fragmentation). I just ran into this when trying to figure out what could be done within the letter of the law.
________________________________
From: Birrane, Edward J. <[email-masked]>
Sent: Monday, February 1, 2021 20:15
To: Brian Sipos <[email-masked]>; [email-masked] <[email-masked]>
Subject: RE: BPSec and bundle fragmentation

Brian,

  Consider a BIB which cryptographically binds a target block to a bundle by concatenating the primary block of the bundle with the type-specific-data of the target when calculating the plain text input to an integrity mechanism. In this circumstance, you will always fail to verify that BIB if the original bundle is ever fragmented, even if both the target and the BIB blocks appear in the same fragment.  This is because a bundle representing a fragment is a different entity than the original bundle and has a different primary block (https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-ietf-dtn-bpbis-31%23section-5.8&amp;data=04%7C01%7CBSipos%40rkf-eng.com%7C91dd4d5401e34e659dc008d8c718064c%7C4ed8b15b911f42bc8524d89148858535%7C1%7C0%7C637478253307478566%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=eEVzK3MM4kAFfE171m0A8QqYOsw%2Be5KA%2FgNSWBV9vyk%3D&amp;reserved=0).

-Ed

---

> [1] https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-ietf-dtn-bpbis-31&amp;data=04%7C01%7CBSipos%40rkf-eng.com%7C91dd4d5401e34e659dc008d8c718064c%7C4ed8b15b911f42bc8524d89148858535%7C1%7C0%7C637478253307478566%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=H7Pa40sy%2FtdWz1ldSgjMboVPlo0em241MM%2FIig%2BfkdI%3D&amp;reserved=0
> [2] https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-ietf-dtn-bpsec-26&amp;data=04%7C01%7CBSipos%40rkf-eng.com%7C91dd4d5401e34e659dc008d8c718064c%7C4ed8b15b911f42bc8524d89148858535%7C1%7C0%7C637478253307478566%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=dYERAO7%2Bq1RMJtt9vfjRxp4KaHZ3eEPYTshBJbB8xss%3D&amp;reserved=0

---

From: "Birrane, Edward J." <[email-masked]>
Date: Tue, 2 Feb 2021 14:26:32 +0000

Brian,

  Completely agree that working through these corner cases is valuable and informative and I have been appreciating your thorough review of these documents through their last calls.

  In the case you describe (and assuming the MTU and other bundle characteristics support it) there is nothing preventing the same security policy that required adding the BCB to add the BCB with flags saying that it, too, should be replicated in every fragment.

  In fact, there are probably a few policy statements that could be made regarding block processing control flags (BPCFs), such as a security block should have the same bpcf as its target or a security block with multiple targets should have the most permissive union of its target bpcfs. Or maybe that all security blocks should be replicated in every fragment no matter what. The options you present below are all interesting policy statements/considerations that or may not be preferable based on the type of traffic, network, and type of extension block.

  My concern was simply that when we talk about requirements on the node, we should mean policy and not normative specification - because I don't see a one-size-fits-all normative statement for these cases.

  Ultimately, fragmenting a bundle changes the bundle. While it is not a malicious change, it is one which can break security processing because (absent perfect knowledge) these changes are indistinguishable from an attack. Fragmentation changes the primary block and may cause security blocks to be "dropped" from a bundle.

  Again, with your example, if the BCB co-located with its target in a fragment had included the primary block as part of its AAD, then the target could not be decrypted anyway.  Though perhaps a BPA would be able to use the fact that a BCB existed over the target to react to its failure to process the target in some more graceful way.

-Ed

---

From: Brian Sipos <[email-masked]>
Sent: Monday, February 01, 2021 10:38 PM
To: Birrane, Edward J. <[email-masked]>; [email-masked]
Subject: [EXT] Re: BPSec and bundle fragmentation

APL external email warning: Verify sender [email-masked]<mailto:[email-masked]> before clicking links or attachments

Ed,

And I agree that the better solution is to fragment the whole bundle as an opaque byte string (either by BIBE or via CL fragmentation). I just ran into this when trying to figure out what could be done within the letter of the law.
________________________________
From: Birrane, Edward J. <[email-masked]<mailto:[email-masked]>>
Sent: Monday, February 1, 2021 20:15
To: Brian Sipos <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]> <[email-masked]<mailto:[email-masked]>>
Subject: RE: BPSec and bundle fragmentation

Brian,

-Ed

---

> From: Brian Sipos <[email-masked]<mailto:[email-masked]>>
> To: [email-masked]<mailto:[email-masked]>
> Cc: Birrane, Edward J. <[email-masked]<mailto:[email-masked]>>
> APL external email warning: Verify sender [email-masked]<mailto:[email-masked]> before