Re: [dtn] BPSec optional Security Source

"R. Atkinson" <rja.lists@gmail.com> Mon, 04 January 2021 23:21 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 6A86B3A09E8 for <dtn@ietfa.amsl.com>; Mon, 4 Jan 2021 15:21:58 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.198
X-Spam-Level:
X-Spam-Status: No, score=-0.198 tagged_above=-999 required=5 tests=[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 mQJvIuJrMGAe for <dtn@ietfa.amsl.com>; Mon, 4 Jan 2021 15:21:56 -0800 (PST)
Received: from mail-qv1-xf34.google.com (mail-qv1-xf34.google.com [IPv6:2607:f8b0:4864:20::f34]) (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 B13983A09D7 for <dtn@ietf.org>; Mon, 4 Jan 2021 15:21:56 -0800 (PST)
Received: by mail-qv1-xf34.google.com with SMTP id s6so13868885qvn.6 for <dtn@ietf.org>; Mon, 04 Jan 2021 15:21:56 -0800 (PST)
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=pPbDL2uyHAk9Y9ngr51vgaFBARzYUcZeH/FpYGWPR0U=; b=RAln9ZdLxNrygwzaZ0NrLfKKkkLX6Y1V1zBnmYL2xRxFvVVi2KFMTISBi9ITP/jRIj /tuIlKDQdsXsUVsbyBHvuxTfmiBku+SN1SBB4gse/fZAPS3CiGxIpWwXlQO+rBRiiHoG 7Z2EfAfy6gii+lpzmP45i4Skj3U1FoCeVwcPhqBixyOf67TXY5tRWb9+kv+d+tDy1mIe TyBLJej3XRWzd+wDNRwnoMwBAfKbupu1DpulQR51mdlBr7ML1JOtf+2hkUdr+kSW/lPc V8RFeXd4jJm+7t/1ZlNeuiWa3L97Am32Y22BPz4oGSO1WDIEjyoRISDEYcEPBE1Dta3q EjQQ==
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=pPbDL2uyHAk9Y9ngr51vgaFBARzYUcZeH/FpYGWPR0U=; b=OsAd4y2lxpMbWdSa8RLml/98sxHy5yslsiWeC/nC7nlgqILkPS/xIkntpxHUuj8zgh GutfOcYr9xBFC04OjGQpQoyV7wRyWCG34QLkLfk+GDFlZ1TnW71jyINPon8EEZosvzjL 0d9pyjPPCbrDgEY6KRw+ZlSADfaYzou4l5AHah+S6qyd6Rp9SOGNxLbbArKIz5VBIYuB HC5bBbe1ukMV4n0nXowV/McmXtXNEx5paa/xwrXoUeG24sW9WmntEs0zzRhNl6r+RI2z sHBgm7QGWKysLONHqqh5LxcgeW8KJ6xpfFr270DqZyaWnGRRPNIgdPkbOAc0uysY4wGM UWEQ==
X-Gm-Message-State: AOAM533f12nZQDwXc01wC3REkBYO2SmYNyDmPJ70ynZrSTQm7sSBDo9P Kv/n+IL4HZzf++kL0USB9GBjuR74cMQ=
X-Google-Smtp-Source: ABdhPJyazn7RE9HI8SR0sylOMYHMyWYku9zXf6FzF6n51xtwrYY486D+gz/1IVC7Ng6tn/Tzs+/9qw==
X-Received: by 2002:a05:6214:1754:: with SMTP id dc20mr78308452qvb.7.1609802515501; Mon, 04 Jan 2021 15:21:55 -0800 (PST)
Received: from [10.30.20.27] (pool-141-156-180-77.washdc.fios.verizon.net. [141.156.180.77]) by smtp.gmail.com with ESMTPSA id 16sm25787489qkf.112.2021.01.04.15.21.54 for <dtn@ietf.org> (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Mon, 04 Jan 2021 15:21:54 -0800 (PST)
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 13.4 \(3608.120.23.2.4\))
Date: Mon, 04 Jan 2021 18:21:53 -0500
References: <MN2PR13MB356798402CA7086AAEDDC0649FC50@MN2PR13MB3567.namprd13.prod.outlook.com> <82edb601dc6e4d86bef9c2a80b0dc9fc@aplex01.dom1.jhuapl.edu> <MN2PR13MB35670E69E788A5423B7F39E39FD20@MN2PR13MB3567.namprd13.prod.outlook.com>
To: DTN WG <dtn@ietf.org>
In-Reply-To: <MN2PR13MB35670E69E788A5423B7F39E39FD20@MN2PR13MB3567.namprd13.prod.outlook.com>
Message-Id: <AB61EC38-92F6-4186-A2AC-999EBB1511B7@gmail.com>
X-Mailer: Apple Mail (2.3608.120.23.2.4)
Archived-At: <https://mailarchive.ietf.org/arch/msg/dtn/kaUE-PIc-gSbywvytflrbKUTqWo>
Subject: Re: [dtn] BPSec optional Security Source
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, 04 Jan 2021 23:21:58 -0000

All,

For the sake of interoperability, maybe just say the “Security Source EID always must be present.”  It seems terribly optimistic to think the sender will have a priori knowledge of what downstream nodes plan to do.

Always including it might cost a few bytes, but doesn’t preclude a local policy at some node to look at other things, but including it always definitely helps with interoperability.

Postel’s Law:
	Be conservative in what you send and liberal in what you receive.

“Conservative” in this case means including the Security Source EID always - even if some downstream node did not require that datum some of the time.

Yours,

Ran

> On Jan 4, 2021, at 16:45, Brian Sipos <BSipos@rkf-eng.com> wrote:
> 
> Ed,
> Thanks for that clarification. Could this be added to the spec itself?
> Right now, as you mention, there is a requirement on the how the security acceptor handles that field but no requirement or expectation on the security source. It seems like that Security Source EID is expected to be present and it's a special case (based on network knowledge) that it would be absent. I mistakenly made the opposite assumption.
> e.g. The Security Source field SHOULD be present unless all security verifiers and acceptors are known to infer the correct implied security source.
> 
> Slightly related about terminology, that Security Source is defined as "This field identifies the Endpoint that inserted the security block in the bundle." But is the real situation that the source isn't an arbitrary endpoint but must always be a BP node (with a Node ID). Section 1.4 mentions that the security source has a Node ID and not a more general Endpoint ID.
> 
> Also, there are several places in the document where "security verifier" is used but that isn't present in Section 1.4 terminology listing. Can this be clarified? I assume a verifier is an acceptor which only performs read-only security operations related to a bundle. Maybe that's the wrong exact phrasing.
> From: Birrane, Edward J. <Edward.Birrane@jhuapl.edu>
> Sent: Monday, January 4, 2021 15:52
> To: Brian Sipos <BSipos@rkf-eng.com>; dtn@ietf.org <dtn@ietf.org>
> Subject: RE: BPSec optional Security Source
>  
> Brian,
>  
>   I agree that it is a little inefficient to include a security source EID in a security block when that EID is the exact same as the bundle source.  However, I would prefer to not have BPSec prohibit this duplication.
>  
>   BPSec states that if a security source EID is not present, then “the source MUST be inferred from other information, such as the bundle source, previous hop, or other values defined by security policy.”
>  
>   What if local policy on a BPA requires that, absent an asserted security source EID, the security source EID should be inferred as being the previous hop? In such a case, omitting the security source because it was the same as the bundle source would result in undesired behavior.
>  
>   Omitting a security source EID should be done when the security source node “believes the network can infer the security source correctly” which is different than saying “whenever it is the same as the bundle source”.  In many cases those two statements have the same practical result, but not in every case.
>  
> -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
>  
>  
> From: Brian Sipos <BSipos@rkf-eng.com> 
> Sent: Wednesday, December 16, 2020 11:55 AM
> To: dtn@ietf.org; Birrane, Edward J. <Edward.Birrane@jhuapl.edu>
> Subject: [EXT] BPSec optional Security Source
>  
> APL external email warning: Verify sender BSipos@rkf-eng.com before clicking links or attachments
>  
> Ed,
> My interpretation of the purpose of the ASB Security Source field is to indicate the EID only if it's different than the bundle's source, but there's no actual requirement that I can see in the spec about this. Does it seem like a reasonable statement to say something like "If the security source EID is the same as the bundle source EID, as identified in the primary block, the Security Source field SHALL NOT be included in the ASB." but rephrased as needed?
> Thanks,
> Brian S.
> _______________________________________________
> dtn mailing list
> dtn@ietf.org
> https://www.ietf.org/mailman/listinfo/dtn