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

["Birrane, Edward J." <[e-mail]>]

Dave,

  Thank you for fragmenting the discussion into separate threads; it is much easier to parse this way.

I recommend the following:

- It is the intention that when adding a BAB, the next BP hop for the bundle is a security-aware node, but this cannot be guaranteed (e.g., there may be a misconfiguration in the network). The language in the spec should be updated to reflect this.

We should do one (not both) of the following:

A: When adding a BAB to a bundle, ensure that the bundle's "Bundle must not be fragmented" field is set. This will result in a delivery failure if the next BP-hop is unable to deliver the bundle as-is, but also ensures there is no payload surgery between BP-hops that require BAB authentication.

B: Use the content range for the ciphersuite parameters to identify the offset,length of the bundle being protected. Then, require BPAs to wait until all fragments of a bundle are received, and then do the authentication check.

My preference is to do "A". It is simple and strict when requiring authentication, as should be the case with authentication.

My concern regarding approach "B" is that we have to use up memory and other resources for partial bundles. Part of the job of authentication is to prevent some types of resource attacks on the network, and "B" seems to re-enable some of those attacks.

-Ed

---
Ed Birrane
Principal Professional Staff, Space Department
Johns Hopkins Applied Physics Laboratory
(W) 443-778-7423 / (F) 443-228-3839


From: Zoller, David A. (MSFC-EO50)[HOSC SERVICES CONTRACT] [mailto:[e-mail]]
Sent: Monday, June 02, 2014 1:07 PM
To: Burleigh, Scott C (JPL-312G)[Jet Propulsion Laboratory]; Birrane, Edward J.; [e-mail]
Subject: RE: Updated SBSP Document - BAB

<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
<SB>

Ø  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.

<AA>
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.

<SB>
>>           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.

<KS>
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).

<SB>

Ø 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.


<DZ>
Having outgoing email issues so some of this is now late and could be later by the time it gets through - if it gets there.

o   This is true when all traversed nodes are SBSP compliant and we probably do not want to overly complicate SBSP trying to anticipate and handle all possible off-nominal scenarios. One of the off-nominal scenarios that I would not be surprised to see with the Space Station is the case where our gateway nodes are running pre-SBSP software and a payload developer installs a cutting edge SBSP implementation. In this scenario, if the payload node applies a BAB to a large bundle [or fragment] then there is the possibility that the pre-SBSP gateway node will fragment [or further fragment] the bundle and not remove the BAB resulting in its misinterpretation when it makes to the end node that is SBSP compliant.

o   I am okay with not specifically handling this scenario as we can recommend not using the BAB until the gateway nodes are updated to SBSP compliance or that their local policy set the 'Discard block if it can't be processed' flag on the BAB.

§  Amy mentioned the DO_NOT_FRAGMENT" flag as another possible option before I could send this reply due to system and email issues (and maybe I am a slow typist)...

·         What happens if there is a conflict between DO_NOT_FRAGMENT and "must fragment if bigger than x"? Is the bundle sent whole, trapped, or deleted?

§  And now - the suggested BIBE is another good approach

o   If this particular scenario might impact other folks as well and the consensus is to handle it then a refinement would be to use the <block type> to hold the fragment offset so that a further fragmented fragment could be more reliably reconstituted and BAB verified. I "think" this would make the BAB "SBSP_hop - to - SBSP_hop" regardless of the compliance of any intervening nodes.