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

Martin Duke <martin.h.duke@gmail.com> Thu, 10 December 2020 19:38 UTC

Return-Path: <martin.h.duke@gmail.com>
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 0B79D3A123F; Thu, 10 Dec 2020 11:38:59 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level:
X-Spam-Status: No, score=-2.097 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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, 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=gmail.com
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 3fOfCfn62dTP; Thu, 10 Dec 2020 11:38:57 -0800 (PST)
Received: from mail-io1-xd2e.google.com (mail-io1-xd2e.google.com [IPv6:2607:f8b0:4864:20::d2e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2C5633A123D; Thu, 10 Dec 2020 11:38:57 -0800 (PST)
Received: by mail-io1-xd2e.google.com with SMTP id q137so6793961iod.9; Thu, 10 Dec 2020 11:38:57 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=lUnYdVNdOndOVxRXqdnRMDhGK+bAs+vv5o7j/aJVQEg=; b=Gz4+HAV8Emx821OjCaJVJsfSxBykbklYgSl3uU4ncbQuzBcg2yL8ECWtsD+FDm/kAi 8T7d3bCI3N+QzvhfnIV7KENWqP5vX4XGglSmfqOfTTBKaxiyxYs+SoqoQqAacnivhkYS Ubi0Mt2MeE7lNwGVuBKAGGg2ningcHQzbxLbfY46D5JI9HwdtdU+mE0JCfsU9uMZuujh 7Ow/A/YOTue25Qfuaepuj5cC3mGpS3K0EVX7YWjkdW9S/uMHZf1iB+TyQdC7dexW9sZ0 YHJxkJYD7RaFIw4571ZiwZQlbN5Z7UFg8sJpPXPs6zwnJ8HqKNZeLxjjAhURb0KQYdLD goJA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=lUnYdVNdOndOVxRXqdnRMDhGK+bAs+vv5o7j/aJVQEg=; b=jg+dMXe5SMTZ1+Gzebnl232TzGKiK7EELCbjmL/beMkDlqf6EuXmXpQ/nHhYHRwOYJ LAYztwFia6jb8JSEp6NXV4WndRRn77aynd336Zbaar1EsEccEIFnhm4K4YBkqFjHOLhC YBZHTejj+dji1ptcqcOBwkx5N+xXTsETN8zZ6vubEzO4E4na1ibEN6y1V5m0wk14IEnW f70rcLw3u0IQVXVauteNe+8lh77oAGV8/7d8uTZGy/qD5Lwyue3zDgbXBYErInyETrN4 ESoLcvab3GJ86DC5OjTelQhQG22giGSWZucoLECIeRXzKSf70YCaSSdpBcnkA6zKicE5 CMkw==
X-Gm-Message-State: AOAM533t02Vf5t07h8PMPWzMXHKtvZGj+K515glaIqQjL9j+ffo4JaIk oNxJe0JAf/FZzmLT0x+cjM0a6U9JIiW1fabAEN4=
X-Google-Smtp-Source: ABdhPJxJq2dOgyz7k91OR8R8LSgcjhmlWh0d9R5KfpSXzplhN0i2FLoqklXx573RXMTx9/JQiDznia+yoIBv5/5U/Qc=
X-Received: by 2002:a6b:7906:: with SMTP id i6mr9861277iop.97.1607629136434; Thu, 10 Dec 2020 11:38:56 -0800 (PST)
MIME-Version: 1.0
References: <160677770739.25234.13578066782905891111@ietfa.amsl.com> <111020090bb94c33be01c60fb7830dd3@aplex01.dom1.jhuapl.edu>
In-Reply-To: <111020090bb94c33be01c60fb7830dd3@aplex01.dom1.jhuapl.edu>
From: Martin Duke <martin.h.duke@gmail.com>
Date: Thu, 10 Dec 2020 11:38:45 -0800
Message-ID: <CAM4esxTZ8gHZGcWfhHPwniJxKXw-WOTX32FzG5gB=_BU6eu_6w@mail.gmail.com>
To: "Birrane, Edward J." <Edward.Birrane@jhuapl.edu>
Cc: The IESG <iesg@ietf.org>, "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>
Content-Type: multipart/alternative; boundary="0000000000009b9b1905b621538d"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dtn/A0vv_kIwRa-f1SZRHvnn9NHpRCw>
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: Thu, 10 Dec 2020 19:38:59 -0000

This looks good, sorry for all the mistakes.

On Tue, Dec 1, 2020 at 6:53 AM Birrane, Edward J. <Edward.Birrane@jhuapl.edu>
wrote:

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