Subject: Re: [dtn-security] Updated SBSP Document

From: Amy Alford <[email-masked]>
Date: Mon, 2 Jun 2014 11:32:31 -0400

I'm also responding inline.

On Fri, May 30, 2014 at 3:17 PM, Burleigh, Scott C (312G) <
[email-masked]> wrote:

>  A couple of remarks on David’s comments, in-line below.
>
>
>
> Scott
>
>
>
> *From:* dtn-security [mailto:[email-masked]] *On Behalf Of
> *Zoller, David A. (MSFC-EO50)[HOSC SERVICES CONTRACT]
> *Sent:* Thursday, May 29, 2014 12:09 PM
> *To:* Birrane, Edward J.; [email-masked]
> *Subject:* Re: [dtn-security] Updated SBSP Document
>
>
>
> Ed,
>
> Good work - the SBSP spec continues to evolve nicely. I’ll kick off the
> discussions with my comments below.
>
> Cheers,
>
> DZ
>
>
>
>
>
>
>
> *[Page 12] 2.4 Bundle Authentication Block*
>
> The security-target MUST be the entire bundle, which MUST be
>
> represented by a <block type><occurrence number> of <0x00><0x00>.
>
> ·         Per 3.4 Bundle Fragmentation and Reassembly, bundle
> authentication may be applied to bundle fragments as well as non-fragmented
> bundles.
>
> ·         If a bundle fragment is received that has a BAB, there is no
> way to determine if the BAB applies to the bundle fragment or if it applies
> to an entire bundle that was later fragmented by a non-security-aware BA.
>
> o    I propose that a <block type><occurrence number> of <0x00><payload
> frag length> indicate that the BAB applies to a bundle fragment
>
> ·         If such a bundle fragment is further fragmented by a
> non-security-aware BA then the <payload frag length> can be used to
> determine that the original fragmented bundle must be reassembled before
> authentication is checked because it will not match the length field in the
> payload block.
>
> o    Some discussion may be desirable in section 3.4 as well as 2.4 if
> accepted
>
> Ø  When a BAB is attached to a bundle that is a fragment, the bundle that
> it applies to is always that fragment, never the bundle that carried the
> original payload (of which the current bundle’s payload is a fragment).
> Since BABs are not end-to-end, the BAB for an original un-fragmented bundle
> will never be carried forward in any fragments generated from that bundle
> (see the last paragraph of 3.3.1), so there’s no ambiguity.  But this does
> bring up an important point: the block processing control flags of the BAB
> must always have the “replicate in every fragment” flag set to 0.
>
>
>
Maybe I'm misunderstanding here, but fragmentation can happen between a BAB
source and a BAB dest if a non-security aware node is between the two.
 Requiring the "DO_NOT_FRAGMENT" flag solves this.

>
>
> *[Page 14] 2.6 Block Confidentiality Block*
>
> The block processing control flags value can be set to whatever
>
> values are required by local policy, except that a Lone BCB or
>
> First BCB MUST have the "replicate in every fragment" flag set.
>
> This indicates to a receiving node that the payload portion in
>
> each fragment represents cipher-text.
>
> ·         The intent here is only if the target of the Lone BCB or First
> BCB is the payload block which would need to be added if this is kept as a
> requirement.
>
> ·         I think this requirement should be removed or at least reduced
> to a "MAY"
>
> 1.       It assumes that the Lone or First BCB must be prior to the
> payload block which is not a specific requirement and is not necessary in
> any case for SBSP
>
> 2.       A BCB block could be quite large and add a lot of bandwidth
> overhead if included in every fragment
>
> 3.       I do not see a benefit gained by including the block in every
> fragment
>
>                                        i.            Even the destination
> node likely cannot decrypt any individual fragment except the first one
> and  it probably would only decrypt a partial bundle as a last resort or
> forensic function if the entire bundle was not received before expiration
>
>                                      ii.            Intermediate nodes
> shouldn't generally be poking around in bundle payloads anyway and no need
> to provide additional clues as to whether a fragment payload is encrypted
> or a bunch of binary values – keep the bad guys guessing and wasting CPU
> cycles if possible
>
>                                     iii.            BSP includes this
> requirement - have any of the implementations found a need or benefit for
> this and would it still apply in context of the SBSP?
>
> Ø  I think this a good point.  Since all decryption should only happen at
> the bundle destination, which is where all the fragments are going to have
> to end up, why not forward all BCBs (for all blocks that have them) only
> with the fragment whose offset is zero?
>
Is there a possibility of an intermediate node adding a BIB to the
fragment, unaware that there's already a BCB on the whole payload?  I
really hate the interaction between fragmentation and BSP.  I feel like
tightly locking down how the two of them combine avoids a lot of pitfalls
and ambiguity.

