Re: [dtn] Mirja Kühlewind's Discuss on draft-ietf-dtn-tcpclv4-18: (with DISCUSS and COMMENT)

Magnus Westerlund <magnus.westerlund@ericsson.com> Wed, 27 May 2020 13:18 UTC

Return-Path: <magnus.westerlund@ericsson.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 636F13A0BD3; Wed, 27 May 2020 06:18:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.091
X-Spam-Level:
X-Spam-Status: No, score=-2.091 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, 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, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.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 z0RdasCp_sAd; Wed, 27 May 2020 06:18:28 -0700 (PDT)
Received: from EUR05-DB8-obe.outbound.protection.outlook.com (mail-db8eur05on2054.outbound.protection.outlook.com [40.107.20.54]) (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 F33663A0B43; Wed, 27 May 2020 06:18:25 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=QS00YpRMhht/PgTFB/kkOh90hVxBWeRFBopd8xYsU8ZD7jdgqP5OprVS+ybqAdEu3Pqf+1xylJOtjR5+S3IpoUuasB2Ky+1Ll9Sbsh09adzq3BXS6+5e9q5NY1wRERvXf73W6gVwxj0fk/rCuXf3EKJrukK+yvBr/bYIEjrnFnPL565g8gTffKM9IxwZl5rekWJXSo/RHh7RDfG9M03CzrGekkUzMNbzAO2g6+MjuKmJc/RR5kvg03lbaZRVU1Spg6TsWAcYXdFxbPTmalaLHYiPxtVom6yjQdn2wesPYuolfkHWB7RjQv+14WFX3cVdrijq+1CtkE8T7Es9k4l24g==
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=roulw8Up1pwFnKAPCq35oJfJB1AlHOFmumU0eHsogLc=; b=e3AfcbvA7+pz9rUO7QsUTEeiE35ZQacGA73yRzxxdf6ERcYQ/4L/iGd8Cnpwl+h8Fj3bU0Q3Gbup04tkGl1U9JfOOTRvuKzZ6QQKPYnwOxbmysnk/5JdnBbt/cw0kcee5eIJmb9Qy7joLH98Nrs79w1h0muI69ejQTGmyAT2mronP2GxkPmfbrxKgu0gi7yDXtUjMydnJPRjNHPHXFw1B4yfGJaE1KJSEhiGN/SPxiGYfUInZCj76Ump4MLBM8jFnCmoV0qdwqlmf/7j0UYE4Ugk9bnFLYJAKstoe/JnFtCLSHMgl/4WHVd5dyWYBzjYQKuvAUs7AiUcJh7AAlGVCg==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ericsson.com; dmarc=pass action=none header.from=ericsson.com; dkim=pass header.d=ericsson.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=roulw8Up1pwFnKAPCq35oJfJB1AlHOFmumU0eHsogLc=; b=hPa+DR8Sn2X4u/iL7bhnBBnNxloh2Nw+j+SH2kfxqDoaO4MbeWQ/xPJMaskJpONSzySfJVsm/fXuqoTn2RiuunHwejIGw4ubqGwY0ZyV2RClq9TTPki81jJS59qdaSHaIytEibkmokouryP0Gsekvo9lyCRJek9EDGX/x0t2FL0=
Received: from HE1PR0702MB3772.eurprd07.prod.outlook.com (2603:10a6:7:8e::14) by HE1PR0702MB3755.eurprd07.prod.outlook.com (2603:10a6:7:8d::33) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3045.13; Wed, 27 May 2020 13:18:21 +0000
Received: from HE1PR0702MB3772.eurprd07.prod.outlook.com ([fe80::ec28:2c21:6d78:917a]) by HE1PR0702MB3772.eurprd07.prod.outlook.com ([fe80::ec28:2c21:6d78:917a%2]) with mapi id 15.20.3045.014; Wed, 27 May 2020 13:18:21 +0000
From: Magnus Westerlund <magnus.westerlund@ericsson.com>
To: Brian Sipos <BSipos@rkf-eng.com>, "ietf@kuehlewind.net" <ietf@kuehlewind.net>, "iesg@ietf.org" <iesg@ietf.org>
CC: "draft-ietf-dtn-tcpclv4@ietf.org" <draft-ietf-dtn-tcpclv4@ietf.org>, "dtn-chairs@ietf.org" <dtn-chairs@ietf.org>, "dtn@ietf.org" <dtn@ietf.org>, "edward.birrane@jhuapl.edu" <edward.birrane@jhuapl.edu>
Thread-Topic: [dtn] Mirja Kühlewind's Discuss on draft-ietf-dtn-tcpclv4-18: (with DISCUSS and COMMENT)
Thread-Index: AQHV5+6WGby3OQoJeUGE8iR16tXBQqg90i+AgHI3IwA=
Date: Wed, 27 May 2020 13:18:21 +0000
Message-ID: <HE1PR0702MB37721BC4C889B6AF96793B8395B10@HE1PR0702MB3772.eurprd07.prod.outlook.com>
References: <158220398711.12456.13531582672796496258.idtracker@ietfa.amsl.com> <745bfd811b9d3fb03f3e280b15fe9feb41241ba8.camel@rkf-eng.com>
In-Reply-To: <745bfd811b9d3fb03f3e280b15fe9feb41241ba8.camel@rkf-eng.com>
Accept-Language: sv-SE, en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
x-mailer: Evolution 3.28.5-0ubuntu0.18.04.2
authentication-results: rkf-eng.com; dkim=none (message not signed) header.d=none;rkf-eng.com; dmarc=none action=none header.from=ericsson.com;
x-originating-ip: [158.174.130.143]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 2268f2d9-0344-4f6b-a84a-08d802406dfa
x-ms-traffictypediagnostic: HE1PR0702MB3755:
x-microsoft-antispam-prvs: <HE1PR0702MB3755E102D61F6414BADFE02595B10@HE1PR0702MB3755.eurprd07.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-forefront-prvs: 04163EF38A
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: H+bQTEcESu8Q7rbfv0vxoNk/bzs7ug7yXXa4Ks9WEr4A4Fbhgk6breRo6VA9+4jjca1iKk+k5gVJF7PbCLPkd0Lm2SuA/tji+9l/v+dYDzTAPWIW4a/51KPVFmjNrqeofgHk4zpg1TjVGCjsGsnZIFTtbijdKmosLCzvILk5V23xqsOR62yTxLjt2ihPpqaCavRztW+RvHwfUQpfrsBJyWfo6o6xWMxeuTDdzPm1ZEbAKSoLX7HrdSg/WWKYx7Cf/sTWdHzkisLubLDEe79T45cGWfHJ4n+pPMLPplsKJ77Bkzo+jsJbCpdNGoB+juKyLu5Pcaa4KPhMOT3Xwr1lBP+1g4Q5zCaxlvEthdKRPEiKvKzANH6H1FFpsrd37yQkYzbwGLgygFujjStjnyrKQtkcFubZG91oLFucmdYYVFhUMueyU3ld+EpyLB+LoQ1gHQaCDaM0vr5JW85cFOtLSA==
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:HE1PR0702MB3772.eurprd07.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(136003)(396003)(376002)(39860400002)(366004)(346002)(52536014)(2906002)(44832011)(21615005)(54906003)(30864003)(966005)(224303003)(99936003)(478600001)(71200400001)(166002)(316002)(6506007)(26005)(186003)(5660300002)(33656002)(8936002)(66574014)(66616009)(64756008)(76116006)(66946007)(110136005)(66446008)(55016002)(66476007)(83380400001)(7696005)(66556008)(86362001)(9686003)(4326008)(99106002)(579004)(559001); DIR:OUT; SFP:1101;
x-ms-exchange-antispam-messagedata: kfmNxyYmV3Ln8YbKsNe6TK+FaiNcBsgdu3zOVsrTNkiND98cWoK60Znj2VJxCXv1BV9Zdk0Jyf5mXPlWHi8yxj/1TIFmzUaLKo2/9JLDJKqXprSC25W1pUm6WrE+1R8bUsnpo5yn8bvBcnNSZxRsLjy1xkhX76vUMbmH1O8gz5DIXAGxkPp4926rQTs/WHObIMguSAD1tmDKqW+wbtQjvMlKa8YKyBEpvBYGs5l9IKW80YlHhkesYnlhSumtG1rFGfTmgMptcJZ9x1CJkvIIESGccguI3LeqQl+MNdOXTS467ypqvCneky88o6F0upEWFkLNWxFH7I023NTglYzE6pjvqZhgpzJe8g+ydZHqYoxjqnT2ABk0oXDBZMbO0GJvO3ZZSxzAjsFyHml60tyHaBq628dDLEeCl1x9WsuL+gAFb9BylfGRpoNf4vdmX+U+stHUOVNElVA3tbaJx/c3+s02j6fGCJh8rWgIJC7HRnV4tZbP4f8nhSbp4mOnkByi
x-ms-exchange-transport-forked: True
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg="SHA1"; boundary="----=_NextPart_000_0056_01D6343A.0DB9DB80"
MIME-Version: 1.0
X-OriginatorOrg: ericsson.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 2268f2d9-0344-4f6b-a84a-08d802406dfa
X-MS-Exchange-CrossTenant-originalarrivaltime: 27 May 2020 13:18:21.8161 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: uXkxS9lwbp4s+uz+EPezVxQGvdflgm0BkryCYsjcCZ/6k2G0wfWCTKz/MW16xHI0mO54FMXFqGsMTiPo8XhvBL5NrTmDJwWRisQHckSkXyo=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR0702MB3755
Archived-At: <https://mailarchive.ietf.org/arch/msg/dtn/rLLHgIbM0CIe5BQxZXRRv8fWBbk>
Subject: Re: [dtn] Mirja Kühlewind'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: Wed, 27 May 2020 13:18:33 -0000

Hi Brian and WG,

 

I have looked into Mirja's discuss and comments to see if I can remove my discuss. Please see inline. We are not quite done and do need a  little bit of discussion, especially on the first part of the discuss and CL interaction with BP agent and how CL retry and reestablishment should work. 

 

 

 

 

On Sat, 2020-03-07 at 22:37 +0000, Brian Sipos wrote:

> Mirja,

> I'm including responses below with prefix "BS: "

> 

> On Thu, 2020-02-20 at 05:06 -0800, Mirja Kühlewind via Datatracker wrote:

> > Mirja Kühlewind has entered the following ballot position for

> > draft-ietf-dtn-tcpclv4-18: Discuss

> > 

> > When responding, please keep the subject line intact and reply to all

> > email addresses included in the To and CC lines. (Feel free to cut this

> > introductory paragraph, however.)

> > 

> > 

> > Please refer to 

> >  <https://www.ietf.org/iesg/statement/discuss-criteria.html> https://www.ietf.org/iesg/statement/discuss-criteria.html

> > 

> > for more information about IESG DISCUSS and COMMENT positions.

> > 

> > 

> > The document, along with other ballot positions, can be found here:

> >  <https://datatracker.ietf.org/doc/draft-ietf-dtn-tcpclv4/> https://datatracker.ietf.org/doc/draft-ietf-dtn-tcpclv4/

> > 

> > 

> > 

> > 

> > ----------------------------------------------------------------------

> > DISCUSS:

> > ----------------------------------------------------------------------

> > 

> > Thanks for this well-written document. I have a couple of thing in the
> > comment

> > section below that should be clarified. But there is one point which does
> > not

> > seem correct to me and therefore I'm raising it at thee discuss level:

> > 

> > Sec 5.1.1:

> > "Both sides SHALL send a KEEPALIVE message whenever the negotiated interval

> >    has elapsed with no transmission of any message (KEEPALIVE or other).

> > 

> >    If no message (KEEPALIVE or other) has been received in a session

> >    after some implementation-defined time duration, then the node SHALL

> >    terminate the session by transmitting a SESS_TERM message (as

> >    described in Section 6.1) with reason code "Idle Timeout". "

> > 

> > It is not necessary that both endpoints send keepalives when TCP is used

> > underneath as data is transmitted reliably. If one end sends keepalives and

> > transmission fails it will close the TCP connection no matter what.
> > Therefore

> > the case where no keepalive is received, can only happen if no keepalive was

> > send by the application, however, if the own keepalives are send
> > successfully

> > it is also received and the TCP connection is alive. If this is only to test

> > liveness of the TCP connection, why don't you use TCP keepalives instead?

> > 

> > Further what happens when a keepalive fails? Should one endpoint try to

> > reconnect, immediately or later when new data is available?

> > 

> 

> BS: You are correct that it is not strictly necessary that both sides transmit

> KEEPALIVE messages to keep the TCP connection alive. The current KEEPALIVE

> behavior is inherited from TCPCLv3 and has not had any (positive or negative)

> discussion in the WG so it was just kept as-is.

> It's not explicitly stated, but there are no restrictions on when to re-

> establish a session to an entity which has lost a session due to Idle Timeout.

> Depending on local BP agent policy a preemptive session may be reinstated or
> the

> agent may wait until a transfer is needed.

 

>From my perspective I think there are no issue with Section 5.1. The KEEPALIVE messages do make sense and avoid the need for having complex interactions with the TCP stack to figure out if ones sent data actually was acknowledged or not. 

 

Just to verify the point about reestablishment. To my understanding is that if a TCPCLV4 entity do not receive a KEEPALIVE message from the peer it will trigger an IDLE timeout. Which will trigger the sending of a SESS_TERM message. It will also result in a change of the TCPCL session status to the higher layer indicating "ending". Thus, the higher layer can know that its link is closing down and can thus do what is appropriate in relation to the communication. Does this understanding match the intention?

 

What isn't clear to me is if there needs to be recommendation to those higher layers for how to handle TCPCL connection terminations and failures. The different convergence layer has quite different properties depending of what they are. A deep space link that is dependent on when a transmitter can have a LOS to the receiver and thus knows it is not worth attempting to establish the CL until then is quite different from a TCP CL that given that one have bundles to transmit should attempt, and if failing retry after suitable times. There is also the issue that some entities may not be capable of receiving any bundle unless it contacts out, and in that case that node needs to establish a TCPCL connection simply to receive bundles. 

 

Some discussion of the above issue appears motivated to determine if there should be some more discussion of what reestablishment behavior TCPCL should have and provide guidance to the higher layer that uses the TCPCL. 

 

> 

> > And one more small thing:

> > sec 6.1:

> > "However, an entity MUST always send

> >    the contact header to its peer before sending a SESS_TERM message."

> > This normative requirement seems contradicting the way version failures are

> > handled earlier on in the doc.

> > 

> 

> BS: The contact header is always the first thing sent from either side of a
> new

> TCP connection intended to establish a TCPCL session. A passive entity can

> choose to close the TCP connection rather than sending a contact header if
> some

> security policy dictates that, but an entity cannot send anything before a

> contact header.

> The graceful way to refuse a connection at the start is to send a contact
> header

> (with some desired version number, but it really doesn't matter) and then
> either

> close the TCP connection or send a SESS_TERM. This is described in section 4.3

> "Contact Validation and Negotiation". I don't see the discrepancy between
> these

> sections.

> 

 

On Section 6.1:

 

   A session termination MAY occur immediately after transmission of a

   Contact Header (and prior to any further message transmit).  This

   can, for example, be used to notify that the entity is currently not

   able or willing to communicate.  However, an entity MUST always send

   the Contact Header to its peer before sending a SESS_TERM message.

 

I do see Mirja's issue. The text is a bit contradictory and unclear on which session is referenced. So if the passive part receives a CONTACT header and then sends a SESS_TERM I interpret this as you consider a TCPCL session is crated through only Contact exchange. Secondly, as Mirja states it is allowable to terminate the TCP session per Section 4.1 prior to this. 

 

If the passive entity does not receive a Contact Header

   after some implementation-defined time duration after TCP connection

   is established, the entity SHALL close the TCP connection. 

 

Thus, maybe a clarification that context of the normative text statement is in relation to the TCPCL session. And note that TCP connection termination may occur prior to the CONTACT exchange. 

 

Maybe: 

 

 A TCPCL session termination MAY occur immediately after transmission of a

^^^^^

   Contact Header (and prior to any further message transmit).  This

   can, for example, be used to notify that the entity is currently not

   able or willing to communicate.  However, an entity MUST always send

   the Contact Header to its peer before sending a SESS_TERM message.

Termination of the TCP connection can occur prior to receiving the Contact

header as discussed in Section 4.1. 

 

Feedback on this? 

 

 

 

> > 

> > ----------------------------------------------------------------------

> > COMMENT:

> > ----------------------------------------------------------------------

> > 

> > 1) Sec 4.1:

> > "Therefore, the entity MUST retry the

> >    connection setup no earlier than some delay time from the last

> >    attempt."

> > It would be good to provide a recommended value or at least a minimum value.

> > 

> 

> BS: This would seem to be quite network dependent. I can see making a

> recommendation for a minimum initial delay of 1 second, but that's quite

> arbitrary.

 

I think this is fine. 

 

> 

> > 2) Similar here in sec 4.1:

