Re: [dtn] [EXT] Martin Duke's Discuss on draft-ietf-dtn-bpsec-24: (with DISCUSS and COMMENT)

"Birrane, Edward J." <Edward.Birrane@jhuapl.edu> Tue, 01 December 2020 14:53 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 08AEC3A133B; Tue, 1 Dec 2020 06:53:31 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.1
X-Spam-Level:
X-Spam-Status: No, score=-2.1 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_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 ZzY-GWD7JgVL; Tue, 1 Dec 2020 06:53:29 -0800 (PST)
Received: from aplegw01.jhuapl.edu (aplegw01.jhuapl.edu [128.244.251.168]) (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 071283A133D; Tue, 1 Dec 2020 06:53:10 -0800 (PST)
Received: from pps.filterd (aplegw01.jhuapl.edu [127.0.0.1]) by aplegw01.jhuapl.edu (8.16.0.42/8.16.0.42) with SMTP id 0B1Er8GG063105; Tue, 1 Dec 2020 09:53:08 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jhuapl.edu; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : content-transfer-encoding : mime-version; s=JHUAPLDec2018; bh=mN0kwlzYMOj6ii8WyptjyATjJLEfZadqLGtgnZg0CIg=; b=D/JaAss8aD4iBseGtHwU3LRwxuFA98Q+usjl58SXS1PzoMstBvYrfd713jIfieC1ocW5 Ohg97k5gf6idcLbBTHmlOrV+2bvdmM/qioG687LmrbdHV5xCrURfrbhyeHmZ1ggCXXh+ 39ewGew8t/EDfwun41y64HJ1S+cc8CmUokkqrTrPCPrDc3vnpKZISHFQ/BFFZ8dAMuNo Pxc9xO7QSPDBxcgGj2wVSuydsJZjMzSlTymk2NVraQcdmY/uU6oNGRV/6TJdPBEWTvxI kv09Ydy4aTSt0vf1cv7eo8VBrKcX955vcN/x66yitxGaAcUXWOseUgSDQnTgSINuLwjd Uw==
Received: from aplex04.dom1.jhuapl.edu (aplex04.dom1.jhuapl.edu [128.244.198.162]) by aplegw01.jhuapl.edu with ESMTP id 353gfa2f6n-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Tue, 01 Dec 2020 09:53:08 -0500
X-CrossPremisesHeadersFilteredBySendConnector: APLEX04.dom1.jhuapl.edu
Received: from aplex01.dom1.jhuapl.edu (128.244.198.5) by APLEX04.dom1.jhuapl.edu (128.244.198.162) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Tue, 1 Dec 2020 09:52:52 -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; Tue, 1 Dec 2020 09:52:52 -0500
From: "Birrane, Edward J." <Edward.Birrane@jhuapl.edu>
To: Martin Duke <martin.h.duke@gmail.com>, The IESG <iesg@ietf.org>
CC: "draft-ietf-dtn-bpsec@ietf.org" <draft-ietf-dtn-bpsec@ietf.org>, "dtn-chairs@ietf.org" <dtn-chairs@ietf.org>, "dtn@ietf.org" <dtn@ietf.org>, Scott Burleigh <Scott.C.Burleigh@jpl.nasa.gov>
Thread-Topic: [EXT] Martin Duke's Discuss on draft-ietf-dtn-bpsec-24: (with DISCUSS and COMMENT)
Thread-Index: AQHWx223Qo/xp4y5BEOSYjrH9LTjdaniRLfQ
Date: Tue, 1 Dec 2020 14:52:51 +0000
Message-ID: <111020090bb94c33be01c60fb7830dd3@aplex01.dom1.jhuapl.edu>
References: <160677770739.25234.13578066782905891111@ietfa.amsl.com>
In-Reply-To: <160677770739.25234.13578066782905891111@ietfa.amsl.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: APLEX04.dom1.jhuapl.edu
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.312, 18.0.737 definitions=2020-12-01_07:2020-11-30, 2020-12-01 signatures=0
Archived-At: <https://mailarchive.ietf.org/arch/msg/dtn/2uhdlj8_cROpXVLjS2Ti_n3vF6k>
Subject: Re: [dtn] [EXT] Martin Duke's Discuss on draft-ietf-dtn-bpsec-24: (with DISCUSS and COMMENT)
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, 01 Dec 2020 14:53:31 -0000

Martin,

  Thank you for the read and updates.  My comments are in-line below and I have numbered the Discusses as D# and the comments as C# in my response.

-Ed


Edward J. Birrane, III, Ph.D.
Embedded Applications Group Supervisor
Principal Staff, Space Exploration Sector
Johns Hopkins Applied Physics Laboratory
(W) 443-778-7423 / (F) 443-228-3839

> -----Original Message-----
> From: Martin Duke via Datatracker <noreply@ietf.org>
> Sent: Monday, November 30, 2020 6:08 PM
> To: The IESG <iesg@ietf.org>
> Cc: draft-ietf-dtn-bpsec@ietf.org; dtn-chairs@ietf.org; dtn@ietf.org; Scott
> Burleigh <Scott.C.Burleigh@jpl.nasa.gov>ov>; Scott.C.Burleigh@jpl.nasa.gov
> Subject: [EXT] Martin Duke's Discuss on draft-ietf-dtn-bpsec-24: (with
> DISCUSS and COMMENT)
> 
> ----------------------------------------------------------------------
> DISCUSS:
> ----------------------------------------------------------------------
> 
> - Is this meant to obsolete RFC 6257?