>
>
>
>
>
> *[Page 24] 3.1.2.3 Extension Block Canonicalization*
>
> The block-length is canonicalized as its unpacked SDNV value.  If the
>
> data to be canonicalized is less than the complete, original block
>
> data, this field contains the size of the data being canonicalized
>
> (the "effective block") rather than the actual size of the block.
>
> ·         Section 3.1.2.1 (Primary Block Canonicalization) details the
> length fields as 4 byte values and effectively reserves the term "unpacked
> SDNV value" to mean the 8 byte value. I recommend using the same convention
> here.
>
> o    Personally, I would specify all SDNV values canonicalized as 8 byte
> values and be done with it
>
> ·         Add a statement to the effect:
>
> o    The entirety or portion(s) of the block body data are canonicalized
> as is.
>
> Ø  I agree about canonicalizing all SDNVs as 8-byte values.  FWIW, I
> think the canonicalization in bundle security protocol is a major pain in
> the neck.  Is the mutability of blocks – the need to exclude mutable fields
> from hash computations – the main reason for it?  Is there no way to
> simplify?
>
>
>
I think the major issue is the dictionary, since it can be modified even if
the actual eid's in the block are stable.  The flags are straightforward.
 In BSP, there's also a big issue with tail chasing when a PIB block is
required to include chunks of itself in it's own hash.  IIRC, SBSP avoids
that entirely.

---

From: "Burleigh, Scott C (312G)" <[email-masked]>
Date: Mon, 2 Jun 2014 15:55:13 +0000

Good points, Amy.  My thoughts likewise in-line.

Scott

From: Amy Alford [mailto:[email-masked]]
Sent: Monday, June 02, 2014 8:33 AM
To: Burleigh, Scott C (312G)
Cc: Zoller, David A. (MSFC-EO50)[HOSC SERVICES CONTRACT]; Birrane, Edward J.; [email-masked]
Subject: Re: [dtn-security] Updated SBSP Document

