IETF Logo Mail Archive

Re: [dtn] BPv7 bundle flags

"Burleigh, Scott C (312B)" <scott.c.burleigh@jpl.nasa.gov> Mon, 15 April 2019 15:23 UTC

Return-Path: <scott.c.burleigh@jpl.nasa.gov>
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 CA7C61203D1 for <dtn@ietfa.amsl.com>; Mon, 15 Apr 2019 08:23:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.002
X-Spam-Level:
X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=jpl.nasa.gov
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 v1-JRysJfgHs for <dtn@ietfa.amsl.com>; Mon, 15 Apr 2019 08:23:29 -0700 (PDT)
Received: from ppa02.jpl.nasa.gov (ppa02.jpl.nasa.gov [128.149.137.113]) (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 B8FF41200B8 for <dtn@ietf.org>; Mon, 15 Apr 2019 08:23:22 -0700 (PDT)
Received: from pps.filterd (ppa02.jpl.nasa.gov [127.0.0.1]) by ppa02.jpl.nasa.gov (8.16.0.27/8.16.0.27) with SMTP id x3FFKTUD012048; Mon, 15 Apr 2019 08:23:21 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jpl.nasa.gov; h=from : to : subject : date : message-id : references : in-reply-to : content-type : content-transfer-encoding : mime-version; s=JPL1810; bh=p1g9svk7qG8BKIUSqRzHA199y1zBOEO09vkn/JHuWNU=; b=ll3fDngSsa8ay7NShJDwPcOipgPzcERtyIQ21cWxu3Hv9CZzc8npL9C6aKsfJFEwmaJY j/K7nA42g0py1lC+Kyuka3QqJB3nXI87rWfR78CAolBQAGvzg7st7nx85aInqyNmhUrT wqdhxzpMT6I51+lB4Qz+UVwZrs4cIkWvsxtZsyPgqfr6RrHmWrx4ODKqRfdr2HtWdKkV wfX4flTXOzWTv+hUe5fzC1cu1UopcY5nDWOBNtQ+3meXMEgguSU44GmO0aaOL4RKyMYl 3V5DveFk05UCAQgXzwFGQsyFJrBPf0z91Q1cx0232ojxfHetMa5t+u+px6+krK+rpAo+ Og==
Received: from mail.jpl.nasa.gov (altphysenclup02.jpl.nasa.gov [128.149.137.53]) by ppa02.jpl.nasa.gov with ESMTP id 2ruexud1aw-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 15 Apr 2019 08:23:20 -0700
Received: from ap-embx16-sp60.RES.AD.JPL (ap-embx16-sp60.jpl.nasa.gov [128.149.137.141]) by smtp.jpl.nasa.gov (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id x3FFNJI8025467 (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128 bits) verified FAIL); Mon, 15 Apr 2019 08:23:20 -0700
Received: from ap-embx16-sp10.RES.AD.JPL (2002:8095:8953::8095:8953) by ap-embx16-sp60.RES.AD.JPL (2002:8095:898d::8095:898d) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1591.10; Mon, 15 Apr 2019 08:23:19 -0700
Received: from ap-embx16-sp10.RES.AD.JPL ([fe80::4:f430:47b5:767b]) by ap-embx16-sp10.RES.AD.JPL ([fe80::4:f430:47b5:767b%17]) with mapi id 15.01.1591.008; Mon, 15 Apr 2019 08:23:19 -0700
From: "Burleigh, Scott C (312B)" <scott.c.burleigh@jpl.nasa.gov>
To: Brian Sipos <BSipos@rkf-eng.com>, "dtn@ietf.org" <dtn@ietf.org>
Thread-Topic: BPv7 bundle flags
Thread-Index: AQHU8hPmU2110ssDa0u6iOwFIgEuuaY9Vfyg
Date: Mon, 15 Apr 2019 15:23:19 +0000
Message-ID: <525347626b6c4606a6fe6b9d526ee27b@jpl.nasa.gov>
References: <004d51214bec07c40494ba6ecdfce32fd79e39bf.camel@rkf-eng.com>
In-Reply-To: <004d51214bec07c40494ba6ecdfce32fd79e39bf.camel@rkf-eng.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [207.151.104.72]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-Source-IP: ap-embx16-sp60.jpl.nasa.gov [128.149.137.141]
X-Source-Sender: scott.c.burleigh@jpl.nasa.gov
X-AUTH: Authorized
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-04-15_06:, , signatures=0
X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1810050000 definitions=main-1904150106
Archived-At: <https://mailarchive.ietf.org/arch/msg/dtn/Utqk-SDFH7HxQBCynZ5KVv910fs>
Subject: Re: [dtn] BPv7 bundle flags
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: Mon, 15 Apr 2019 15:23:31 -0000

Hi, Brian.  People have been asking for something like a Manifest block for several years, but there has never been quite enough energy to get one defined.  So that flag is intended to support a notional future capability.

As I recall, the intent of this capability was to ensure that a certain type of bundle tampering - removal of one or more extension blocks - would be detectable; only a Manifest extension block, protected by a BIB signed by the source node, could accomplish this.  But the one bit of tampering that a signed Manifest block could not detect would be removal of the Manifest block itself.  [Replacement of the Manifest block with a bogus manifest would be detectable due to lack of a BIB signed by the source node.]  The way to make this detectable would be to set a flag in the primary block and (as usual) protect the primary block with a BIB signed by the source node.

So I think a good case can be made for retaining that flag and adding definition of the Manifest block to the charter of the DTN WG once our first round of document are well on their way.  But if the consensus of the WG is otherwise then I will happily revise the BPbis spec.

Scott

-----Original Message-----
From: Brian Sipos <BSipos@rkf-eng.com> 
Sent: Saturday, April 13, 2019 9:14 AM
To: Burleigh, Scott C (312B) <scott.c.burleigh@jpl.nasa.gov>; dtn@ietf.org
Subject: [EXTERNAL] BPv7 bundle flags

Scott,
As of BPbis -12 draft, there is a bundle flag "bundle contains a Manifest block" which seems to not really serve any purpose, especially because the block type is not defined in the draft. The other flags indicate how the bundle is to be handled or reported-about, but I don't see what this flag is supposed to influence. If the bundle does in fact contain a manifest block then that should be evident from the presence of that block type itself.

Should this flag really be defined in bpbis, or just reserved for later use? And is there really a use for a flag even when the block type is defined?
Thanks,
Brian S.

v2.23.0 | Report a Bug | By Email