Re: [dtn] Benjamin Kaduk's Discuss on draft-ietf-dtn-tcpclv4-18: (with DISCUSS and COMMENT)

"R. Atkinson" <rja.lists@gmail.com> Tue, 27 October 2020 14:42 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 1B4593A0B38 for <dtn@ietfa.amsl.com>; Tue, 27 Oct 2020 07:42:36 -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 K6HgwqGf_ULm for <dtn@ietfa.amsl.com>; Tue, 27 Oct 2020 07:42:34 -0700 (PDT)
Received: from mail-qk1-x72c.google.com (mail-qk1-x72c.google.com [IPv6:2607:f8b0:4864:20::72c]) (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 9AE313A0B37 for <dtn@ietf.org>; Tue, 27 Oct 2020 07:42:34 -0700 (PDT)
Received: by mail-qk1-x72c.google.com with SMTP id j129so1352711qke.5 for <dtn@ietf.org>; Tue, 27 Oct 2020 07:42:34 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=JupFbDFZdOykbDIlHsIfE/VHFSIQmDPwqBc+MQo2V8s=; b=vSQ6B1pl8el3Opy39mMbHPc1ZlljY+hitVFPkgCw08UWYEGBFdt7lSIDMf92dhMbaF lSqObUZXM3eUv7dZXMgR1pBwAsgTOwsZM0XmNGz/IOP3MQObw9Yw5cwRKKthnwOmDdYT O1fGyx9m190IlLen+mEfr6bxAdkWj59fWBk6xJlr89Iz1KN+fQvpovGk10uYVHpfiQPY T4Bg2u01m8d7caBlr670j6jLFkUkqFZWfvVgWsdNlnbwQYmQQEqwsx3gA8nb2Q7stkop JIwu6MU4W2fhHXi6S37uY9mt2uMZRrEwXw+BQJ3VP6TQ3K3FqyOeV4rdJVsoxWNllQQH ZQDQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=JupFbDFZdOykbDIlHsIfE/VHFSIQmDPwqBc+MQo2V8s=; b=ig+awwA9aWHhyO/KkL0Hr9s1q0k18xlMrKHpi0fOwP7FPu1sClz4g7e7E1i7UE974U jyKPTPgng5vvpbtkpyZf3HQxWBpIdT+v2IBdC5Ul9eC5z3MBectktRD0L0Lju89YSyXG A4NkNYf09FmGo+AtZFk4eJS9gFTEx6kP6vEvgVmdn5Tc9WRVNKJsXAvlKhAJjclEadyT 8RGBzh7gl2agytC7J6TTcGIjASI5yspKXv300n420o+X2kCKZZsL3uSPdyIeIYUYT6V7 qmDQ1lJWX0OAP4mZt6N/y2A+ARCNApgCvP4qRQCFN5wWqUCDv5KsE1SjoXi6NgCUWuex G5iQ==
X-Gm-Message-State: AOAM5326c8B5IoAOCupmtRr2qHFn32y9hAsh1jwFbCP1MAzbeDnM0mFN utZuMwXTcSaDaRQd5QB22J5w4GQXjvU=
X-Google-Smtp-Source: ABdhPJzwPIoS2lWtLeHhXlP/Xj3yaghWu13leu8BgJvwbnTKDMZ9VZMXpo/vGUsiVkM6FAZAmKxLJw==
X-Received: by 2002:a37:7e41:: with SMTP id z62mr2350020qkc.495.1603809753306; Tue, 27 Oct 2020 07:42:33 -0700 (PDT)
Received: from [10.30.20.28] (pool-141-156-180-77.washdc.fios.verizon.net. [141.156.180.77]) by smtp.gmail.com with ESMTPSA id b191sm789372qkg.81.2020.10.27.07.42.32 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 27 Oct 2020 07:42:32 -0700 (PDT)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.17\))
From: "R. Atkinson" <rja.lists@gmail.com>
In-Reply-To: <MN2PR13MB3567B7727DF06411E47A826A9F160@MN2PR13MB3567.namprd13.prod.outlook.com>
Date: Tue, 27 Oct 2020 10:42:31 -0400
Cc: Benjamin Kaduk <kaduk@mit.edu>, "dtn@ietf.org" <dtn@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <6D6A8A1F-69C2-4B2B-B8B3-464C680D9A3D@gmail.com>
References: <158215235500.17580.7759757155303566523.idtracker@ietfa.amsl.com> <50c5dae1bc26ade7d0fcd9388873665868f7284c.camel@rkf-eng.com> <20201001015416.GE89563@kduck.mit.edu> <MN2PR13MB3567B7727DF06411E47A826A9F160@MN2PR13MB3567.namprd13.prod.outlook.com>
To: DTN WG <dtn@ietf.org>
X-Mailer: Apple Mail (2.3445.104.17)
Archived-At: <https://mailarchive.ietf.org/arch/msg/dtn/2aVjkQAkMYl_2_mwTYZT00Obl9w>
Subject: Re: [dtn] Benjamin Kaduk's Discuss on draft-ietf-dtn-tcpclv4-18: (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, 27 Oct 2020 14:42:36 -0000