On Fri, May 30, 2014 at 3:17 PM, Burleigh, Scott C (312G) <[email-masked]<mailto:[email-masked]>> wrote:
A couple of remarks on David’s comments, in-line below.
Scott
From: dtn-security [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Zoller, David A. (MSFC-EO50)[HOSC SERVICES CONTRACT]
Sent: Thursday, May 29, 2014 12:09 PM
To: Birrane, Edward J.; [email-masked]<mailto:[email-masked]>
Subject: Re: [dtn-security] Updated SBSP Document

Ed,

Good work - the SBSP spec continues to evolve nicely. I’ll kick off the discussions with my comments below.

Cheers,

DZ
[Page 12] 2.4 Bundle Authentication Block
The security-target MUST be the entire bundle, which MUST be
represented by a <block type><occurrence number> of <0x00><0x00>.
•         Per 3.4 Bundle Fragmentation and Reassembly, bundle authentication may be applied to bundle fragments as well as non-fragmented bundles.
•         If a bundle fragment is received that has a BAB, there is no way to determine if the BAB applies to the bundle fragment or if it applies to an entire bundle that was later fragmented by a non-security-aware BA.
o    I propose that a <block type><occurrence number> of <0x00><payload frag length> indicate that the BAB applies to a bundle fragment
•         If such a bundle fragment is further fragmented by a non-security-aware BA then the <payload frag length> can be used to determine that the original fragmented bundle must be reassembled before authentication is checked because it will not match the length field in the payload block.
o    Some discussion may be desirable in section 3.4 as well as 2.4 if accepted

>  When a BAB is attached to a bundle that is a fragment, the bundle that it applies to is always that fragment, never the bundle that carried the original payload (of which the current bundle’s payload is a fragment).  Since BABs are not end-to-end, the BAB for an original un-fragmented bundle will never be carried forward in any fragments generated from that bundle (see the last paragraph of 3.3.1), so there’s no ambiguity.  But this does bring up an important point: the block processing control flags of the BAB must always have the “replicate in every fragment” flag set to 0.
Maybe I'm misunderstanding here, but fragmentation can happen between a BAB source and a BAB dest if a non-security aware node is between the two.  Requiring the "DO_NOT_FRAGMENT" flag solves this.

>>           I see what you’re saying, and I think it goes to the lament in your next comment: the interaction between fragmentation and BSP really is a mess.  But I thought SBSP simplified things somewhat by not allowing any non-security-aware nodes between the BAB source and BAB destination.  At least, that’s what I hoped we were doing, and it’s how I interpret “BABs operate between topologically adjacent nodes” on page 6.  If that’s not the case then I think there are additional problems to resolve.

 [Page 14] 2.6 Block Confidentiality Block
The block processing control flags value can be set to whatever
values are required by local policy, except that a Lone BCB or
First BCB MUST have the "replicate in every fragment" flag set.
This indicates to a receiving node that the payload portion in
each fragment represents cipher-text.
•         The intent here is only if the target of the Lone BCB or First BCB is the payload block which would need to be added if this is kept as a requirement.
•         I think this requirement should be removed or at least reduced to a "MAY"
1.       It assumes that the Lone or First BCB must be prior to the payload block which is not a specific requirement and is not necessary in any case for SBSP
2.       A BCB block could be quite large and add a lot of bandwidth overhead if included in every fragment
3.       I do not see a benefit gained by including the block in every fragment
                                       i.            Even the destination node likely cannot decrypt any individual fragment except the first one and  it probably would only decrypt a partial bundle as a last resort or forensic function if the entire bundle was not received before expiration
                                     ii.            Intermediate nodes shouldn't generally be poking around in bundle payloads anyway and no need to provide additional clues as to whether a fragment payload is encrypted or a bunch of binary values – keep the bad guys guessing and wasting CPU cycles if possible
                                    iii.            BSP includes this requirement - have any of the implementations found a need or benefit for this and would it still apply in context of the SBSP?

>  I think this a good point.  Since all decryption should only happen at the bundle destination, which is where all the fragments are going to have to end up, why not forward all BCBs (for all blocks that have them) only with the fragment whose offset is zero?
Is there a possibility of an intermediate node adding a BIB to the fragment, unaware that there's already a BCB on the whole payload?  I really hate the interaction between fragmentation and BSP.  I feel like tightly locking down how the two of them combine avoids a lot of pitfalls and ambiguity.

>>           Is there any real need to allow payload BIBs and BCBs to be added in bundles that are fragments?  Why not just prohibit that?  If it’s absolutely necessary for some unfathomable reason, use bundle-in-bundle encapsulation to encapsulate the fragmentary bundle as the payload of a new bundle and attach the BIB or BCB to the encapsulating bundle.

[Page 24] 3.1.2.3 Extension Block Canonicalization
The block-length is canonicalized as its unpacked SDNV value.  If the
data to be canonicalized is less than the complete, original block
data, this field contains the size of the data being canonicalized
(the "effective block") rather than the actual size of the block.
•         Section 3.1.2.1 (Primary Block Canonicalization) details the length fields as 4 byte values and effectively reserves the term "unpacked SDNV value" to mean the 8 byte value. I recommend using the same convention here.
o    Personally, I would specify all SDNV values canonicalized as 8 byte values and be done with it
•         Add a statement to the effect:
o    The entirety or portion(s) of the block body data are canonicalized as is.

>  I agree about canonicalizing all SDNVs as 8-byte values.  FWIW, I think the canonicalization in bundle security protocol is a major pain in the neck.  Is the mutability of blocks – the need to exclude mutable fields from hash computations – the main reason for it?  Is there no way to simplify?
I think the major issue is the dictionary, since it can be modified even if the actual eid's in the block are stable.  The flags are straightforward.  In BSP, there's also a big issue with tail chasing when a PIB block is required to include chunks of itself in it's own hash.  IIRC, SBSP avoids that entirely.

>>           Which is a major reason that I want to get rid of the dictionary altogether in “RFC5050bis”.

---

From: "Scott, Keith L." <[email-masked]>
Date: Mon, 2 Jun 2014 16:27:13 +0000

Some comments in-line below.

                        --keith

From: dtn-security [mailto:[email-masked]] On Behalf Of Amy Alford
Sent: Monday, June 02, 2014 11:33 AM
To: Burleigh, Scott C (312G)
Cc: [email-masked]
Subject: Re: [dtn-security] Updated SBSP Document

Scott

Ed,

Cheers,

DZ

BABs should be applied ‘point-to-point’ between bundle agents; there shouldn’t be an opportunity for a non-security-aware node to fragment a bundle with a BAB on it.  I’ll have to check the cross-product between encapsulation and BAB (i.e. whether you can encapsulate a bundle with a BAB on it (and then possibly fragment the encapsulating bundle) or not).  I suspect that the answer is ‘no’ (i.e. you check / remove the BAB immediately on receipt and before you encapsulate and/or fragment for transmission).

My notion is that the BCB should apply to the entire (unfragmented) payload.  If it’s possible to apply a BCB to a fragment (in the middle of a path and connection) then the BCB itself had better state to which bytes of the payload it applies, or it’s going to be really hard to sort it out later.

What’s the rationale for replication?  The destination is the only node that’s going to have to deal with decryption, so what is this doing?  Is the notion that the receiver might pass parts of the not-yet-fully-received bundle to the application?  That would be, I think, wrong.

---

From: "Burleigh, Scott C (312G)" <[email-masked]>
Date: Mon, 2 Jun 2014 16:53:44 +0000

One more comment on one of these topics, also in-line.

From: Scott, Keith L. [mailto:[email-masked]]
Sent: Monday, June 02, 2014 9:27 AM
To: Amy Alford; Burleigh, Scott C (312G)
Cc: [email-masked]
Subject: RE: [dtn-security] Updated SBSP Document

                        --keith

Cc: [email-masked]<mailto:[email-masked]>

Ed,

Cheers,

DZ

Ø There isn’t really any accepted spec to consult on encapsulation, but within the concept that I’ve been working with (https://datatracker.ietf.org/doc/draft-irtf-burleigh-bibe/) the encapsulation protocol is a convergence-layer adapter.  In that case, the entire, complete outbound bundle – including any BAB that was attached at the last moment before serialization for the CLA – would become the payload of the new encapsulating bundle.  The encapsulating bundle might or might not be security-aware, but that doesn’t matter.  The destination of the encapsulating bundle would extract the encapsulated bundle (the “outer” bundle’s payload) and simulate reception of that bundle, which would still have its BAB.  That bundle would, in effect, have traversed only a single hop (direct transmission between sender and receiver at the convergence layer), so there was no intervening non-security-aware forwarding node between the sending node that attached the BAB and the receiving node that would validate it.  So no opportunity for fragmentation, no problem.