> > " If the

> >    passive entity does not receive a Contact Header after some

> >    implementation-defined time duration after TCP connection is

> >    established, the entity SHALL close the TCP connection."

> > It would be good to provide some default value or at least some more

> > discussion

> > about ranges of values. In any case this value should be larger than X times

> > the RTT as TCP segments can get lost any might need to be transmitted. I
> > guess

> > something in the order of second would be appropriate?

> > 

> 

> BS: For an earlier comment I added a very wide bound for this:

> Entities SHOULD choose a Contact Header reception timeout interval no 

> longer than 10 minutes (600 seconds).

 

The only concern I have with 600 seconds is that it leaves the passive side open for resource attacks. If the server actually opens and creates states and hold on to it for 600 seconds before closing it. An bot-net attacker could potentially manage to create quite a lot of state. I would think that with the basic protection this has each IP address could use 63000 different source ports and simply leave state hanging. That is 63 million TCP connections for just 1000 nodes. Managing to generate 63000 TCP connections in 10 minutes is something a toaster most likely can manage, probably also a lot of smaller IoT devices. 

 

So maybe a shorter interval of 30 or 60 seconds and a resource exhaustion warning. 

 

> 

> > 3) Sec 4.3:

> > " To prevent a flood

> >    of repeated connections from a misconfigured application, an entity