> On Oct 26, 2020, at 23:49, Brian Sipos <BSipos@rkf-eng.com> wrote:

> It's also inconsistent with a desire
> to make TLS support mandatory to implement (but not mandatory to use),
> since mandatory to implement implies mandatory to be "capable of
> exchanging messages with TLS", thus mandatory to use.

The quote above is a confusion, I think. 

Please bear with me while I try to explain why that claim about “mandatory
to use" is only a confusion, not what “mandatory to implement” actually means.

The key distinction is that “mandatory to implement” means something must
be fully implemented and supported in the code (or logic if one were to have a
a Verilog implementation), but it does NOT mean that it have a default run-time 
configuration of “security is enabled”.

As a trivial example, possibly unrealistic in life but still useful for understanding...

 Some implementation (which I will call “X”) of DTN implements support for BPsec
 and TLS, but it also has a *user* (or maybe system administrator) configurable 
 switch which allows TLS to be enabled or disabled for a given system which has
 that implementation X installed on it.

 Such a switch might have various degrees of granularity,  It could be set
 to default to respond to TLS but not initiate TLS.  It could be set to try to
 initiate TLS but continue without TLS if the other end is not willing to do TLS.
 Ideally, it would enable security to be invoked on a per DTN-session basis,
 perhaps through some API.
 
 As an example from another protocol family, one’s smart phone handset almost
 certainly _implements_ AH, ESP, and IKE.  That doesn’t mean that the handset
 will respond to an unsolicited IKE initiation packet from an unknown remote IP
 address.  Many IPsec deployments have been _configured_ to ignore unsolicited
 IKE packets, for example.  One’s smart phone likely drops unsolicited / unexpected
 incoming IKE initiation packets, unless it has been configured otherwise in some
 manner.  

 (Example: For an iPhone, the “managed deployment” software generally provides
 ways for a corporate IT department to automatically bring up an IPsec VPN, an
 SSL/TLS VPN, or to have some security-protocol policies configured a certain way
 inside the smart phone handset.)

 Common UNIX implementations of AH, ESP, and IKE use setsockopt() to enable
 and/or configure the use of AH or ESP for a given IP session.  On my Mac, the
 most immediately relevant man pages (man pages are only accessible if one has 
 developer tools installed on MacOS, AFAIK) are:
     setsockopt(2)
     sysctl(8)
     ipsec(4)

 On other flavours of UNIX, the relevant set of man pages might vary.

 So to use IPsec for a given IP session, one probably has a line of code which
 invokes setsockopt() with the applicable socket option to enable IPsec.  This
 might manifest in an application as a command-line switch or flag, for example.

So, to be very clear, the IETF meaning of “mandatory to implement” is that ALL
implementations must support the feature/capability.  It does NOT mean that a
given _deployment_ of that implementation on a _particular system_ is required 
to configure that capability to be on by default.

Yours,

Ran