Re: [dtn-security] Updated SBSP Document - BCB and BIB

"Zoller, David A. (MSFC-EO50)[HOSC SERVICES CONTRACT]" <david.a.zoller@nasa.gov> Mon, 02 June 2014 17:20 UTC

Return-Path: <david.a.zoller@nasa.gov>
X-Original-To: dtn-security@ietfa.amsl.com
Delivered-To: dtn-security@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 346F11A024D for <dtn-security@ietfa.amsl.com>; Mon, 2 Jun 2014 10:20:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.551
X-Spam-Level:
X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rarQOC1HkDho for <dtn-security@ietfa.amsl.com>; Mon, 2 Jun 2014 10:20:47 -0700 (PDT)
Received: from ndjsnpf01.ndc.nasa.gov (ndjsnpf01.ndc.nasa.gov [IPv6:2001:4d0:a302:1100::101]) by ietfa.amsl.com (Postfix) with ESMTP id AC3A31A01ED for <dtn-security@irtf.org>; Mon, 2 Jun 2014 10:20:46 -0700 (PDT)
Received: from ndmsppt104.ndc.nasa.gov (ndmsppt104.ndc.nasa.gov [198.117.0.69]) by ndjsnpf01.ndc.nasa.gov (Postfix) with ESMTP id 66AA8D051E; Mon, 2 Jun 2014 12:15:02 -0500 (CDT)
Received: from NDMSCHT109.ndc.nasa.gov (ndmscht109-pub.ndc.nasa.gov [198.117.0.209]) by ndmsppt104.ndc.nasa.gov (8.14.5/8.14.5) with ESMTP id s52HKeen008379; Mon, 2 Jun 2014 12:20:40 -0500
Received: from NDMSMBX404.ndc.nasa.gov ([169.254.4.107]) by NDMSCHT109.ndc.nasa.gov ([198.117.0.209]) with mapi id 14.03.0174.001; Mon, 2 Jun 2014 12:20:40 -0500
From: "Zoller, David A. (MSFC-EO50)[HOSC SERVICES CONTRACT]" <david.a.zoller@nasa.gov>
To: "Zoller, David A. (MSFC-EO50)[HOSC SERVICES CONTRACT]" <david.a.zoller@nasa.gov>, "Burleigh, Scott C (JPL-312G)[Jet Propulsion Laboratory]" <scott.c.burleigh@jpl.nasa.gov>, "Birrane, Edward J." <Edward.Birrane@jhuapl.edu>, "dtn-security@irtf.org" <dtn-security@irtf.org>
Thread-Topic: Updated SBSP Document - BCB and BIB
Thread-Index: Ac9+hoOpmbVxZkqoRbuTayxesOBSNw==
Date: Mon, 02 Jun 2014 17:20:40 +0000
Message-ID: <94CFB3711B4CAE4DBFC5BEB3374BF0C60D8E56@NDMSMBX404.ndc.nasa.gov>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [198.119.225.34]
Content-Type: multipart/alternative; boundary="_000_94CFB3711B4CAE4DBFC5BEB3374BF0C60D8E56NDMSMBX404ndcnasa_"
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.12.52, 1.0.14, 0.0.0000 definitions=2014-06-02_02:2014-06-02,2014-06-02,1970-01-01 signatures=0
Archived-At: http://mailarchive.ietf.org/arch/msg/dtn-security/OVJ_YYAIrP76RyfF_SdoS4o6pq8
Subject: Re: [dtn-security] Updated SBSP Document - BCB and BIB
X-BeenThere: dtn-security@irtf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "The Delay-Tolerant Networking Research Group \(DTNRG\) - Security." <dtn-security.irtf.org>
List-Unsubscribe: <https://www.irtf.org/mailman/options/dtn-security>, <mailto:dtn-security-request@irtf.org?subject=unsubscribe>
List-Archive: <http://www.irtf.org/mail-archive/web/dtn-security/>
List-Post: <mailto:dtn-security@irtf.org>
List-Help: <mailto:dtn-security-request@irtf.org?subject=help>
List-Subscribe: <https://www.irtf.org/mailman/listinfo/dtn-security>, <mailto:dtn-security-request@irtf.org?subject=subscribe>
X-List-Received-Date: Mon, 02 Jun 2014 17:20:49 -0000

<DZ>
[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?

<SB>

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

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


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

<DZ>
Fortunately, section 3.4 does prevent adding a BCB or a BIB to a fragment.