> >    MAY elect to hold an invalid connection open and idle for some time

> >    before ending it."

> > Not sure why you need to hold it open...? All you need is to not accept but

> > ignore new connections from that peer/IP address for some time. And more

> > questions:

> >   - When kept open and you suddenly received a valid message, should you

> >   process it? - And when  you finally decide to close the connection, how do

> >   you do that? TCP RST, or FIN? - Do you send (TCP) keepalives?

> > 

> 

> BS: This requirement was a hold over from TCPCLv3 and I'm not exactly sure the

> rationale either. It does make sense to handle this as a firewall-type rule to

> disallow new connections from that peer. I don't know that this warrants a
> TCPCL requirement though, that seems more generic firewall activity.

 

I think the new text is fine. 

 

 

> 

> > 4) Also 4.3:

> > "   The first negotiation is on the TCPCL protocol version to use.  The

> >    active entity always sends its Contact Header first and waits for a

> >    response from the passive entity.  The active entity can repeatedly

> >    attempt different protocol versions..."

> > If you read on in this section it seems like the receiver always sends a

> > SESS_TERM if the version is not compatible. So I assume you mean the active

> > entity can open a TCP and try again. And I assume it should do it
> > immediately

> > after the SESS_TERM is received. I believe that's what the following

> > paragraphs

