Re: [dtn] BPbis - mandatory BPsec

"R. Atkinson" <rja.lists@gmail.com> Wed, 29 July 2020 13:16 UTC

Return-Path: <rja.lists@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 46D213A0ADE for <dtn@ietfa.amsl.com>; Wed, 29 Jul 2020 06:16:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level:
X-Spam-Status: No, score=-2.098 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, 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 UFTKstJElPgZ for <dtn@ietfa.amsl.com>; Wed, 29 Jul 2020 06:16:43 -0700 (PDT)
Received: from mail-qk1-x72a.google.com (mail-qk1-x72a.google.com [IPv6:2607:f8b0:4864:20::72a]) (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 4CB733A085A for <dtn@ietf.org>; Wed, 29 Jul 2020 06:16:43 -0700 (PDT)
Received: by mail-qk1-x72a.google.com with SMTP id l64so15292789qkb.8 for <dtn@ietf.org>; Wed, 29 Jul 2020 06:16:43 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:content-transfer-encoding:mime-version:subject:date:references :to:in-reply-to:message-id; bh=sjkwRsa+yIzimAO1vWhSoaRTyDm9SYdlQ1X15X5t8sI=; b=RHumbxFHzW2WFSRwfYG3zovxTKw8oqVp2Qz0b0z29nj2vFHolyS9QI200W/DvM7eks wJnCJGYfsF8SBIKaLbelCplPgRCyGsd2hlZcpVwwY6bp2wHk+tlNINYHI2rE8MWHmDR1 L9olLAvYWpaQPIYiGL6IWYi9iJZ6dplPWUy05tAuN84sl1PeUlKI0wIJTSExFFKwlH8u Q8UONRJNYoJP55RiQ8gM/vABqQOfQeHSdFwaJA4AgsmJAcUqeAxDCiYnuv75f0oTufFb JWRuBLsvZIOepzrKFkbI75RiZ96MWFUgHAu8iNHCtQ85RU5ByBBlXN0EX9pvhOo1d8Do fK4A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:content-transfer-encoding:mime-version :subject:date:references:to:in-reply-to:message-id; bh=sjkwRsa+yIzimAO1vWhSoaRTyDm9SYdlQ1X15X5t8sI=; b=S6R3DrtLvy92c+LHuHJEfoGoqAbwnr9X/8+PRgTu7tF8cVmOuE1gpRUjKvl6l0iZ5w UgVUpFeqE0yauT1oO5LmirPYvMSHyjK06wMdHVACrYEshc9bsMSxopGkscE1PnDS71vJ RA/3L9kAwH7cu7m6YO66lWO6CmqvW1NkiPK06IbWIejrbUMrYPHQmOxqeJzw3n4uW5V2 9cUcm35f4X2Yc6itVu/wKF2Ls9CFmspYuROJdSR+ZdnU9riFX5ExBW8i81TbxIFnne7H D0ZrsdUmA2jnEoen/S+0zowgQMSLFbOCMvKOnxdN/rRkfW4FSRExI1NUpZ76vvGhxmA7 0vkg==
X-Gm-Message-State: AOAM530yRjg2MfF8Ju4FAT0hTK+mGMihh5lvO9A4CZH2UzTazOfIF7kt KX3xSs8OHMg3TxCjgNR0a+c/SbJD
X-Google-Smtp-Source: ABdhPJxuPBE07eIy/X8/ImrF/v+HrhyaehgqBN51q+MXBM5PFMmCc9hffIKzlfMi7iqifp09mMPPSA==
X-Received: by 2002:a37:4ccc:: with SMTP id z195mr32292411qka.270.1596028602199; Wed, 29 Jul 2020 06:16:42 -0700 (PDT)
Received: from [10.30.20.24] (pool-141-156-180-77.washdc.fios.verizon.net. [141.156.180.77]) by smtp.gmail.com with ESMTPSA id x12sm1810261qta.67.2020.07.29.06.16.41 for <dtn@ietf.org> (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Wed, 29 Jul 2020 06:16:41 -0700 (PDT)
From: "R. Atkinson" <rja.lists@gmail.com>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.14\))
Date: Wed, 29 Jul 2020 09:16:40 -0400
References: <4da9776f577e4f09b5e8d248437e5f3a@jpl.nasa.gov>
To: DTN WG <dtn@ietf.org>
In-Reply-To: <4da9776f577e4f09b5e8d248437e5f3a@jpl.nasa.gov>
Message-Id: <EA340974-935B-4343-9E4B-4CC00040FB6A@gmail.com>
X-Mailer: Apple Mail (2.3445.104.14)
Archived-At: <https://mailarchive.ietf.org/arch/msg/dtn/T6PSBOuZQBm9TZ48D72-uO-2buQ>
Subject: Re: [dtn] BPbis - mandatory BPsec
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: Wed, 29 Jul 2020 13:16:45 -0000

All,

The usual and decades-long IETF practice is that “security is mandatory to implement, but optional to use”.

If security is NOT mandatory to implement, then experience shows it is unlikely to be widely available for users (or sessions) who wish to use security.

All that noted, I think Edward Birrane at JHU/APL had a possibly useful construct:
% I agree that a BPA which does not source, verify, or accept security blocks 
% does not need to implement BPSec.

I would invert that sentence, but (I think) keep the same intention.  I propose adding the quoted two sentences just below to the Security Considerations:

“A Bundle Protocol Agent (BPA) which sources, verifies, and/or accepts a Bundle MUST IMPLEMENT support for BPsec.  Use of BPsec for a particular Bundle Protocol session is optional.”

This means that any BPA which doesn’t provide any of those (source/verify/accept) services need not implement BPsec.  For example, a pure forwarder would not need to implement BPsec.

The text above tries to crisply differentiate implementation from actual use by any particular BP session, in part because long-standing IETF practice is to levy requirements on implementations but (generally) avoid specifying mandatory operational practices (e.g., RPF filtering for IP routes is a BCP but is not a hard requirement.)  

In the context of BP and DTN, it is easy to imagine deployments/environments where high-assurance link-layer communications security might be provided, thereby significantly reducing the potential value of BPsec for a given BP session.

I think the text above will go a long way towards keeping the IETF Security Area happy and greatly reducing the chances of security-related objections during the approval process.

I really think some form of “mandatory to implement” text for BPsec is important.

Yours,

Ran

> On Jul 28, 2020, at 20:49, Burleigh, Scott C (US 312B) <scott.c.burleigh=40jpl.nasa.gov@dmarc.ietf.org> wrote:
> 
> Hi.  At IETF-108 there was discussion on whether implementation of the BPsec security extensions should be mandatory in every BP node.  Version 26 of the BPbis I-D (now posted) includes some revision to the first paragraph of section 9.0 to address this question.  It would be helpful to discover the WG consensus on this matter.
>  
> Please use this thread for your comments.
>  
> Scott
> _______________________________________________
> dtn mailing list
> dtn@ietf.org
> https://www.ietf.org/mailman/listinfo/dtn