Re: [dtn] BPSec and bundle fragmentation

"Birrane, Edward J." <Edward.Birrane@jhuapl.edu> Tue, 02 February 2021 01:15 UTC

Return-Path: <Edward.Birrane@jhuapl.edu>
X-Original-To: dtn@ietfa.amsl.com
Delivered-To: dtn@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 691733A163D for <dtn@ietfa.amsl.com>; Mon, 1 Feb 2021 17:15:27 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level:
X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=jhuapl.edu
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 zS5cop466VE9 for <dtn@ietfa.amsl.com>; Mon, 1 Feb 2021 17:15:25 -0800 (PST)
Received: from aplegw02.jhuapl.edu (aplegw02.jhuapl.edu [128.244.251.169]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 777193A1634 for <dtn@ietf.org>; Mon, 1 Feb 2021 17:15:25 -0800 (PST)
Received: from pps.filterd (aplegw02.jhuapl.edu [127.0.0.1]) by aplegw02.jhuapl.edu (8.16.0.42/8.16.0.42) with SMTP id 1121EhHN005691; Mon, 1 Feb 2021 20:15:22 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jhuapl.edu; h=from : to : subject : date : message-id : references : in-reply-to : content-type : content-transfer-encoding : mime-version; s=JHUAPLDec2018; bh=Fo9V4UzKqXwcW4Uid/mXGs6ZcmFurT7TyDZe5EDrEbs=; b=JrhQ7fanB1+PcGsOxKoRePVpYV3urrsJ4bYo4DEqUsmsr9vdKROkCJYIdXE7ZLNrfA/p TAzFMdjoaZe2HfbGY/z6BGmFAC8w07wrGq9zo8CV51DO+ZnjXm1t7PX57KCf05AcJKz4 kkonn8JkLExfKyWyhozPbDvYNNJN6DVstl3HtSRHf24Zc98FimNWgU5fgohTyREYE11S 8R/kVLt87yla1LtRlc1D67A2md8WFoEXM0LS+XvV+ki9J34aLw2HPaXUlqbZEGWN9cj/ a+C2/i8MxhQuwhTt0LW7aQKbhvq0dj0cFZAq1AQxJeImB+WRRjJgB/dMxwK6QBUIG95K BQ==
Received: from aplex02.dom1.jhuapl.edu (aplex02.dom1.jhuapl.edu [128.244.198.6]) by aplegw02.jhuapl.edu with ESMTP id 36d4j1j1aj-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Mon, 01 Feb 2021 20:15:22 -0500
X-CrossPremisesHeadersFilteredBySendConnector: aplex02.dom1.jhuapl.edu
Received: from aplex01.dom1.jhuapl.edu (128.244.198.5) by aplex02.dom1.jhuapl.edu (128.244.198.6) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Mon, 1 Feb 2021 20:15:22 -0500
Received: from aplex01.dom1.jhuapl.edu ([fe80::19f5:dcc5:c696:1a50]) by aplex01.dom1.jhuapl.edu ([fe80::19f5:dcc5:c696:1a50%25]) with mapi id 15.00.1497.007; Mon, 1 Feb 2021 20:15:22 -0500
From: "Birrane, Edward J." <Edward.Birrane@jhuapl.edu>
To: Brian Sipos <BSipos@rkf-eng.com>, "dtn@ietf.org" <dtn@ietf.org>
Thread-Topic: BPSec and bundle fragmentation
Thread-Index: AQHW+OZiAQnUion8Z06QD/5h+pouv6pD6muQ
Date: Tue, 02 Feb 2021 01:15:21 +0000
Message-ID: <1545e685bb77462e962efc2bb59ee1ed@aplex01.dom1.jhuapl.edu>
References: <b8c948b4307bc464185975b8391f70cfa4e691b8.camel@rkf-eng.com>
In-Reply-To: <b8c948b4307bc464185975b8391f70cfa4e691b8.camel@rkf-eng.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [128.244.198.169]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OrganizationHeadersPreserved: aplex02.dom1.jhuapl.edu
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.369, 18.0.737 definitions=2021-02-01_14:2021-01-29, 2021-02-01 signatures=0
Archived-At: <https://mailarchive.ietf.org/arch/msg/dtn/Bx_7peqOopFmMhKAYiF1ZZhjPok>
Subject: Re: [dtn] BPSec and bundle fragmentation
X-BeenThere: dtn@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Delay Tolerant Networking \(DTN\) discussion list at the IETF." <dtn.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dtn>, <mailto:dtn-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dtn/>
List-Post: <mailto:dtn@ietf.org>
List-Help: <mailto:dtn-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dtn>, <mailto:dtn-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 02 Feb 2021 01:15:30 -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 <BSipos@rkf-eng.com>
> Sent: Monday, February 01, 2021 5:06 PM
> To: dtn@ietf.org
> Cc: Birrane, Edward J. <Edward.Birrane@jhuapl.edu>
> Subject: [EXT] BPSec and bundle fragmentation
> 
> APL external email warning: Verify sender BSipos@rkf-eng.com 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
> 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