> > say but this part confused me a bit. So might be only an editorial issue.

> > Please clarify! However, if there would be any attempt to send another CH on

> > the same TCP connection, that could lead to ambiguity and would need to be

> > further specified. Also more point, the text does not specify what the

> > receiver's response to the CH is. The figure shows that it will also send a

> > CH,

> > however, that should also be spelled out in the text!

> > 

> 

> BS: I edited this paragraph from an earlier comment and clarified that a
> contact

> header send is one-for-one with a TCP connection. The Section 4.1 was also

> updated to have specific sequencing SHALL statements.

> Here is the new Section 4.3 text for reference:

> 

> The first negotiation is on the TCPCL protocol version to use.

> The active entity always sends its Contact Header first and waits for

> a response from the passive entity.

> During contact initiation, the active TCPCL node SHALL send the highest TCPCL

> protocol

> version on a first session attempt for a TCPCL peer.

> If the active entity receives a Contact Header with a lower

> protocol version than the one sent earlier on the TCP connection,

> the TCP connection SHALL be closed.

> If the active entity receives a SESS_TERM message with reason of

> "Version Mismatch", that node MAY attempt further TCPCL sessions with the

> peer using earlier protocol version numbers in decreasing order.

> Managing multi-TCPCL-session state such as this is an implementation matter..

