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

Brian Sipos <BSipos@rkf-eng.com> Tue, 10 November 2020 05:19 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 9C5413A0D32; Mon, 9 Nov 2020 21:19:59 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.1
X-Spam-Level:
X-Spam-Status: No, score=-2.1 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, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=rkf-eng.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 Gz6pbRX-dio8; Mon, 9 Nov 2020 21:19:56 -0800 (PST)
Received: from NAM12-MW2-obe.outbound.protection.outlook.com (mail-mw2nam12on2064.outbound.protection.outlook.com [40.107.244.64]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 79EED3A0D2F; Mon, 9 Nov 2020 21:19:56 -0800 (PST)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=DbiS7rC0MJIOCg/FKtlRwEtZzxw5EgNXARuVpfVPEPLdWJgFNIEs/FvRK6/4UgEFO1wHhMdEEVQ/CzJE7/6QfWPdYvSdHF42eqYektP6rz180mluhRQcR06zLbSguUzHdKVwHDUG46UCAiezlWKF2Ocz5xHT91RSU0cMiYOv7pjnGU5rIylEUNDj/HARECxIZNOLdszX08m1W+LiHuFINE141Dp86y6d0EzvZTTFphA6I9M0eE0C8kURku+ee9vzFuXZoHCg25zAZDn7mNA4QxfgvpRiHQuEKxFWsArWbRjulXn3W9Ys5SKyvBm1g8Xl9aSPjYnE9HPSGd8EEtJ0ng==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=KVbmFPjsoOZwUb6AfSiO8H7gXuyEC9OV92BwQ3ncMLU=; b=WGq6EFreJQKvrgTGiCNYlR2L3+fF0kUUmghs0+GjtHN08LV4tgggtxNGCZ8Cba7HJpJ/URDLQRSSJ9RHkZDSqB12MdJM0sIhjfN2FtFIXeoSu7NOXAAU7x3fekNcvBjRC9+rWUHZsyYfDg7H3hVDw3fdg/AC9oCLh+DafU04Oy0gN0HDKX6V6B1RZdBsLriFW0A6mebjA+SRHstQhxbIPrDVz4wfHrOWMH4d+9uZCE2du1Cpkm0NjqwNa5uP3cT+9IcXtHLWIHzZIGjN64ogb3dy/4/tdoIaFKv8fO9GRx5F9gvMy9hRrXEz3hkq53+eoibVJiQ6rTvbIc2s4wKkBQ==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=rkf-eng.com; dmarc=pass action=none header.from=rkf-eng.com; dkim=pass header.d=rkf-eng.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rkf-eng.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=KVbmFPjsoOZwUb6AfSiO8H7gXuyEC9OV92BwQ3ncMLU=; b=I3jpc1KWGMcr3WLZHfLaviCSNrdoYubaUxDsuZJ4toHP5lwWO/SegSkNe77GD+n8UI8jRqfZUuceU5kfDs3tVjwhvvTGX90S7/0sEYvF9YoyIRy+vfYVgvAiirFLYg7J/ffD0YKe8eaBtGFMOaXV4X7gm9diI0scIOe12Megvho=
Received: from MN2PR13MB3567.namprd13.prod.outlook.com (2603:10b6:208:168::10) by BL0PR13MB4450.namprd13.prod.outlook.com (2603:10b6:208:17d::18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3541.10; Tue, 10 Nov 2020 05:19:49 +0000
Received: from MN2PR13MB3567.namprd13.prod.outlook.com ([fe80::b90b:cb8:82cb:7d1a]) by MN2PR13MB3567.namprd13.prod.outlook.com ([fe80::b90b:cb8:82cb:7d1a%3]) with mapi id 15.20.3564.021; Tue, 10 Nov 2020 05:19:49 +0000
From: Brian Sipos <BSipos@rkf-eng.com>
To: Martin Duke <martin.h.duke@gmail.com>
CC: "iesg@ietf.org" <iesg@ietf.org>, "dtn-chairs@ietf.org" <dtn-chairs@ietf.org>, "draft-ietf-dtn-tcpclv4@ietf.org" <draft-ietf-dtn-tcpclv4@ietf.org>, "dtn@ietf.org" <dtn@ietf.org>, "edward.birrane@jhuapl.edu" <edward.birrane@jhuapl.edu>
Thread-Topic: Martin Duke's Discuss on draft-ietf-dtn-tcpclv4-22: (with DISCUSS and COMMENT)
Thread-Index: AQHWtWfzgXKYe2o4cUC4psquQl8WX6m/Ck2AgAFax4CAAF+eGg==
Date: Tue, 10 Nov 2020 05:19:49 +0000
Message-ID: <MN2PR13MB356760FBF3C9232E40C7754E9FE90@MN2PR13MB3567.namprd13.prod.outlook.com>
References: <160479610567.30934.2651041608307943087@ietfa.amsl.com> <d7b8cefdb52977bfbb99bf2608083a2f281dc807.camel@rkf-eng.com>, <CAM4esxTNouowAR_f6_WaGC7FfVabDPGjbVGjEgd4rWbBqUixYw@mail.gmail.com>
In-Reply-To: <CAM4esxTNouowAR_f6_WaGC7FfVabDPGjbVGjEgd4rWbBqUixYw@mail.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: [170.249.178.82]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 3758fd2b-f093-4207-9c76-08d885383eeb
x-ms-traffictypediagnostic: BL0PR13MB4450:
x-microsoft-antispam-prvs: <BL0PR13MB44509FFD381693E23B0A840C9FE90@BL0PR13MB4450.namprd13.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: imOa6gaK8aWG/0R8dNI8SkFvI91wdWee572jIebZPu5g9NLlBJ68x7oWBw7UxFLLP7p6Drzk6gnnMNoBzA+LozPBNOragOi6sy/KsQkdtD/d370/5//XhycAVnT6/YaPSUylzTge26GCW0HB78lIeNyHig7QxFgxnctczwd5fBgi1ZmWw87M9FnE4XPXhxv2Etxk8h+ZnzxxOkUiNik/a95VroI0F6wLBo6v9kokldbVZKMYZL4MkIzqJU13BFnoYM6ZZJH4Mu5YqtDcn0g7Yn7dhepfkbJwbWLbu2zDjCOWWNlMvRz39pDKjUUCctoqreFQnwppUOUoN3mfV7DuialU2YxADSodd984MO2XThb0oyF9zoVN61nM6xM/ITq327qYqkgOpTlSIISW9AldjQ==
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:MN2PR13MB3567.namprd13.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(396003)(376002)(39830400003)(346002)(366004)(136003)(54906003)(19627235002)(166002)(966005)(5660300002)(33656002)(8676002)(316002)(8936002)(66476007)(66446008)(53546011)(30864003)(71200400001)(52536014)(19627405001)(86362001)(55016002)(26005)(6506007)(64756008)(9686003)(6916009)(478600001)(83380400001)(76116006)(66946007)(4326008)(7696005)(2906002)(66556008)(186003)(91956017); DIR:OUT; SFP:1101;
x-ms-exchange-antispam-messagedata: 1MKJM+yGWSU1LnC/JE+BlAJwwuhFU6dFy5wlC6EzN9BK+l6hY1a4yY5j6TIROHmVm9dsQ7h/QGIE//0+exUBVFUrCCv58OdxUT9lee0c/6Ew4BQBjoyTxn7C3R3dhEfD1ryh2ZSVGe3QZ1pKetOjl7j8JkzMVXegB7wMoC8YzaOnjsyA+gzLCQTy8iQ/F1I9AWYPFdG6ZF2OrXIy6CZfqdB7eKG5AJEzBBC96gtDTUZt3GhuC4b21wsbuejfCfVI/PPn5DpSnaQOMh/a2vtSpseI+D6Mv+Y2vPZUMfpR9MZaUeiZU/FCTKPv/EvlUD17nywK6KJXIvrzQ5VLdf/EdU7KsmajjmuY/wKt1AMhQyQMnGMEy+wFuNLYz4iaJ4DegcP+/J77MLuv1VOeMt9iE6u8IiugsndLyjiBuamwwGC1tFI7px4jbGa0/AqSPRd/HVFuoAExEoHZlct5udTd/eVNAMYE4v2vit5FF+jZsu2JFSgC+7gp6AjV5QbKZXZo3OaaF3qVskCvpN6VEq1r8krV625hDwd6TlqGJdqcbYqOSV3IgHLUgF9dLKqMOBM/42AQbY244SEudylwfnEIlVhHas5vAJc+EFH7aa8aSMpT7aozitiLRIQ5qA8up1RdebXm3ElitA7R7mQxbp9Ep61bwD/gr+Ih+t1ml+yZR7HFI8CDmpasWcm82KAH/qPT2aQqvOJ6r6IiArx6u3gq9tRqMyw6f6zl/CM55D4O0nOfQcR7W+aKI9J8IB5yEJ4vYe3/odYJx+GCjsruvTVzZLD1fZ+eDjVjIoahb0itgjdxSegA3eOVvvKnXzzyz7p5HZB11ALjyVmk3odKnR+NwUKfAQ1CVunZtp16CuXialQZOX+xzG4A5/7KThVE4EN9HHAtuylYxQk+gX5mkRFp5g==
x-ms-exchange-transport-forked: True
Content-Type: multipart/alternative; boundary="_000_MN2PR13MB356760FBF3C9232E40C7754E9FE90MN2PR13MB3567namp_"
MIME-Version: 1.0
X-OriginatorOrg: rkf-eng.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: MN2PR13MB3567.namprd13.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 3758fd2b-f093-4207-9c76-08d885383eeb
X-MS-Exchange-CrossTenant-originalarrivaltime: 10 Nov 2020 05:19:49.2156 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 4ed8b15b-911f-42bc-8524-d89148858535
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: +54lDAKFd4sfTaqHaXvdPJqnOitUgjPfgBC1ERWkxm+SMG+9u6bdjQvhHeFHYejDTI8ataKlA9HTkJr1a5Pm0g==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL0PR13MB4450
Archived-At: <https://mailarchive.ietf.org/arch/msg/dtn/rR5CZgVtNVAqi9e9Z4DmURv1FbI>
Subject: Re: [dtn] Martin Duke's Discuss on draft-ietf-dtn-tcpclv4-22: (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, 10 Nov 2020 05:20:00 -0000

Martin,
This appears to be getting close. The one remaining comment is related to TLS handshake and failures.

One reason for some of this trouble, I think, is the lack of obvious pre-existing concrete requirements for the use of TLS [1] by application protocols. I'm looking through references to TLS [2] for both "proposed standard" status and "normatively references" type, and see many extensions to TLS and many references to data used by TLS but for the use of TLS I see only NTP [3] and its requirements are quite loose and certainly don't include a protocol state machine definition of how TLS fits in.

There seems to be a kind of assumption in protocol specifications that using TLS just lets the implementation of TLS "do its thing" even though TLS itself explicitly excludes doing things like certificate validation in Section 4.4.2.4:
In general, detailed certificate validation procedures are out of scope for TLS (see [RFC5280]).

The use of TLS for TCPCL has its own specific issues related to some of the certificate validation (DNS name) happening within the TLS implementation during handshake and some (Node ID) happening after the handshake has completed, when many TLS APIs don't allow injecting arbitrary Alerts into the TLS message stream. Sending a post-TLS-handshake SESS_TERM seems to be allowed by TLS itself and a reasonable way to avoid intermingling of CL-level messaging with TLS-level messaging.

Considering all that, is there a good RFC to point to as an example of a well-specified example of using TLS 1.3 (or even an earlier version) in a way which is actually compatible with TLS implementations?

Thanks again for your feedback,
Brian S.

[1] https://tools.ietf.org/html/rfc8446
[2] https://datatracker.ietf.org/doc/rfc8446/referencedby/
[3] https://tools.ietf.org/html/rfc8915
[4] https://tools.ietf.org/html/rfc5280


________________________________
From: Martin Duke <martin.h.duke@gmail.com>
Sent: Monday, November 9, 2020 17:30
To: Brian Sipos <BSipos@rkf-eng.com>
Cc: iesg@ietf.org <iesg@ietf.org>rg>; dtn-chairs@ietf.org <dtn-chairs@ietf.org>rg>; draft-ietf-dtn-tcpclv4@ietf.org <draft-ietf-dtn-tcpclv4@ietf.org>rg>; dtn@ietf.org <dtn@ietf.org>rg>; edward.birrane@jhuapl.edu <edward.birrane@jhuapl.edu>
Subject: Re: Martin Duke's Discuss on draft-ietf-dtn-tcpclv4-22: (with DISCUSS and COMMENT)

Hi Brian,

On Sun, Nov 8, 2020 at 5:49 PM Brian Sipos <BSipos@rkf-eng.com<mailto:BSipos@rkf-eng.com>> wrote:
Martin,
My responses are in-line below with prefix "BS1".

>
> First of all, "failure of the transfer" is ambiguous because there
> may be two
> transfers going on, one in each direction.
>
BS1: This phrasing is a bit unclear because the statement applies to
the transfer itself. Instead of "a transmitting node" it should be "a
node transmitting a transfer" so the subject of the statement becomes
the outgoing transfer.

Yes, that would help.


> Second, I would like further clarity on what it means that nodes
> "SHALL"
> consider it "a failure of the transfer". What is actionable if it's a
> failure?
> If nothing is actionable, it shouldn't be a SHALL. Does this mean
> that in
> subsequent sessions I must resend the whole bundle?
>
BS1: There are requirements about how a CLA interacts with its
overlaying BPA, and this requirement applies to what will be indicated
to the BPA about the formerly-in-progress transfer. Section 3.1
explains that CLA--BPA interface.

This reply makes sense. Perhaps a reference to Sec 3.1 would help?


> Can you list some reasons why an endpoint would choose to close
> uncleanly? Some
> motivation might provide helpful context.
>
BS1: The motivation here is that there are some reasons why the CLA
will know that it's about to lose connectivity and send a positive
indication of "I'm about to go away and cannot finish a transfer (in
either direction)" instead of waiting (potentially a long time) for a
CLA timeout or a TCP timeout. For example, a low battery starting into
a power saving mode and stopping a data link. This is as opposed to a
clean termination, which is not time-critical and more of a "I don't
want to start any more transfers, so don't attempt any new ones."

Thanks. Maybe add a sentence about this? "For instance, an endpoint may know it's about to lose connectivity and request abrupt termination rather than forcing a timeout."


> Moreover the "sending or receiving" bit is confusing.
> - So one option is that I'm a session that has decided to do an
> unclean
> termination rather than a clean one. So I send SESS_TERM and then
> close (FIN?
> RST?) the TCP connection. So if it's a FIN, I might very well get the
> last
> XFER_ACK.  If I RST or don't get that ACK, then I do think it's clear
> that the
> transfer is a failure, whatever that means.
>
BS1: I can add a top-level requirement that closing a TCP connection
always means using a FIN.

Thanks.


> - But as a receiver, how do I know that the termination is unclean?
> Have I made
> an independent decision to close uncleanly? Am I to take the receipt
> of a
> SESS_TERM without my having sent XFER_ACK as an unclean close? If I
> sent
> XFER_ACK, how do I know that the sender sent it? And what does it
> mean, as a
> receiver, that the transfer "failed" if I have all the data?
>
BS1: Some of these requirements may be trying to overspecify behavior
and just get confusing. There is always the potential for the TCP
connection to close for some other reason outside the CLA's control.
Maybe a better set of requirements is to mention that a peer MAY close
the connection before a transfer is finished, and that a closed
connection before receiving the final XFER_ACK SHALL be treated as a
failed transfer (even outside of an unclean termination, because at
that point there is no possibility of ever receving that final ACK).

I think that would be an improvement

Some clearer description of when an endpoint TCPCL should send close to its TCP, given receipt of a SESS_TERM and FIN, would be helpful. For most SESS_TERMs, I don't want to send FIN until I have both completed any in-progress transmission, and have XFER_ACKed all incoming segments. In the unclean case I probably want to send a FIN more or less immediately to avoid a timeout, I think (?), and some guidance on how to distinguish these cases would make this clearer.


>
> ---------------------------------------------------------------------
> -
> COMMENT:
> ---------------------------------------------------------------------
> -
>
> Thanks for this document. I have numerous minor concerns:
>
> Sec 4.3. "the TCP connection SHALL be closed." Can you clarify if
> this is a
> clean close (FIN) or abort (RST)? In fact, if you always mean FIN, it
> might be
> good to clarify that in the terminology section to indicate that
> there are no
> RSTs anywhere.
>
BS1: as mentioned above, I will add a requirement that FIN is the
correct method.

Thanks


> Sec 4.3. VERSION_MISMATCH would benefit from being split into
> VERSION_TOO_HIGH
> and VERSION_TOO_LOW. For example, if the passive is at v4 only and
> the active
> supports v1, v2, and v3, it will take three tries to figure out that
> there is
> no way for these nodes to communicate. Even better would be a QUIC-
> style
> Version Negotiation message that would communicate the options in 1
> RTT.
>
BS1: This had been discussed in the WG somewhat and this is a carry-
over from the behavior of the TCPCLv3.
The current requirements on the actie entity are to start at the
highest supported version and on the passive entity are to begin
TLS/session negotiation on *any* acceptable TCPCL version, which
assumes that a later version will be more acceptable to an arbitrary
passive entity.
Adding a "supported versions set" to the Contact Header is possible,
but there needs to be WG discussion on whether this is a worthwile late
addition.

If it's routine for a node that supports v4 to also support earlier versions, than I agree there is no serious problem here.


> There are few items that seem to be artifacts of TLS happening after
> session
> negotiation in v3:
>
> Sec 4.4.3. "If certificate validation
>    fails or if security policy disallows a certificate for any
> reason,
>    the entity SHALL terminate the session"
>
> I don't understand this; certificate validation generally occurs
> during the TLS
> handshake, where there is no session?
>
BS1: There is a bit of gray area when the TLS handshake is involved,
because it can either succeed or fail but after the handshake it is
possible to send TCPCL messages regardless of handshake success. I
suppose that if the TLS stack fails within the TLS handshake that there
will be a TLS-level message indicating this fact and the TCPCL-level
message is redundant. Using the SESS_TERM regardless of whether the TLS
stack rejected the handshake or the CLA rejected the peer certificate
guarantees that there is some over-the-wire indication of what went
wrong (as opposed to the connection just being closed after a seemingly
valid TLS handshake).

I am uneasy about this response. The TLS alert mechanism can already signal the peer when there is a problem with the handshake. However, many TLS stacks deliberately obscure the precise reason for handshake failure to avoid attacker analysis. This text treats cert validation as something outside the handshake, which I don't believe is correct.


> Sec 4.4.3
> "the active
>    entity SHALL authenticate the DNS name (of the passive entity)
> used
>    to initiate the TCP connection"
> s/TCP Connection/TLS session. TCP connections don't consider DNS at
> all.
>
BS1: This may be a phrasing issue, maybe instead:
   Either during or immediately after the TLS handshake if the active
   entity resolved a DNS name (of the passive entity) in order to
   initiate the TCP connection, the active
   entity SHALL authenticate that DNS name using any DNS-ID of the peer
   certificate.

LGTM.


> Sec 4.5.
> "After the initial exchange of a Contact Header, all messages
>    transmitted over the session are identified by a one-octet header
>    with the following structure:"
>
> Obviously, TLS handshake messages are after the Contact Header and
> are not
> prepended by these headers. Perhaps this is an artifact from v3?
>
BS1: This is an artifact, it should be clarified as:
    After the initial exchange of a Contact Header and any TLS
    handshake exchanges, ...

LGTM


> Sec 4.7
> "Once this process of parameter negotiation is completed (which
>    includes a possible completed TLS handshake of the connection to
> use
>    TLS),"
>
> The TLS handshake occurs before parameter negotiation.
>
BS1: This is a vestigal behavior and needs to be rephrased to remove
that parenthetical.

Yep


> Sec 5.2.4 I find it odd that each CL would have its own set of reason
> codes
> that it will simply pass to the bundle layer. Far better for it to be
> a common
> set of CL-agnostic errors that the bundle layer implements, as they
> literally
> do not matter to the CL at all.
>
BS1: There had been earlier WG discussion about a standardized CLA--BPA
interface and nomenclature, but the CLA capabilities are incredibly
link-layer dependent and not at all consistent, especially ways in
which a transfer can fail (some link layers are even unidirectional and
don't provide any feedback at all to the CLA).
This could be discussed in the WG to see if the consensus has evolved
in any way in the meanwhile.


OK, I don't think it's necessary to revisit consensus on this.