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

"Burleigh, Scott C (US 312B)" <> Thu, 08 August 2019 22:39 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 45D83120147 for <>; Thu, 8 Aug 2019 15:39:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Status: No, score=-2 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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id fSctkGi0YW2B for <>; Thu, 8 Aug 2019 15:39:13 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id E0E47120189 for <>; Thu, 8 Aug 2019 15:39:13 -0700 (PDT)
Received: from pps.filterd ( []) by ( with SMTP id x78MZ5rV059255 for <>; Thu, 8 Aug 2019 15:39:12 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; h=from : to : subject : date : message-id : references : in-reply-to : content-type : content-transfer-encoding : mime-version; s=InSight1906; bh=jpe2AOlVE3kD/LMF1+rIFsVqRYzJyK1Lb8Or85Bmpi0=; b=cx7ch4PV8bgDFcHYHFcQxCGabd1ejLiu395jP100nxfBkn9IIjw/r7lP9JyCuH6P8n10 w/r5aKBdlmIybxv/VM3rWfZOa7VSPOFTBksmwiIfNdaeBNZxfR+Y6pcFda2TwWi52pfS BfCDnxg+CW+X0DDqOvuiyEB4HqVvaxMSthSFQ1Q4YNEFW6OahKFdU23RZcN67ZEcrKH/ jSqiv+cMPDr+rMLXPmhhRRoyFlRxxxyZZ20k0oRaht4o+MH6k+3+3tBDj2JutGAaYHTf 94YTxKAdK8MZPzTFI3a5PqI+8kPISapjNw6I6I9DDLx99g3nKUfFDlIrxh+2/Pu3Kzg3 Rg==
Received: from ( []) by with ESMTP id 2u892svebe-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for <>; Thu, 08 Aug 2019 15:39:11 -0700
Received: from ap-embx16-sp10.RES.AD.JPL ( []) by (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id x78MdBVm014043 (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128 bits) verified FAIL) for <>; Thu, 8 Aug 2019 15:39:11 -0700
Received: from ap-embx16-sp10.RES.AD.JPL (2002:8095:8953::8095:8953) by ap-embx16-sp10.RES.AD.JPL (2002:8095:8953::8095:8953) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1591.10; Thu, 8 Aug 2019 15:39:10 -0700
Received: from ap-embx16-sp10.RES.AD.JPL ([fe80::4:f430:47b5:767b]) by ap-embx16-sp10.RES.AD.JPL ([fe80::4:f430:47b5:767b%17]) with mapi id 15.01.1591.008; Thu, 8 Aug 2019 15:39:10 -0700
From: "Burleigh, Scott C (US 312B)" <>
To: "" <>
Thread-Topic: AD review of draft-ietf-dtn-tcpclv4-12
Thread-Index: AQHVTiwYSdHzR6wPWEivvF9ksr/dOabx0VJg
Date: Thu, 8 Aug 2019 22:39:10 +0000
Message-ID: <>
References: <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Source-IP: []
X-AUTH: Authorized
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-08-08_09:, , signatures=0
X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1906280000 definitions=main-1908080201
Archived-At: <>
Subject: Re: [dtn] AD review of draft-ietf-dtn-tcpclv4-12
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Delay Tolerant Networking \(DTN\) discussion list at the IETF." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 08 Aug 2019 22:39:18 -0000

Hi.  A couple of thoughts here:

1.  In section 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.


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

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
Subject: AD review of draft-ietf-dtn-tcpclv4-12 

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

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

     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. 
Magnus Westerlund