> 

 

I think this is fine.

> > 5) sec 4.4.1:

> > "When present, the SNI SHALL contain the same host name

> >       used to establish the TCP connection."

> > Not sure what this means... how do you use an host name in an TCP
> > connection?

> > Do you mean the same host name that has been used in name resolution to get

> > the

> > IP address that is used to establish the TCP connection? Or something else?

> > 

> 

> BS: Yes, I've combined the two requirements here to read:

> 

> When a resolved host name was used to establish the TCP connection, the TLS

> ClientHello SHOULD include a Server Name Indication (SNI) in accordance with

> [RFC6066] containing that host name (of the passive entity) which was
> resolved.

> 

 

So if I understand the current text the active part could know that the Node-ID-1 that it want to reach is at hostname1. It will include the hostname1 in the SNI. The server certificate will then list the node-IDs that are available to be served by TCPCLv4 on that hostname. So even if I know the node-ID will not include that as SNI? And the security model here is that the TCPCLv4 will identify those NODEIDs it is a representative of and where it can forward the Bundles after CL depacketization. 

 

Isn’t actually a huge weakness here is that the CA is unlikely to know which NodeIDs that are owned by a particular entity. For normal hierarchical DNS names neither consumers would allow sub-domain names that are for another domain. Thus, impersonation is hard. Here with NodeIDs the same checking is difficult? 

 

 

