IETF Logo Mail Archive

Re: [dtn] TCPCLv4 comments

Brian Sipos <BSipos@rkf-eng.com> Thu, 30 March 2017 13:01 UTC

Return-Path: <BSipos@rkf-eng.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 8AA591294C3 for <dtn@ietfa.amsl.com>; Thu, 30 Mar 2017 06:01:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=rkfeng.onmicrosoft.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 2a1Upi1tJw-1 for <dtn@ietfa.amsl.com>; Thu, 30 Mar 2017 06:01:05 -0700 (PDT)
Received: from NAM01-SN1-obe.outbound.protection.outlook.com (mail-sn1nam01on0078.outbound.protection.outlook.com [104.47.32.78]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 29FAD129451 for <dtn@ietf.org>; Thu, 30 Mar 2017 06:01:05 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rkfeng.onmicrosoft.com; s=selector1-rkfeng-com0i; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=E3KleHIRd0xpgOBNK3v74y8JYDF4TZClfnX1ENJJ2W0=; b=UhpSTgjAl+eb3UbzA7xzduO8nz5HntCKBPbFU+cBZED3c/uG+97dyDVih1Uqv7fT+nQxI1OHVcUudUkpJ8PcsJ4nTqj8id69FLa4Zpj7Z2frN5vVMMZsslSZA8nR5LCenKkEnceUudmgfGbd8wJMgIm6PAIQEKUrz+PnjaJeTEM=
Received: from CY1PR0501MB2057.namprd05.prod.outlook.com (10.164.3.19) by CY1PR0501MB2059.namprd05.prod.outlook.com (10.164.3.21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1019.8; Thu, 30 Mar 2017 13:01:03 +0000
Received: from CY1PR0501MB2057.namprd05.prod.outlook.com ([10.164.3.19]) by CY1PR0501MB2057.namprd05.prod.outlook.com ([10.164.3.19]) with mapi id 15.01.1005.014; Thu, 30 Mar 2017 13:01:03 +0000
From: Brian Sipos <BSipos@rkf-eng.com>
To: "R. Atkinson" <rja.lists@gmail.com>, "dtn@ietf.org" <dtn@ietf.org>
Thread-Topic: [dtn] TCPCLv4 comments
Thread-Index: AQHSqJUuxtf83Vq7Iki5g7Vd50UA+qGtWDaT
Date: Thu, 30 Mar 2017 13:01:02 +0000
Message-ID: <CY1PR0501MB205796F31CF1B34014FD21349F340@CY1PR0501MB2057.namprd05.prod.outlook.com>
References: <B12E55E1-5073-4A3B-98A5-8F0647B96101@gmail.com>
In-Reply-To: <B12E55E1-5073-4A3B-98A5-8F0647B96101@gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: gmail.com; dkim=none (message not signed) header.d=none;gmail.com; dmarc=none action=none header.from=rkf-eng.com;
x-originating-ip: [132.245.44.5]
x-microsoft-exchange-diagnostics: 1; CY1PR0501MB2059; 7:KIP3dxeuCJFKBYTs4p98ayh1DPIikeF0LCVI94HosEIXwpG7+bbM06BWxRRBf/wJI/aeTioRjGb/RDDbLdPyVoQnFWRsvqM/VHq/aiXInwS1leYA3zctbKz+LTEIMjWPp997uawZ4ofQL7x0s9P55a8V5bNIw/c9+3SLL9vYJE02bEkLqyMDa4hGax7eK9SrM29+2G7Bpu/04dSiQVok8+w+dD73/9hmljF72qLRD0KGdQiE4xd+oEwJQ+4T/kXhuZegB9evR9fSIIhMEZzNui+SVfkI9WD4yHiioSNoxF1yMCM7uDxfHPYI8Xxm5GBnbijVTGQ1fZcUCaC5g0AT4g==
x-ms-office365-filtering-correlation-id: 083815b7-40b8-4732-1a5c-08d4776cd20c
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(201703131423075); SRVR:CY1PR0501MB2059;
x-microsoft-antispam-prvs: <CY1PR0501MB2059138D4BB11D86299CE5F69F340@CY1PR0501MB2059.namprd05.prod.outlook.com>
x-exchange-antispam-report-test: UriScan:(158342451672863)(192374486261705);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040450)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(6041248)(201703131423075)(201702281528075)(201703061421075)(20161123562025)(2016111802025)(20161123560025)(20161123555025)(20161123564025)(6072148)(6043046); SRVR:CY1PR0501MB2059; BCL:0; PCL:0; RULEID:; SRVR:CY1PR0501MB2059;
x-forefront-prvs: 02622CEF0A
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(39400400002)(39450400003)(39410400002)(39830400002)(377454003)(7736002)(33656002)(7906003)(74316002)(102836003)(6116002)(39060400002)(38730400002)(3846002)(55016002)(25786009)(53546009)(5660300001)(80792005)(6436002)(3660700001)(53936002)(606005)(9686003)(54896002)(3280700002)(6306002)(236005)(2906002)(86362001)(99286003)(6246003)(8936002)(81166006)(7696004)(8676002)(2900100001)(76176999)(54356999)(6506006)(229853002)(50986999)(77096006)(189998001)(66066001)(2501003)(2950100002)(122556002); DIR:OUT; SFP:1101; SCL:1; SRVR:CY1PR0501MB2059; H:CY1PR0501MB2057.namprd05.prod.outlook.com; FPR:; SPF:None; MLV:ovrnspm; PTR:InfoNoRecords; LANG:en;
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_CY1PR0501MB205796F31CF1B34014FD21349F340CY1PR0501MB2057_"
MIME-Version: 1.0
X-OriginatorOrg: rkf-eng.com
X-MS-Exchange-CrossTenant-originalarrivaltime: 30 Mar 2017 13:01:02.8432 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 4ed8b15b-911f-42bc-8524-d89148858535
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR0501MB2059
Archived-At: <https://mailarchive.ietf.org/arch/msg/dtn/J_8QFwwlUDTBqCvmkIqeTyoat_c>
Subject: Re: [dtn] TCPCLv4 comments
X-BeenThere: dtn@ietf.org
X-Mailman-Version: 2.1.22
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, 30 Mar 2017 13:01:08 -0000

Ran,

The original thought behind mandatory-to-use TLS was to simplify the TCPCL state machine, but if there is a need to allow TCPCLv4 to be usable in complete absence of TLS on an endpoint (and from the discussion yesterday it sounds like yes, there is) then this is already accommodated by the current TCPCL draft. It makes use of a STARTTLS-like mechanism to upgrade a TCP connection if both endpoints support it.


With all of this in mind, would you be willing to review the current draft spec regarding the contact header and TCPCL session establishment (sections 4 and 5.3 respectively) for its completeness? Any comments in this area are very much welcome so that we can avoid any undesirable behaviors in this important area of operation.


Thank you,

Brian S.

________________________________
From: dtn <dtn-bounces@ietf.org> on behalf of R. Atkinson <rja.lists@gmail.com>
Sent: Wednesday, March 29, 2017 10:02:54 AM
To: dtn@ietf.org
Subject: Re: [dtn] TCPCLv4 comments

>  - I am absolutely fine with making TLS mandatory (my own use of TCPCL is to always require TLS),
> as it would simplify logic. Some may dislike this, but if it's easier for approval then I would prefer that.
> There would be no prohibition from somebody implementing a "TCPCLv4 without TLS" as a
> separate thing for closed networks.

The text quoted above is ambiguous, so I can’t figure out what it means.


The IETF has for about 30 years now taken 2 complementary positions on security:
  A.  Security has to be specified and Security has to be “MUST implement”, so that is is available to use in all shipping products.
  B.  Security is OPTIONAL to deploy/use and this is left as a decision for the network operator or user.


The IETF generally avoids telling operators what they have to do.  Yes, we do have a growing
number of “Best Current Practice (BCP)” documents, but that is in the category of strong advice,
rather than a standards mandate.

I concur with the long-standing IETF position on security.

So in the context of TCPCL, I believe it is very important for TLS to be “MUST implement”,
but I object to any notion that EITHER “standards-compliant deployments” OR “interoperable
deployments” MUST deploy/user” TLS.

In short, it needs to be possible to interoperate fully - whether or not - one happens
to *use* (“deploy”) TLS  for a particular TCPCL session.

Yours,

Ran

_______________________________________________
dtn mailing list
dtn@ietf.org
https://www.ietf.org/mailman/listinfo/dtn

v2.23.0 | Report a Bug | By Email