[D1] No. Were BPSec to obsolete RFC6257 that would imply that one should use BPSec in circumstances where one would otherwise use RFC6257. But, BPSec is specific to BPv7 (bpbis) and RFC6257 is specific to BPv6 (RFC5050). These two security protocols are specific to the version of BP because of structural differences between BPv7 and BPv6. 


> - Section 3.8 says "BCB blocks MUST NOT have the 'block must be removed
> from bundle if
>       it can't be processed' flag set." However, the notes for this section ask
>       that "designers carefully consider the effect" of setting this flag. I
>       presume the latter should have been deleted?

[D2] In BP, there are 2 different flags: "delete the block if the block cannot be processed" and "delete the bundle if the block cannot be processed".  The main body of section 3.8 refers to the first flag. The notes section refers to the second flag.

> - Sec 11.3 specifies an unsigned integer with certain meanings attached to
> negative values.

[D3] Agreed. This was discussed/discovered as a typo in the last DTNWG meeting. I updated BPSec (bpsec-25) to correct this error.
 
 
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
> 
> Sec 3.1 While there is no formal IETF policy, there has been some concern
> that "MITM" is exclusionary. How would you feel about replacing this with
> "On-Path Attacker" and "Mallory" with a suitable replacement (Olive?)?

[C1] I am completely in favor of removing exclusionary language. I have updated BPSec (bpsec-25) to make these changes. IMO, these changes do not alter the technical content of the security protocol nor do they make other parts of the protocol more difficult to understand. 

> I am somewhat unsure of the implications of Section 3.9, where the
> waypoint is supposed to delete the BIB and replace it with another BIB.
> Presumably, policies will generally require authentication from a specific
> source? I kept waiting for some discussion of these issues in 3.9, 7, and/or
> 8.2.2, and was disappointed. There are many ways to resolve this, including
> just explaining that I'm wrong, but text in 3.9 like "this technique is
> incompatible with policies that require integrity checking with the bundle
> source as security source" or something to that effect would be one way.

[C2] We discuss these issues as part of section 2.2 "Multiple Security Sources".  That section clarifies that a security operation occurs between a security source and a security acceptor which might not be the bundle source and bundle destination.  If one needs more certainty in selecting a specific security destination, mechanisms such as bundle-in-bundle encapsulation can be used. 

I agree that policy at a waypoint and policy at a bundle destination could be incompatible, and that policy misconfigurations in general are possible. But I am unsure that we need to state this in the BPSec specification beyond what is already in section 2.2.