> > 6) sec 5.1.2:

> > What is the entity receiving the MSG_REJECT supposed to do?

> > 

> 

> BS: The intent of this message is for troubleshooting only. A likely use of

> MSG_REJECT is that the message type was unknown to the peer and the reject

> sender has already closed the TCP connection.

 

Ok. Clarification looks good. 

 

> > 7) sec 5.2.3: General question on the ACK mechanism: As you say correctly
> > the

> > fact that you don't get a notification is not a TCP protocol matter but only

> > an

> > interface matter. E.g. if taps would be used, this information would be

> > available. Was it considered to make the ACK mechanism optional, e.g. by
> > using

> > a flag in the XFER_SEGMENT to request an ACK per segment? Also more
> > questions:

> >  - Why are the message flags reflected?

> >  - Why is the Acknowledged length field needed if there needs to be one ACK

> >  (send in order) for each segment anyway?

> > 

> 

> BS: The use of XFER_ACK is supposed to indicate a stronger state than just
> "the

> peer received these messages on the TCP stream. It's supposed to indicate that

> the segment of data has been fully processed, which includes indication to the

> BP agent (and potentially persistence in the agent for reactive fragmentation

> purposes).

> 

> There was some discussion about negotiating the use of ACK or similar
> parameters

> but the WG consensus was to keep the protocol with as few negotiated behaviors

> as possible. The Segment MRU parameter and associated XFER_SEGMENT data size

> determine how much data each XFER_ACK covers so that is in a way negotiation
> of

> "when to use XFER_ACK". As stated elsewhere in the document, it is possible to

> send an entire transfer in a single segment which is the least overhead for

> XFER_SEGMENT and the least number of XFER_ACK per transfer (exactly one).

> 

> The repetition of the flags is not strictly necessary but is a holdover from

> TCPCLv3. The ACK length is also a holdover and is redundant as you mention,
> but

> it is helpful from a troubleshooting perspective.

> 

 

I think the clarification of  “… fully processed”  improves this aspect. 

 

> > 8) sec 5.2.4: Can you maybe explain why the XFER_REFUSE is a message/feature

> > of

> > the CL and not the BP?

> > 

> 

> BS: It's really just to allow interrupting a transfer at a lower layer than
> the

> BP agent for data handling issues like insufficient storage. It also allows a

> large bundle transfer to be interrupted if the receiver won't accept it for

> routing or other reasons after the bundle header is received and decoded (but

> the rest of the bundle payload is not yet received).

