Re: [dtn] AD review of draft-ietf-dtn-tcpclv4-12

Brian Sipos <BSipos@rkf-eng.com> Tue, 13 August 2019 12:58 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 4EFED120147 for <dtn@ietfa.amsl.com>; Tue, 13 Aug 2019 05:58:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 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_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 HVd9m9ahzH5S for <dtn@ietfa.amsl.com>; Tue, 13 Aug 2019 05:58:46 -0700 (PDT)
Received: from NAM04-SN1-obe.outbound.protection.outlook.com (mail-eopbgr700042.outbound.protection.outlook.com [40.107.70.42]) (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 7857C120130 for <dtn@ietf.org>; Tue, 13 Aug 2019 05:58:46 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=mfohMuKMta94+hoSDBswW13Ls4bsypA0wkYZOOeLIxsCXxR2paq7Ej3kKvf4A3g75z41kgTGVRUdIkMH8uZ18kmAOxWPhjpabg8x11yfICuHDI6phQEkiFBxnN7md1QdDERCSv1r1IfCQCiHQGXyeEmgPlegJSlhdxG581lqaNDsCUxfbp1YV0tqU+JlknP3Cb2Fune3OclrcbYWeE+AqqsziSbrRK5a1fjQNiOEEiPeq2pVpQqRjdoV/bd0MRxRGc/+gLITHJlNwzh5czQiFPmRxzP+EPJRZd5+ZM5ePEGeDJP/K6qq0JGsOwuW3axCtZ0um3D5C8EJSNGhmmEyPQ==
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=eaL5mlzP/i7scMQlpXs9Wfg5H5aQAt4nfLbUpSuLzyo=; b=Vm6/cuqgPQw80W0MKWDCW6ygrrDO9xAVLEBdQqghV4j8q48NcYV0j+ergW2Ekwc8189vSNs/3rypsFDm4PhTYs79NchR/sIKtl7W73BupSTqRaJRHlWneL+C2AEh0lwHO2sjz4Nn52450FEZBccB7I1diGgfGsHrdRKhUiuEYpGnvgp+DYodpCnKePUL2B8LwL4XXH6aPTiut3AlfpHVP5jjqkt4lrtZl0ND3upDZH/dCdMOLU2gO/1HpscpWzo6QYSwjP+s6IBabLjcyb4eq0EXYN4PLw3YQdyWqK96CzzawbF4hCXbsfmjQimXA3JWkYIB+SuZN+s8v8vE8Oz7OQ==
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=rkfeng.onmicrosoft.com; s=selector2-rkfeng-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=eaL5mlzP/i7scMQlpXs9Wfg5H5aQAt4nfLbUpSuLzyo=; b=Em1OkXkzfBwwAzlCaA/8TMH8O5V6IOXEyUB+DRt0cBL4u71jY9+XBMdAjz7WsB1Ut6uQtZqYQpKMNOMG1OIy23uqVAhja5G/P70w/suDNIof5hkYE27XtOSGEBJYNUr6Valy1bS8tywE6B2GpBE76FwG1MHKrdtOZ9Qymq/Oj0g=
Received: from BYAPR13MB2614.namprd13.prod.outlook.com (20.178.206.140) by BYAPR13MB2469.namprd13.prod.outlook.com (52.135.229.159) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2157.14; Tue, 13 Aug 2019 12:58:43 +0000
Received: from BYAPR13MB2614.namprd13.prod.outlook.com ([fe80::1c5d:f9e6:e81a:5c16]) by BYAPR13MB2614.namprd13.prod.outlook.com ([fe80::1c5d:f9e6:e81a:5c16%5]) with mapi id 15.20.2157.020; Tue, 13 Aug 2019 12:58:42 +0000
From: Brian Sipos <BSipos@rkf-eng.com>
To: "Burleigh, Scott C (US 312B)" <scott.c.burleigh@jpl.nasa.gov>, "dtn@ietf.org" <dtn@ietf.org>
Thread-Topic: AD review of draft-ietf-dtn-tcpclv4-12
Thread-Index: AQHVTiwYSdHzR6wPWEivvF9ksr/dOabx0VJggAEHqRqAAHqFMIAESJ1p
Date: Tue, 13 Aug 2019 12:58:42 +0000
Message-ID: <BYAPR13MB26148819EE9002D45AB6CB539FD30@BYAPR13MB2614.namprd13.prod.outlook.com>
References: <BN8PR13MB2611BFB2B6E15C4BCF6D00D29FD70@BN8PR13MB2611.namprd13.prod.outlook.com>, <cd2a67b0498044b0bc4934591d95a9d8@jpl.nasa.gov> <BN8PR13MB2611D2E56E407263B2B970419FD60@BN8PR13MB2611.namprd13.prod.outlook.com>, <be80a173c70046a59a0e4fb266ac74df@jpl.nasa.gov>
In-Reply-To: <be80a173c70046a59a0e4fb266ac74df@jpl.nasa.gov>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: spf=none (sender IP is ) smtp.mailfrom=BSipos@rkf-eng.com;
x-originating-ip: [38.100.63.114]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: dc4a4bc0-2fed-4372-3668-08d71fedf83e
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(7021145)(8989299)(4534185)(7022145)(4603075)(4627221)(201702281549075)(8990200)(7048125)(7024125)(7027125)(7023125)(5600148)(711020)(4605104)(1401327)(2017052603328)(7193020); SRVR:BYAPR13MB2469;
x-ms-traffictypediagnostic: BYAPR13MB2469:
x-ms-exchange-purlcount: 1
x-microsoft-antispam-prvs: <BYAPR13MB2469F84A6B3174E036E0BFE39FD20@BYAPR13MB2469.namprd13.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-forefront-prvs: 01283822F8
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(39830400003)(376002)(346002)(136003)(366004)(396003)(189003)(199004)(15404003)(236005)(66446008)(966005)(53946003)(25786009)(66066001)(508600001)(6246003)(55016002)(66574012)(2906002)(446003)(80792005)(53936002)(54896002)(6306002)(9686003)(91956017)(66946007)(486006)(76116006)(14454004)(7736002)(66556008)(64756008)(5660300002)(74316002)(66476007)(19627405001)(316002)(110136005)(86362001)(6506007)(6436002)(33656002)(256004)(30864003)(11346002)(606006)(52536014)(2501003)(99286004)(476003)(3846002)(186003)(105004)(8676002)(76176011)(14444005)(8936002)(26005)(102836004)(81156014)(229853002)(81166006)(53546011)(71190400001)(7696005)(6116002)(71200400001); DIR:OUT; SFP:1101; SCL:1; SRVR:BYAPR13MB2469; H:BYAPR13MB2614.namprd13.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1;
received-spf: None (protection.outlook.com: rkf-eng.com does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam-message-info: 72HviD33fKpJr1ozoo4xkCjtNyrVfkU/ZbcTgauI87/YKlu7GvzPmw5wh+sAQqF21iLkfCNCjM6+h7CicvurN6hC3BXoJD1LdhC0diBBmsYwWV2pMGAM+vfSFtN4rZBDIkEatqZrdk8NQ7o+YkRwjwnJ7zL5fn4DqJ8n+cA2nOJfS5bkdHQdm7Dl8k7aAJoW0X9S0mccunRMFMmHt/7foXWLJrqIiiVzueWKYN2zjC20Ftn0my6FSz4tquh7MNo1BU3bQPN2XzpOdrNgfl4qod1s2Exf4GRUIzXDTiu9oxgsSvM0Vrkimd8GdwM61E7vqQ9vFzC+CiyGfTnIDRWAJBtqmZn+sK+mr/vwrjA3mhrOxpLGiO+6bDUHt+xvAnuTRCP0ZGwIZC1JJdjc4F0yNm1JcVk/cunZzuWofcAdj5k=
x-ms-exchange-transport-forked: True
Content-Type: multipart/alternative; boundary="_000_BYAPR13MB26148819EE9002D45AB6CB539FD30BYAPR13MB2614namp_"
MIME-Version: 1.0
X-OriginatorOrg: rkf-eng.com
X-MS-Exchange-CrossTenant-Network-Message-Id: dc4a4bc0-2fed-4372-3668-08d71fedf83e
X-MS-Exchange-CrossTenant-originalarrivaltime: 13 Aug 2019 12:58:42.6192 (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: jLxSOBmkA4n8Wo1mXSNlTkO5zD8LANeyIkUEiCxvLW0M0q7XQAKqJ2PUgXj9/zUnZGd7gmLH1hDUT7RDGD0V6Q==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR13MB2469
Archived-At: <https://mailarchive.ietf.org/arch/msg/dtn/gIXOP45q37vtA91pNRxoPxzXti4>
Subject: Re: [dtn] AD review of draft-ietf-dtn-tcpclv4-12
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, 13 Aug 2019 12:58:51 -0000

Scott,
Okay, I will scrub the "endpoint" language from the CL spec because all the CL should deal with is inter-node transport. My feeling on the authentication side (binding the Node ID to the TLS session) is to just use the pre-existing X.509 mechanism for identifying the subject of a certificate as a URI since Node IDs are already a URI. This involves no protocol change and is consistent with other TLS-using protocols.

One other carry-over from TCPCLv3 is the association of a single Node ID with a CL session. Is it correct that there is no sensible reason for a single TCPCL session to have any more than a single Node ID? This is not to say that a single BP Agent can't have different TCPCL sessions each expressing a different Node ID, but within each session each TCPCL entity has exactly one Node ID.
________________________________
From: Burleigh, Scott C (US 312B) <scott.c.burleigh@jpl.nasa.gov>
Sent: Friday, August 9, 2019 19:11
To: Brian Sipos <BSipos@rkf-eng.com>; dtn@ietf.org <dtn@ietf.org>
Subject: RE: AD review of draft-ietf-dtn-tcpclv4-12


Hi, Brian.  First, yes, I do think the terminology is worth getting right, and I think we’ve been less than precise in the past.  A “node” is an entity that can send or receive bundles, comprising a bundle protocol agent, a set of zero or more convergence layer adapters, and an application agent; an “endpoint” is a set of zero or more nodes that all identify themselves for BP purposes by a common identified, i.e., an endpoint ID.  The source of a bundle is a node; the destination of a bundle is an endpoint (often a “singleton endpoint” that always contains exactly one member).



The way I understand TCPCL (at least in terms of socket-based implementations) is that any node can use its TCPCL adapter in one of two ways to enable communication via the TCPCL adapter of any other node:

1.       If it knows the IP address and port number of the socket on which that remote node’s TCPCL adapter is accepting connections, then the local TCPCL adapter can create a socket of its own and connect that socket to the remote socket.

2.       The local TCPCL adapter’s connection acceptance socket can accept a connection from the socket of a remote node’s TCPCL adapter.



In case 1, it necessarily has information associating the node with the socket address; in case 2 it doesn’t, which is why the ID of the associated node has to be provided in the contact header.



Node discovery is an altogether different mechanism; a node might use the ipnd node discovery protocol to acquire the information needed for case 1 (for multiple nodes in the local subnet, for example), but alternatively that information might be provided by some sort of management function.



The key point is that the association between node and socket address is information that has to come from somewhere (management, node discovery, the contact header) in order for bundles to flow, and that information might be accidentally or maliciously incorrect no matter where it comes from.



I figure one easy and straightforward way to authenticate the node ID is to check a signature (covering part or all of the contact header, and included in the contact header) computed in the private key of the purported node; the authenticating node is likely to need that node’s public key anyway in order to run bpsec.



If there are easier ways, I’m for ‘em.  But I would caution us against relying too heavily on capabilities that are readily available on the Internet, since not all DTN nodes that use TCPCL are going to be on the Internet.  (For example, the LANs on the International Space Station.)



Scott



From: Brian Sipos <BSipos@rkf-eng.com>
Sent: Friday, August 9, 2019 8:09 AM
To: Burleigh, Scott C (US 312B) <scott.c.burleigh@jpl.nasa.gov>; dtn@ietf.org
Subject: [EXTERNAL] Re: AD review of draft-ietf-dtn-tcpclv4-12



Scott,

For #1-3, should the CL spec use the term "Node ID" instead? The Endpoint ID term was carried over from TCPCLv3 quite blindly, as I am less familiar with bundle routing logic than transport logic.



Regarding #4-5, is it true that a CL contact/session is likely to be established with a peer already known to the BP agent and already associated with a Node ID? Or is it just as likely to do something like proactively attempt TCPCL sessions with all addresses in a local subnet to coarsely 'discover' other nodes?



My feeling on the TLS authentication topic is to allow any of the following:

  *   Authenticate the IP peer name/address using X.509 subjectAltName of type dNSName or iPAddress
  *   Authenticate the DTN peer Node ID using subjectAltName of type uniformResourceIdentifier

Then it would be up to each entity policy of when to require authentication, and the auth'n could occur on either/both ends of the CL session regardless of which entity is the passive or active role.

________________________________

From: dtn <dtn-bounces@ietf.org<mailto:dtn-bounces@ietf.org>> on behalf of Burleigh, Scott C (US 312B) <scott.c.burleigh=40jpl.nasa.gov@dmarc.ietf.org<mailto:scott.c.burleigh=40jpl.nasa.gov@dmarc.ietf.org>>
Sent: Thursday, August 8, 2019 18:39
To: dtn@ietf.org<mailto:dtn@ietf.org> <dtn@ietf.org<mailto:dtn@ietf.org>>
Subject: Re: [dtn] AD review of draft-ietf-dtn-tcpclv4-12



Hi.  A couple of thoughts here:

1.  In section 4.1.5.2 of the bpbis I-D we explain how nodes are identified by node IDs and how node IDs are a subset of (though syntactically indistinguishable from) EIDs.

2.  There is no need for TCPCL to have any awareness of BP endpoint IDs at all.  BP endpoints are the destinations of bundles, used for routing in the network; TCPCL plays no part in bundle routing.

3.  What TCPCL needs to be aware of is the IDs of the BP nodes on whose behalf it is acting.  Node IDs, not endpoint IDs.

4.  When a remote TCPCL entity makes a TCP connection to the local TCPCL entity, contact headers are exchanged; the IDs of the BP nodes served by the two TCPCL entities are noted in the contact headers.  At the local TCPCL entity, this enables bundles that are queued up for transmission to the BP node served by the remote TCPCL entity to be dequeued and transmitted correctly via the new TCP connection.

5.  It is of course possible for the remote TCPCL entity's contact header to be incorrect or malicious, falsely claiming association with the cited BP node.  To this end, maybe one of the data items in the contact header should be a signature over the whole contact header, signed in the private key of the remote TCPCL entity's associated BP node.  When each TCPCL entity receives the other's contact header and reads the node ID, it could use the cited node's public key to validate the contact header's signature.

Scott

From: dtn <dtn-bounces@ietf.org<mailto:dtn-bounces@ietf.org>> On Behalf Of Brian Sipos
Sent: Thursday, August 8, 2019 2:18 PM
To: dtn@ietf.org<mailto:dtn@ietf.org>
Subject: [EXTERNAL] Re: [dtn] AD review of draft-ietf-dtn-tcpclv4-12

All,
Because I am less familiar with the nuances of preexisting DTN and TCPCLv3 uses, can anyone help inform me about how the EID was/is intended to be used as part of the TCPCL. As Magnus points out, as currently written (and as a carry-over from TCPCLv3) there is no mechanism to authenticate that the EID sent by a TCPCL Entity is properly bound to the host sending it. Is there a purpose for this EID other than manual troubleshooting?

I'm planning on adding some text explaining how TLS with X.509can be used to authenticate the TCPCL peer based on the hostname/address used for the TCP connection in accordance with RFC 6125. It would also be possible to authenticate the EID as a subject URI of a peer certificate. Does this seem reasonable and desirable?

Thanks for any guidance,
Brian S.

________________________________________
From: Magnus Westerlund
Sent: Thursday, August 01, 2019 09:31
To: mailto:dtn@ietf.org; mailto:draft-ietf-dtn-tcpclv4@ietf.org
Subject: AD review of draft-ietf-dtn-tcpclv4-12

Hi,

I have now performed my AD review of draft-ietf-dtn-tcpclv4-12. I think most are minor comments, however the TLS and security related ones may be more problematic to resolve. I will now be on vacation so you know you will not receive any quick replies from me before the end of the month.

1. Section 1: What are the applicability of TCPCLv4 to BPv6? I wonder as RFC5050 is referenced.
2. Section 1.1: Session State Changed. Some editorial issues. Missing ":" initially. Then double ".." on Terminated.
3. Section 1.1:
   Session Idle Changed  The TCPCL supports indication when the live/idle sub-state changes.  This occurs only when the top-level session state is Established.  Because TCPCL transmits serially over a TCP connection, it suffers from "head of queue blocking" this indication provides information about when a session is available for immediate transfer start.

So in which direction are this change indicated/reported, both or only in one of them, or any as implied by Section 2.1's definition of Live Session?
4. Section 1.1: Transmission Intermediate Progress: Segment is not defined prior to this. Maybe a forward pointe? Or should maybe the whole subsection (1.1) be moved to after definitions?
5. Section 2: Is there a point to use the RFC 8174 language that makes only capital words have special meaning?
6. Section 3.1: "One of these parameters is a singleton endpoint identifier for each node (not the singleton Endpoint Identifier (EID) of any application running on the node) to denote the bundle-layer identity of each DTN node."

The above quote does imply something that at least BPBis isn't making clear that a particular application agent would have its own EID. It is not clear that there are a one-to-one relationship between bundle nodes and application agents. Can you please clarify what the relationship is and lets figure out if that needs to be clarified back to BPbis.
7. Section 3.1: "Bundle interleaving can be accomplished by fragmentation at the BP layer or by establishing multiple TCPCL sessions between the same peers."

Are there clear rules established for how many TCPCL sessions in parallel that may be established? By the end of my reading this is unanswered.
8. Section 3.1: XFER_REFUSE does that indicate that the bundle has already been received. How else does one separate other reasons for refusing a bundle versus that one have received it prior?
9. Section 3:1:    Once a session is established established, TCPCL is a symmetric protocol between the peers.
Double established
10. Figure 4: "Close message" is this TCP level message, if that is the case can that be clarified by prefix with TCP?
11. Section 3.2:
   Notes on Established Session states:
      Session "Live" means transmitting or reeiving over a transfer
      stream.

      Session "Idle" means no transmission/reception over a transfer
      stream.

     Session "Closing" means no new transfers will be allowed.

Note that "Closing" is not used in Figure 4, it is called ending. Note spelling error on "live" receving.
12. Section 3.2: Figure 5 and 6 uses PCH without explanation. Figure 5 could probably also benefit by expanding CH as Contact Header.
13. Figure 8 and 10: Uses [SESSTERM] is this the same as using the SESS_TERM message, or some other procedure. Please clarify.
14. Section 3.3: "   Many other policies can be established in a TCPCL network between these two extremes."

The list above includes three items, so the two extremes needs to be enumerated.
15. Section 4.1: Can TCPCLv3 and TCPCLv4 coexist on Port 4556? Based on 9.1 the answer is yes, please clarify here.
16. Section 4.1: "Therefore, the entity MUST retry the connection setup no earlier than some delay time from the last attempt, and it SHOULD use a (binary) exponential backoff mechanism to increase this delay in case of repeated failures."

Any recommended upper limit for the backoff?
17. Section 4.2:    Version:  A one-octet field value containing the value 4 (current version of the protocol).

I think the use of "the protocol" is unclear, maybe call it "the TCP convergence layer". This to avoid confusion with BPv7.
18. Section 4.2: Please define how to set and ignore reserved bits in the Flags field so that it may be extended in the future.
19. Section 4.3 and 4.4: Due to how the Contact Header relate to TLS there is clear risk for a TLS stripping attack where the CAN_TLS flag is cleared. I think there need to be some thought about mitigation of this weakness. Depending on the expected mix of entities and their capabilities one can either have policy for a deployment where one mandates TLS being used, thus preventing the bid-down by not being according to policy. It is more difficult to mitigate in a deployment where one have some entities that doesn't support TLS, unless one can some way securely learn which entities support it or not and thus can detect the manipulation. One can potentially also first attempt to do a TLS handshake for the best version one supports. Then run the CH inside the TLS to prevent TCPCL version and other flags to be manipulated. But that doesn't solve the down-bid. I did note the negotiation in Section 4.7 and the relation to Security Policy. Maybe the solution is to write some text on the risk of TLS striping in Section 8 and add forward pointers in 4.7 to that risk.
20. Section 4.4: Dealing with new TLS versions. BCP 195 does not appear to me to define how to deal with newer versions. However, as TLS 1.3 already exist I think this is from the start a relevant question.
21. Section 4.4: So what about entity authentication? Will the TCPCL entity have a name / identity that can be authenticated so that one know that one are talking to the right entity. And is the solution for this a classical PKI, or something else? Also does the passive entity expect the active (TLS client) to authenticate itself also?
22. Section 4.8: Please define how to set and ignore the reserved bits.
23. Section 4.5: Based on that many later sections just refer to the Message Header, shouldn't the section title for section 4.5 be Message Header? Now the first mentioning of "Message Header" are in Figure 16's title.
24. Section 6.1:
   After sending a SESS_TERM message, an entity MAY continue a possible
   in-progress transfer in either direction.  After sending a SESS_TERM
   message, an entity SHALL NOT begin any new outgoing transfer (i.e.
   send an XFER_SEGMENT message) for the remainder of the session...
   After receving a SESS_TERM message, an entity SHALL NOT accept any
   new incoming transfer for the remainder of the session.

To me it seems that the above paragraph contains one contradiction. The parenthesis in the second sentence (i.e. send an XFER_SEGMENT message) appears to be false. Because as the beginning of the sentence implies that it can't start a new transfer. However SESS_TERM is allowed to be inserted in between XFER_SEGEMENT messages for a transfer ID, i.e. XFER_SEGMENT(ID=7), SESS_TERM, XFER_SEGMENT(ID=7, end) is an allowed sequence. Can you please clarify.
25. Section 8.
If this identifier is used outside of a TLS-secured session or
   without further verification as a means to determine which bundles
   are transmitted over the session, then the node that has falsified
   its identity would be able to obtain bundles that it otherwise would
   not have.

I don't see how a entity could trust the in SESS_INIT provided EID more just because it is in TLS unless there are some mechanism for binding the EID to the TLS session endpoint (client or server). Some type of authentication is needed to prove the identity.
26. Section 8.
Therefore, an entity SHALL NOT use the EID value of an
unsecured contact header to derive a peer node's identity unless it
   can corroborate it via other means.

The EID value is not part of the CH, only SESS_INIT. Is this a left over from TCPCLv3 or earlier versions?
27. Section 8. Needs text on  TLS stripping attack due to the optional TLS usage.
28. Section 9: "In this section, registration procedures are as defined in [RFC8126]." . defined as in .
29. Section 9: "Some of the registries below are created new for TCPCLv4 but share code values with TCPCLv3."

I don't think "share" is the right word here. Maybe "Some of the registries have been defined as version specific to TCPCLv4, and imports some or all codepoints from TCPCLv3."
30. Section 9.3: Is RFC Required unnecessary strict? Considering the quite large name space, I would think that specification required would be a suitable policy? Just trying to understand what you think is gained by having someone publish the extension as an RFC, in any stream including the independent.
31. Section 9.4: Same question as for 30)
32. Section 9.5: Here RFC required may be suitable. However, does it make sense to allocate 2 or 4 points also here for Private/Experiments?
33. Section 9.6: Here I would consider Expert Review with a specification requirement. I also do not understand why so much is reserved, a reason for that?
34. I would expect that the policy for 9.6-9.8 to be aligned so may require change if change is decided on 33.
35. A big question I have after having read this document is how one discover / determine the IP+port(s) to connect to for a given EID. Is this currently completely deployment specific? And how bound is this to Bundle routing?

What may be missing is the section that tells the intended implementor that in addition to follow this specification you do need a solution to the following things, like for example authentication framework that allows one to verify the TLS connects to EID mappings. Or an address resolution protocol that maps EID to IP address and port pairs for cases when routing simply give you Forward this bundle to EID using TCPCLv4.

Cheers

Magnus Westerlund

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