Re: [dtn-security] Updated SBSP Document

[Amy Alford <[e-mail]>]

I'm also responding inline.


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

>  A couple of remarks on David’s comments, in-line below.
>
>
>
> Scott
>
>
>
> *From:* dtn-security [mailto:[e-mail]] *On Behalf Of
> *Zoller, David A. (MSFC-EO50)[HOSC SERVICES CONTRACT]
> *Sent:* Thursday, May 29, 2014 12:09 PM
> *To:* Birrane, Edward J.; [e-mail]
> *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.