> 

 

Ok.

 

> > 9) sec 5.2.4:

> > "If a sender receives a XFER_REFUSE message, the sender

> >    MUST complete the transmission of any partially sent XFER_SEGMENT

> >    message.  There is no way to interrupt an individual TCPCL message

> >    partway through sending it."

> > Not sure if use of normative language is appropriate here, because I believe

> > what you mean is that as soon as the data/message is given to the TCP

> > connection, you can't call it back. That's just a fact and nothing the
> > sender

> > may or can enforce. However, it could reset the TCP connection effectively
> > but

> > that probably not what is desired. Please clarify or remove normative

> > language!

> > 

> 

> BS: This text was a holdover from earlier TCPCLv3. I agree that this is not

> strictly a protocol requirement, but it is an important implementation concern

> that once the header portion of a message is sent the entire message needs to

> follow so that the receiver can properly decode the subsequent messages.

> Would simply replacing the "MUST" with a "has to" be reasonable?

> 

 

I have no issue with leaving the RFC2119 language in place. 

 

 

> > 10) sec 5.2.5.1: Can you further explain what the use case ifs for the

> > Transfer

> > Length Extension? When do you expect the actual length to be different?

> > 

> 

> BS: The purpose is not to provide redundant data but to indicate the total

> length to the receiver at the start of transfer so that the receiver may

> validate or pre-allocate storage for the transfer.

> In a trivial implementation each transfer is a single segment and the total

> length is implied by the segment data length.

> This was made into an optional extension because there are some uses of TCPCL

> which either use single-segment transfers or which don't need to pre-allocate

> storage.

> 

 

Ok.

> > 11) sec 6.1:

> > "   After sending a SESS_TERM message, an entity MAY continue a possible

> >    in-progress transfer in either direction."

> > Why is this necessary? Why can the entity not just send the SESS_TERM after

> > the

> > end of the transfer? Please clarify in the doc!

> > 

> 

> BS: I'm adding text to Section 6 to clarify, but here is the paragraph:

> 

> This section describes the procedures for terminating a TCPCL session.

> The purpose of terminating a session is to allow transfers to complete

> before the session is closed but not allow any new transfers to start.

> A session state change is necessary for this to happen because transfers

> can be in-progress in either direction (transfer stream) within a session.

> Waiting for a transfer to complete in one direction does not control

> or influence the possibility of a transfer in the other direction.

> Either peer of a session can terminate an established session at any time.

> 

 

I think this text looks ok. 

 

> > 12) 6.1:

> > " When performing an unclean shutdown, a receiving node

> >    SHOULD acknowledge all received data segments before closing the TCP

> >    connection."

> > What do you mean here? TCP acknowledgements? If so, this should not be

> > normative as TCP will do that not matter what. However, you can not send any

> > new application data/CL ACK after a TCP FIN was sent. Please clarify!

> > 

> 

> BS: I clarified this to "... SHOULD acknowledge all received XFER_SEGMENTs
> with

> an XFER_ACK ..." Does this make sense?

> 

 

Yes, I think it works. I had to think a little bit about the roles here. 

 

> > 13) sec 6.1:

> > "   If a session is to be terminated before a protocol message has

> >    completed being sent, then the node MUST NOT transmit the SESS_TERM

> >    message but still SHALL close the TCP connection. "

> > Not sure how this case is supposed to happen. When give a message to your
> > TCP

> > stack it will send it. If sending fails on the TCP level, the connection
> > will

> > be closed automatically. Or do I misunderstand the intended scenario here?

> > 

> 

> BS: This requirement really applies to a situation where an entity really
> really

> needs to end a session promptly and doesn't have time to wait for an earlier

> message to complete and the SESS_TERM handshake to finish. Maybe the word

> "terminated" here needs to be replaced by some other term? "closed"?

 

Ok.

 

 

-- 

Cheers

 

Magnus Westerlund 

 

 

----------------------------------------------------------------------

Networks, Ericsson Research

----------------------------------------------------------------------

Ericsson AB                 | Phone  +46 10 7148287

Torshamnsgatan 23           | Mobile +46 73 0949079

SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com <mailto:magnus.westerlund@ericsson.com> 

----------------------------------------------------------------------