Delay-Tolerant Networking TCP Convergence-Layer Protocol Version 4
Note: This ballot was opened for revision 18 and is now closed.
Comment (2020-12-02 for -23) Sent
I'll not disagree with my predecessor, but "[[ discuss ]]" has some random thoughts that were rattling around in my head. [[ discuss ]] [ section 4.* ] * Instead of upgrading in-session to TLS after CH version and magic field verification, Can the TLS session be negotiated first and perhaps quickly closed based on some DTN-specific ALPN (perhaps "dtn")? Can the use of a DTN-specific ALPN be any help even with in-session TLS upgrade (as currently described)? [ section 4.7 ] * Selecting the minimum of the two session keepalive parameters, in the case where one side uses a value of zero, allows one side to disable all keepalives altogether. I think this might not be the best negotiated outcome if one node knows that it is behind a NAT gateway: that node might need to send session keepalives in order to maintain NAT binding state. [[ nits ]] [ section 3.4 ] * "This situation not ideal" -> "This situation is not ideal" [ section 4.4 ] * "entity MAY attempt use" -> "entity MAY attempt to use"
(was Discuss, No Objection) No Objection
Comment (2020-11-23 for -23) Sent
Thanks for addressing my DISCUSS. Sec 6.1 is much clearer now. I am not sure what "Any delay between request to close the TCP connection and actual closing of the connection (a "half-closed" state) MAY be ignored by the TCPCL entity." means. Presumably if it gets a XFER_ACK, it should pay attention to it.
Comment (2020-02-19 for -18) Sent
Thanks for all of the changes made in response to the LC SECDIR review. Also, thank you for the LC SECDIR review, Chris (Wood)! A reference implementation (as noted in [github-dtn-bpbis-tcpcl]) that includes a Wireshark dissector is phenomenal (and a bar we should all strive towards when making a new protocol) ** Section 2.1. In the definition of the TCPCL Session, “there are two possible transfer streams; one in each direction, with one stream from each entity being the outbound stream and the other being the inbound stream.”, what does this imply about the underlying TCP connections? It would be worth being clearer on the relationship between a given stream and the TCP connection. ** Section 3.1. Is the list of provided convergence layer services enumerated in this section unique to the TCPCL, or would it be expected that all CLs would implement it? If the latter, then why isn’t it in the draft-ietf-dtn-bpbis? ** Section 3.2. Per “Each transfer is performed by an sequence of logical segments of data …”, what is the relationship between a “logical segment” and a “transfer segment” (defined in Section 2.1)? ** Section 3.3. Figure 4. What is the state transition from “Established Session Live” to “Established Session Ending”? Wouldn’t a session go from live to idle when the transfer is done (and then session ending)? Is the Session live to Session ending perhaps due to an interrupt or termination request while the transfer is underway? ** Section 4.2. Given that this new version of the convergence layer is a “green field” (judging from the list if implementations), why not require TLS v1.3 as the minimum (rather than TLS v1.2)? ** Section 8.6. (as suggested by Chris in his telechat SECDIR review) This section isn’t clear on the threat. It seems to cover material relevant to validation better aligned with Section 4.4.2. In particular, the reference to RFC5280 and reminder to check CRLs would be needed guidance to added to the Section 4.4.2 paragraph, “Any certificate received during TLS handshake SHALL be validated up to one or more trusted certificate authority (CA) certificates …” ** Editorial Section 2.1. Typo. s/entitys/entities/ Section 2.1. Typo. s/passivley/passively/ Section 2.1. Typo. s/trasnfer/transfer/ Section 2.1. Typo. s/Inititated/Initiated/g Section 3.1. Typo. s/defintion/definition/ Section 3.1. Typo. s/reciver/receiver/ Section 3.1. Typo. s/transmssion/transmission/ Section 3.2. Typo. s/negligable/negligible/ Section 3.2. Typo. s/by an sequence/by a sequence/ Section 3.3. Typo. s/reeiving/receiving/ Section 3.3. Typo. s/Recevied/Received/ Section 3.4. Typo. s/polcy/policy/ Section 4.2. Typo. s/contanct/contact/ Section 4.2. Typo. s/behavor/behavior/ Section 4.4.1. Typo. s/assoicated/associated/ Section 4.4.2. Typo. s/unauthticate/unauthenticated/ Section 4.4.3. s/Connnection/Connection/ Section 4.6. Typo. s/ mulitplicity/ multiplicity/ Please run a spell-check on the document. Additional typos were found past Section 4.6 but were not documented here
Comment (2020-02-20 for -18) Sent
Thank you for the work put into this document. Due to too many documents for today IESG telechat (and one week of vacations to be honest...), I am balloting "No objection" trusting the ballots of my IESG colleagues/friends. I only quickly browsed the document with my internet area glasses. And I support Suresh's issue around TLS 1.2. -éric
Mirja Kühlewind Former IESG member
Discuss [Treat as non-blocking comment] (2020-02-20 for -18) Sent
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? 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.
Benjamin Kaduk Former IESG member
(was Discuss) Yes
Yes (2021-01-27 for -24) Sent
The new text on TLS usage and the certificate profile is really solid. A huge thanks for getting that put together. I just have a few minor comments left after looking it over: Section 3.4 has some nice discussion in the last paragraph of SNI usage for "virtual host" behavior. It ends with a note that when distinct per DNS name/Node ID certificate are present, operation proceeds "using the SNI value from the peer to select which certificate to use". This is true, but perhaps leaves a bit of subtlety unsaid when Node IDs are involved, since the SNI content is nominally just a DNS name. If it is to be used to select (say) a certificate with only a Node ID, any mapping between DNS name and Node ID used to pick the Node ID based on the provided DNS name would necessarily be conveyed out of band from this protocol. That may be obvious, in which case it should be left as is, but if not it might be worth a note that any relationship between DNS name (SNI) and Node ID used in certificate selection is out of scope of this protocol. The certificate profile in Section 4.4.2 notes that the full certification chain SHOULD be included; it is common (but not universal) that when we provide such guidance, we call out what is to be done with the root CA/trust anchor. (Usually it is not sent, since the receiving party needs to have it already in order to validate the chain.) Also relating to the certificate profile in Section 4.4.2, we list the three potentially relevant key usage values of digitalSignature, keyEncipherment, and keyAgreement. The latter two are (IIUC) only relevant for TLS versions prior to 1.3, since in TLS 1.3 certificates are only used to sign the CertificateVerify message, with key exchange being performed in a separate dedicated mechanism. That said, it may still make sense to mention them here, since TCPCL really only requires the properties of TLS and does not make specific use (that I recall) of TLS 1.3. Section 5.1.1 still seems to talk about the Keepalive Interval as being in the contact header, but it is actually in the SESS_INIT.
Magnus Westerlund Former IESG member
(was No Objection, Discuss, Yes, Discuss, Yes) Yes
Yes (2020-09-30 for -21) Sent for earlier
Adam Roach Former IESG member
No Objection (2020-02-19 for -18) Not sent
Balloting "No Objection" in the sense of "I trust the sponsoring AD, and have no time this ballot cycle to read the document." I have skimmed the document for typical ART-area gotchas, and found none.
Alexey Melnikov Former IESG member
No Objection (2020-02-20 for -18) Sent
[Updated. See the new text at the end.] Thank you for this well written document. It was a pleasure to read! I agree with Suresh, text about TLS 1.2 compatibility looks dodgy. I also have some comments I would really like to see replies to: The document never states byte order for 16/32/64 bit fields. As you are not using CBOR (or any other format), this can't be presumed to be known. 4.7. Session Parameter Negotiation Enable TLS: Negotiation of the Enable TLS parameter is performed by taking the logical AND of the two contact headers' CAN_TLS flags. A local security policy is then applied to determine of the negotiated value of Enable TLS is acceptable. It can be a reasonable security policy to both require or disallow the use of TLS depending upon the desired network flows. Because this state is negotiated over an unsecured medium, there is a risk of a TLS Stripping as described in Section 8. If the Enable TLS state is unacceptable, the node SHALL terminate the session with a reason code of "Contact Failure". Note that this contact failure reason is different than a failure of TLS handshake or TLS authentication after an agreed-upon and acceptable Enable TLS state. If the negotiated Enable TLS value is true and acceptable then TLS negotiation feature (described in Section 4.4) begins immediately following the contact header exchange. While this text is not wrong, I think it is in a wrong section. The rest of Section 4.7 talks about SESS_INIT message, while the TLS flag was sent in Contact Header and was already negotiated by this point. 9.1. Port Number Within the port registry of [IANA-PORTS], TCP port number 4556 has been previously assigned as the default port for the TCP convergence layer in [RFC7242]. This assignment is unchanged by TCPCL version 4, but the assignment reference is updated to this specification. Each TCPCL entity identifies its TCPCL protocol version in its initial contact (see Section 9.2), so there is no ambiguity about what protocol is being used. The related assignments for UDP and DCCP port 4556 (both registered by [RFC7122]) are unchanged. +------------------------+----------------------------+ | Parameter | Value | +------------------------+----------------------------+ | Service Name: | dtn-bundle | | | | | Transport Protocol(s): | TCP | Is there another document that will define use over DCCP? 9.6. XFER_REFUSE Reason Codes 9.7. SESS_TERM Reason Codes In both of these sections: I don't think the document say anywhere how recipients of unrecognized reason codes should handle them. I think the document should say that they must be treated as "Unknown". ********************************************************************** * Note, that I am conducting an experiment when people aspiring to be* * Area Directors get exposed to AD work ("AD shadowing experiment"). * * As a part of this experiment they get to review documents on IESG * * telechats according to IESG Discuss criteria document and their * * comments get relayed pretty much verbatim to relevant editors/WGs. * * As an AD I retain responsibility in defending their position when * * I agree with it. * * Recipients of these reviews are encouraged to reply to me directly * * about perceived successes or failures of this experiment. * ********************************************************************** I also have some comments on Benjamin's comments below marked with "[[Alexey]]:" The following comments were provided by Benjamin Schwartz <firstname.lastname@example.org>: Benjamin would have balloted *No Objections* on this document. He wrote: ## Abstract This version of the TCPCL protocol is based on implementation issues in the earlier TCPCL Version 3 of RFC7242 and updates to the Bundle Protocol (BP) contents This would be better phrased as “This version of the TCPCL protocol resolves implementation issues in …” or similar. ## Section 2.1 The paragraph labeled “TCP Connection” might be better labeled “Connection”, since that is the term being defined. Additionally, it might be clearer to define the “connection” as being the TLS connection when TLS is in use. ## Section 3.1 Terminology: “overlaying” isn’t really a word. Please rephrase. ## Section 3.2 TCP already provides segmentation and ACKs, so why does TCPCL replicate this functionality? The draft should mention the rationale. (I imagine it’s because the Berkeley Sockets API doesn’t surface TCP ACKs in a clear way, or because TLS doesn’t provide authenticated ACKs.) TCP already provides keepalive functionality. Why is it replicated in TCPCL? [[Alexey: I think it was observed that keepalive at the protocol level (or in TLS) work better than TCP keepalives when NATs are used. I am wondering if there is any up-to-date information on this.]] # Section 3.4 “MRU” appears here for the first time without being defined. Similarly, reference is made to a “Transfer MRU”, which also has not yet been defined. Please add forward references or reorder the definitions. # Section 4.4.1 Making compliance with BCP 195 (or any successor) “mandatory” seems too strong, especially since existing implementations will be instantly noncompliant whenever such a successor is published. I would limit the requirement strength to SHOULD when referring to a BCP. [[Alexey: it might be better to use MUST for BCP 195 (maybe reference a specific RFC) and SHOULD for successors?]] # Section 8.9 There is the possibility of a "data dribble" attack in which an entity presents a very small Segment MRU which causes transfers to be split among an large number of very small segments and causes the segmentation overhead to overwhelm the network througput. I’m not sure what it means to “overwhelm the network throughput”, but surely TCP congestion control is already a sufficient mitigation against this concern? Similarly for keepalive spam.
Alvaro Retana Former IESG member
No Objection (for -23) Not sent
Barry Leiba Former IESG member
No Objection (2020-02-13 for -18) Sent
TCPCL: I’ve chosen to mentally pronounce this as “tee cee pickle”. Just so you know... Thank you for the work on this stuff. I have a number of comments, a few of which are substantive but minor; the rest are editorial and don’t need explicit responses. The substantive ones: — Section 3.1 — Session State Changed: The TCPCL supports indication when the session state changes. What does “supports indication” mean? Are you saying that the TCPCL “indicates when the session state changes”? Or does some other entity provide those indications? If the latter, it would be better to say what entity or entities do that, something like, “The TCPCL supports indications of session state changes from the BP agent.” It should also be clear, whatever entity provides the indications, whether they always happen or are optional. For example, can we *rely* on getting “Sesson Negotiating” and “Established” indications, or is it an implementation/deployment/configuration choice that they’re produced? (Same comment for Session Idle Changed, and all other items in this section that talk about indications.) — Section 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. Should there be any recommendation about that implementation-defined time duration, as there is in the previous paragraph? No judgment here, but just a question. I’ll note that if I never close the TCP connection I can say that I’m obeying the “SHALL”, and it’s just that my implementation defines the time duration at 17 years. — Section 4.4 — Once established, there is no mechanism available to downgrade a TCPCL session to non-TLS operation. If this is desired, the entire TCPCL session MUST be terminated and a new non-TLS-negotiated session established. I suggest that it’s unlikely that this will be necessary, and I suggest being stronger about not doing it. Does this work for you?: NEW Once established, there is no mechanism available to downgrade a TCPCL session to non-TLS operation. If such a downgrade is necessary, the entire TCPCL session would have to be terminated and a new non-TLS-negotiated session established. This is NOT RECOMMENDED. END — 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 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. Checking something here… according to this, if A sends SESS_TERM to B: - A MUST NOT begin a new transfer to B - B MUST NOT accept a new transfer from A - But B is allowed to begin a new transfer to A, and A can accept it Is that as intended? - - - - - - - - Editorial comments: — Section 1.1 — o Policies or mechanisms for assigning X.509 certificates, provisioning, deploying, or accessing certificates and private keys, deploying or accessing certificate revocation lists (CRLs), or configuring security parameters on an individual entity or across a network. When a list item contains commas, it’s customary to use semicolons to delimit the outer list, in order to avoid confusion. So: NEW o Policies or mechanisms for assigning X.509 certificates; provisioning, deploying, or accessing certificates and private keys; deploying or accessing certificate revocation lists (CRLs); or configuring security parameters on an individual entity or across a network. END — Section 2.1 — Idle Session: A TCPCL session is idle while the only messages being transmitted or received are KEEPALIVE messages. It would be useful to have a forward reference here, “(see Section 5.1.1)”. Live Session: A TCPCL session is live while any messages are being transmitted or received. Maybe “while any messages other than KEEPALIVEs are being...” — Section 3.3 — The states of a nominal TCPCL session (i.e. without session failures) are indicated in Figure 4. Why “nominal”? Or do you mean to say “normal”? (And “i.e.” needs a comma after it throughout the document, as does “e.g.”.) Session "Live" means transmitting or reeiving over a transfer Typo: “receiving” — Section 3.4 — In a situation where network "goodput" is dynamic, the transfer segmentation size can also be dynamic It may be cute, but is there really a need to make up that word and use it just once? Will everyone understand it, or will it just make some people (whose grasp of English isn’t as good as ours) pause and wonder for an unnecessary moment? I don’t feel strongly about it — just asking the question. — Section 4 — For example, some sessions MAY be opened proactively and maintained for as long as is possible given the network conditions, while other sessions MAY be opened only when there is a bundle that I think these are not BCP 14 “MAY”, but just plain English “may” (or “might”). — Section 4.1 — Therefore, the entity MUST retry the connection setup no earlier than some delay time from the last attempt This starts to look as though “the entity MUST retry the connection setup”, which is not what you mean. You can avoid this by moving the negative, and I think it reads more cleanly that way: NEW Therefore, the entity MUST NOT retry the connection setup without some delay time from the last attempt END — Section 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 in descending order until the passive entity accepts one with a corresponding Contact Header reply. Only upon response of a Contact Header from the passive entity is the TCPCL protocol version established and parameter negotiation begun. 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 different 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. The latter paragraph repeats some of what’s in the former, as though they were written separately and pasted together. May I suggest merging them this way?: NEW 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 acceptable TCPCL protocol version on a first session attempt to a TCPCL peer. If the active entity receives a Contact Header with a different protocol version than the one it had sent, 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. Only upon response of an acceptable Contact Header from the passive entity is the TCPCL protocol version established and parameter negotiation begun. END the node MAY either terminate the session (with a reason code of "Version mismatch") or the node MAY adapt its operation to conform to the older version of the protocol. The first “the node MAY” is already factored out of the “either”, so you can strike the second instance: NEW the node MAY either terminate the session (with a reason code of "Version mismatch") or adapt its operation to conform to the older version of the protocol. END — Section 4.6 — The order and mulitplicity of these Session Extension Items MAY be significant, as defined in the associated type specification(s). This is not a BCP 14 “MAY”, but just a plain English “may” (or “might”). — Section 4.7 — If the either Transfer MRU or Segment MRU is unacceptable “If either the” — words swapped. Session Keepalive: Negotiation of the Session Keepalive parameter is performed by taking the minimum of this two contact headers' Keepalive Interval. “of the two” and “Intervals”. It can be a reasonable security policy to both require or disallow the use of TLS depending upon the desired network flows. You can’t both require and disallow at the same time. You mean “either”, not “both”. — Section 4.8 — Flags: A one-octet field containing generic bit flags This field is called “Item Flags” in the diagram, and should be called that here as well. — Section 5.1.1 — Note: The Keepalive Interval SHOULD NOT be chosen too short as TCP retransmissions MAY occur in case of packet loss. … KEEPALIVE messages MAY experience noticeable latency. These are not BCP 14 “MAY”, but just plain English “may” (or “might”). — Section 5.2 — The choice of the length to use for segments is an implementation matter, but each segment MUST be no larger than the As I recommended earlier, I think MUST NOT is clearer than MUST in sentences such as this, so I suggest, “but each segment MUST NOT be larger than”. — Section 5.2.2 — The order and mulitplicity of these transfer extension items MAY be significant, as defined in the associated type specification(s). This is not a BCP 14 “MAY”, but just a plain English “may” (or “might”). — Section 5.2.4 — As data segments and acknowledgments MAY cross on the wire This is not a BCP 14 “MAY”, but just a plain English “may” (or “might”). bundle after transmitting a XFER_REFUSE message since messages MAY cross on the wire; This is not a BCP 14 “MAY”, but just a plain English “may” (or “might”). Note: If a bundle transmission is aborted in this way, the receiver MAY not receive a segment with the 'END' flag set to 1 for the aborted bundle. This is not a BCP 14 “MAY”, but just a plain English “may” (or “might”). But, perhaps what you really want here is “will not”? — Section 5.2.5 — Flags: A one-octet field containing generic bit flags This field is called “Item Flags” in the diagram, and should be called that here as well.
Deborah Brungard Former IESG member
No Objection (for -18) Not sent
Martin Vigoureux Former IESG member
No Objection (for -18) Not sent
Suresh Krishnan Former IESG member
(was Discuss) No Objection
No Objection (2020-03-13 for -19) Sent
Thanks for addressing my DISCUSS points.