Delay-Tolerant Networking TCP Convergence-Layer Protocol Version 4
RFC 9174

Received changes through RFC Editor sync (created alias RFC 9174, changed title to 'Delay-Tolerant Networking TCP Convergence-Layer Protocol Version 4', changed abstract to 'This document describes a TCP convergence layer (TCPCL) for Delay-Tolerant Networking (DTN).  This version of the TCPCL protocol resolves implementation issues in the earlier TCPCL version 3 as defined in RFC 7242 and provides updates to the Bundle Protocol (BP) contents, encodings, and convergence-layer requirements in BP version 7 (BPv7).  Specifically, TCPCLv4 uses BPv7 bundles encoded by the Concise Binary Object Representation (CBOR) as its service data unit being transported and provides a reliable transport of such bundles.  This TCPCL version also includes security and extensibility mechanisms.', changed pages to 62, changed standardization level to Proposed Standard, changed state to RFC, added RFC published event at 2022-01-31, changed IESG state to RFC Published)

[Ballot comment]
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.

Yes, this is approved. However, I ask the authors to add a reference to the ASN.1 specification in Section 9.9 to be clearly specify object identifier:

[X.680] ITU-T, "Information technology -- Abstract Syntax Notation
One (ASN.1): Specification of basic notation", ITU-T
Recommendation X.680, ISO/IEC 8824-1:2015, August 2015,
.

(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Functions Operator has completed its review of draft-ietf-dtn-tcpclv4-24. If any part of this review is inaccurate, please let us know.

The IANA Functions Operator understands that, upon approval of this document, there are nine actions which we must complete.

First, in the Service Name and Transport Protocol Port Number Registry located at:

https://www.iana.org/assignments/service-names-port-numbers/

the registration for port number 4556 will have the reference changed for the TCP port. The TCP port number 4556 will have its reference changed to [ RFC-to-be ]. The UDP and DCCP port number 4556 references will remain unchanged.

NOTE: According to Section 8.1.1 of RFC 6335, the contact listed for the port in Section 9.1 should be the IETF Chair  rather than the IESG.

Second, in the Bundle Protocol TCP Convergence-Layer Version Numbers registry on the Bundle Protocol registry page located at:

https://www.iana.org/assignments/bundle/

a single, new version number will be added as follows:

Value: 4
Description: TCPCLv4
Reference: [ RFC-to-be ]

Third, a new registry is to be created called the Bundle Protocol TCP Convergence-Layer Version 4 Session Extension Types registry. The new registry will be located on the Bundle Protocol registry page located at:

https://www.iana.org/assignments/bundle/

The range of values in the registry are from 0x0000 to 0xFFFF. The new registry will be managed via Expert Review as defined in RFC 8126 for values from 0x0001--0x7FFF. Values from 0x8000-0xFFFF are for private/experimental use as defined in RFC 8126. The value 0x0000 is to be marked reserved.

Fourth, a new registry is to be created called the Bundle Protocol TCP Convergence-Layer Version 4 Transfer Extension Types registry. The new registry will be located on the Bundle Protocol registry page located at:

https://www.iana.org/assignments/bundle/

The range of values in the registry are from 0x0000 to 0xFFFF. The new registry will be managed via Expert Review as defined in RFC 8126 for values from 0x0001--0x7FFF. Values from 0x8000-0xFFFF are for private/experimental use as defined in RFC 8126. The value 0x0000 is to be marked reserved. There is a single, new registration in the new registry as follows:

Code: 0x0001
Transfer Extension Type: Transfer Length Extension
Reference: [ RFC-to-be ]

Fifth, a new registry is to be created called the Bundle Protocol TCP Convergence-Layer Version 4 Message Types registry. The new registry will be located on the Bundle Protocol registry page located at:

https://www.iana.org/assignments/bundle/

The range of values in the registry are from 0x00 to 0xFF. The new registry will be managed via Expert Review as defined in RFC 8126 for values from 0x0001--0xEF. Values from 0xF0-0xFF are for private/experimental use as defined in RFC 8126. The value 0x00 is to be marked reserved. There are initial registrations in the new registry as follows:

+============+==========================+===============+
| Code | Message Type | Reference |
+============+==========================+===============+
| 0x00 | Reserved | [ RFC-to-be ] |
+------------+--------------------------+===============+
| 0x01 | XFER_SEGMENT | [ RFC-to-be ] |
+------------+--------------------------+===============+
| 0x02 | XFER_ACK | [ RFC-to-be ] |
+------------+--------------------------+===============+
| 0x03 | XFER_REFUSE | [ RFC-to-be ] |
+------------+--------------------------+===============+
| 0x04 | KEEPALIVE | [ RFC-to-be ] |
+------------+--------------------------+===============+
| 0x05 | SESS_TERM | [ RFC-to-be ] |
+------------+--------------------------+===============+
| 0x06 | MSG_REJECT | [ RFC-to-be ] |
+------------+--------------------------+===============+
| 0x07 | SESS_INIT | [ RFC-to-be ] |
+------------+--------------------------+===============+
| 0x08--0xEF | Unassigned | [ RFC-to-be ] |
+------------+--------------------------+===============+
| 0xF0--0xFF | Private/Experimental Use | [ RFC-to-be ] |
+------------+--------------------------+===============+

Sixth, a new registry is to be created called the Bundle Protocol TCP Convergence-Layer Version 4 XFER_REFUSE Reason Codes registry. The new registry will be located on the Bundle Protocol registry page located at:

https://www.iana.org/assignments/bundle/

The range of values in the registry are from 0x00 to 0xFF. The new registry will be managed via Expert Review as defined in RFC 8126 for values from 0x0001--0xEF. Values from 0xF0-0xFF are for private/experimental use as defined in RFC 8126. The value 0x00 is to be marked reserved. There are initial registrations in the new registry as follows:

+============+==========================+===============+
| Code | Refusal Reason | Reference |
+============+==========================+===============+
| 0x00 | Unknown | [ RFC-to-be ] |
+------------+--------------------------+===============+
| 0x01 | Completed | [ RFC-to-be ] |
+------------+--------------------------+===============+
| 0x02 | No Resources | [ RFC-to-be ] |
+------------+--------------------------+===============+
| 0x03 | Retransmit | [ RFC-to-be ] |
+------------+--------------------------+===============+
| 0x04 | Not Acceptable | [ RFC-to-be ] |
+------------+--------------------------+===============+
| 0x05 | Extension Failure | [ RFC-to-be ] |
+------------+--------------------------+===============+
| 0x06 | Session Terminating | [ RFC-to-be ] |
+------------+--------------------------+===============+
| 0x07--0xEF | Unassigned | [ RFC-to-be ] |
+------------+--------------------------+===============+
| 0xF0--0xFF | Private/Experimental Use | [ RFC-to-be ] |
+------------+--------------------------+===============+

Seventh, a new registry is to be created called the Bundle Protocol TCP Convergence-Layer Version 4 SESS_TERM Reason Codes registry. The new registry will be located on the Bundle Protocol registry page located at:

https://www.iana.org/assignments/bundle/

The range of values in the registry are from 0x00 to 0xFF. The new registry will be managed via Expert Review as defined in RFC 8126 for values from 0x0001--0xEF. Values from 0xF0-0xFF are for private/experimental use as defined in RFC 8126. The value 0x00 is to be marked reserved. There are initial registrations in the new registry as follows:

+============+==========================+===============+
| Code | Termination Reason | Reference |
+============+==========================+===============+
| 0x00 | Unknown | [ RFC-to-be ] |
+------------+--------------------------+===============+
| 0x01 | Idle timeout | [ RFC-to-be ] |
+------------+--------------------------+===============+
| 0x02 | Version mismatch | [ RFC-to-be ] |
+------------+--------------------------+===============+
| 0x03 | Busy | [ RFC-to-be ] |
+------------+--------------------------+===============+
| 0x04 | Contact Failure | [ RFC-to-be ] |
+------------+--------------------------+===============+
| 0x05 | Resource Exhaustion | [ RFC-to-be ] |
+------------+--------------------------+===============+
| 0x06--0xEF | Unassigned | [ RFC-to-be ] |
+------------+--------------------------+===============+
| 0xF0--0xFF | Private/Experimental Use | [ RFC-to-be ] |
+------------+--------------------------+===============+

Eighth, a new registry is to be created called the Bundle Protocol TCP Convergence-Layer Version 4 MSG_REJECT Reason Codes registry. The new registry will be located on the Bundle Protocol registry page located at:

https://www.iana.org/assignments/bundle/

The range of values in the registry are from 0x00 to 0xFF. The new registry will be managed via Expert Review as defined in RFC 8126 for values from 0x0001--0xEF. Values from 0xF0-0xFF are for private/experimental use as defined in RFC 8126. The value 0x00 is to be marked reserved. There are initial registrations in the new registry as follows:

+============+==========================+===============+
| Code | Rejection Reason | Reference |
+============+==========================+===============+
| 0x00 | reserved | [ RFC-to-be ] |
+------------+--------------------------+===============+
| 0x01 | Message Type Unknown | [ RFC-to-be ] |
+------------+--------------------------+===============+
| 0x02 | Message Unsupported | [ RFC-to-be ] |
+------------+--------------------------+===============+
| 0x03 | Message Unexpected | [ RFC-to-be ] |
+------------+--------------------------+===============+
| 0x04--0xEF | Unassigned | [ RFC-to-be ] |
+------------+--------------------------+===============+
| 0xF0--0xFF | Private/Experimental Use | [ RFC-to-be ] |
+------------+--------------------------+===============+

Ninth, in the SMI Security for PKIX Extended Key Purpose registry on the Structure of Management Information (SMI) Numbers (MIB Module Registrations) registry page located at:

https://www.iana.org/assignments/smi-numbers/

a single, new registration will be made as follows:

Decimal: [ TBD-at-Registration ]
Description: id-kp-bundleSecurity
Reference: [ RFC-to-be ]

As this document requests registrations in a Specification Required (see RFC 8126) registry, we will initiate the required Expert Review via a separate request. This review must be completed before the document's IANA state can be changed to "IANA OK."

The IANA Functions Operator understands that these are the only actions required to be completed upon approval of this document.

Note:  The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is meant only to confirm the list of actions that will be performed.

Thank you,

Sabrina Tanamal
Senior IANA Services Specialist

The following Last Call announcement was sent out (ends 2021-01-18):

From: The IESG
To: IETF-Announce
CC: Edward Birrane , magnus.westerlund@ericsson.com, dtn-chairs@ietf.org, draft-ietf-dtn-tcpclv4@ietf.org, edward.birrane@jhuapl.edu, dtn@ietf.org
Reply-To: last-call@ietf.org
Sender:
Subject: Last Call:  (Delay-Tolerant Networking TCP Convergence Layer Protocol Version 4) to Proposed Standard


The IESG has received a request from the Delay/Disruption Tolerant Networking
WG (dtn) to consider the following document: - 'Delay-Tolerant Networking TCP
Convergence Layer Protocol Version 4'
  as Proposed Standard

This is a second IETF last call due to extensive changes since previous IETF
last call.

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
last-call@ietf.org mailing lists by 2021-01-18. Exceptionally, comments may
be sent to iesg@ietf.org instead. In either case, please retain the beginning
of the Subject line to allow automated sorting.

Abstract


  This document describes a TCP-based convergence layer (TCPCL) for
  Delay-Tolerant Networking (DTN).  This version of the TCPCL protocol
  resolves implementation issues in the earlier TCPCL Version 3 of
  RFC7242 and updates to the Bundle Protocol (BP) contents, encodings,
  and convergence layer requirements in BP Version 7.  Specifically,
  the TCPCLv4 uses CBOR-encoded BPv7 bundles as its service data unit
  being transported and provides a reliable transport of such bundles.
  This version of TCPCL also includes security and extensibility
  mechanisms.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-dtn-tcpclv4/



No IPR declarations have been submitted directly on this I-D.

[Ballot discuss]
[retaining discuss section unchanged from the -21 in order to update the comment
section, even though much progress has been made on this front at IETF 109 and via
email.  IIRC we have a thread open with the PKIX extended key purpose DE for how
to modify the TLS certificate validation procedures.]
========================== discuss section from -21 below ====================
[This is essentially a restatement of the comments at
https://mailarchive.ietf.org/arch/msg/dtn/jnafmsDt0OXUhYlBwT_U9PuNV5c/
but rephrased to be a standalone review rather than continuation of an
existing conversation.]

I'm really impressed by the new text about PKIX environments/CA policy,
and entity identification; thank you!

I suspect that, with one exception, we have similar understandings of
what is supposed to happen, but may need to wrangle the actual text on
the page a little more to get to the right place.

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

The one exception relates to the security properties of having the
certificate validation procedure be a prioritized list of steps with
which steps to use being dependent on the contents of the received
certificate.  Specifically, if we will end up letting a peer with a
DNS-ID cert authenticate as any node ID, then there is no security gain
from having the node ID in the cert in the first place, since the
attacker will just skip that step.  The value of NODE-ID comes into play
when we know, before we go into the validation procedure, that the
legitimate peer will have the expected NODE-ID in their certificate.
Obviously we cannot expect that to always be the case, given that we aim
to be compatible with DTN-Ignorant CAs, so we will need to specify some
granularity for when we do or do not require the NODE-ID to be present.
There are a number of possibilities here and I don't know which is going
to be best for the broadest group of deployments.  Some simple ideas for
consideration include:

(a) any given node either always or never requires NODE-ID
(b) any given interface either always or never requires NODE-ID
(c) push it to the discovery protocol/"out of band configuration"
(d) a trust-on-first-use-like option of "once you've seen a NODE-ID for
  a given node ID, always require NODE-ID in the future for that node
  ID.  (This has pretty significant risks without a way to "undo the
  latch" but if generating a new node ID is cheap they may be
  tolerable.)
(e) define new URI scheme(s) that have similar semantics to the current
  ones but require NODE-ID for authentication.
(f) similar to (e), apply additional granularity based on URI scheme or
  scheme-specific structure (e.g., certain prefixes/suffixes of names
  but not others

In theory there are similar considerations between DNS-ID and NETWORK-ID
(see below for comment about the "NETWORK-ID" name), but since they are
both expected to be coming from the Web PKI and both have similarly weak
models for node authentication it's not clear to me that we should spend
much effort on a complicated procedure for there.  Something simple like
"if you have a (stable) name for the peer, expect DNS-ID; if you only
have an IP address, use NETWORK-ID" should work quite well (and may even
be what you intended anyway).

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

The main place where I'm still seeing a need for wordsmithing is in the
authentication procedures in Section 4.4.3.  I see from the previous
discussion that the intent of "SHALL attempt to authenticate [...] If
and security policy disallows an unauthenticated ,
the entity SHALL terminate the session" is for security policy to be
able to say "yes, there's no -ID and I'm fine with that (or
potentially even "the -ID that is present failed validation and I'm
fine with that"), which is a surprising wording to me but I guess
technically okay.  (The current wording strongly implies, to me, that
if validation fails, the session gets terminated; maybe it's something
about the double negative in "disallows an unauthenticated" that makes
the "security policy" aspect feel very weak.)  What seems significantly
problematic to me, though, is the requirement as-written to attempt
validation of all three types of ID (NODE-ID, DNS-ID, and NETWORK-ID).
In the expected case where a peer's certificate contains only one of the
three (or, perhaps, a NODE-ID and one other name type), this means that
security policy would have to be some complex matrix with
interdependencies between the various types (allow unauthenticated host
by DNS-ID if NETWORK-ID present and valid, etc.) that prevents
validation of each type of name being performed independently.

In particular, this "must attempt all three types" logic seems at odds
with the first paragraph of the section that says that attempting host
name validation is optional.

So, I would have expected the text to flow more along the lines of (but
written less hastily) "security policy determines, for a given connection,
which identity type(s) is expected, and validation is attempted for
those specific type(s).  Failed authentication results in session
termination." It is okay with me for security policy to allow continuing
with the connection even when validation is attempted but fails, but I'm
not sure that we currently have a fully consistent picture about
how/when this happens.  In particular, I see a note in Section 8.10.1
that using TLS in a way which does not authenticate both peers is out of
scope of this document" along with a mention of similarities to
opportunistic security, yet letting security policy proceed with an
unauthenticated peer seems at odds with that "out of scope".  We should
have a clearer picture of whether opportunistic security with no or
failed authentication of one or both peers is permitted by this
document.


I think we can also wordsmith the setting of CAN_TLS a little more;
previous discussion indicated a desire to (e.g.) not require TLS when
operating over IPsec, but that's a different criterion than "capable of
exchanging messages [with TLS]".  It's also inconsistent with a desire
to make TLS support mandatory to implement (but not mandatory to use),
since mandatory to implement implies mandatory to be "capable of
exchanging messages with TLS", thus mandatory to use.

[Ballot comment]
Section 4.6

  When the active entity initiates a TCPCL session, it is likely based
  on routing information which binds a Node ID to CL parameters.  If
  the active entity receives a SESS_INIT with different Node ID than
  was intended for the TCPCL session, the session MAY be allowed to be
  established.  If allowed, such a session SHALL be associated with the
  Node ID provided in the SESS_INIT message rather than any intended
  value.

I would prefer if we could find some way to reiterate that the Node ID
in question must still pass the NODE-ID verification procedures from
Section 4.4.3, though everything I've come up with so far feels a bit
clunky.

Section 5.1.1

  As described in Section 4.3, a negotiated parameter of each session
  is the Session Keepalive interval.  If the negotiated Session
  Keepalive is zero (i.e., one or both contact headers contains a zero
  Keepalive Interval), then the keepalive feature is disabled.  There

This is SESS_INIT, not contact header.  (I'm pretty sure this is the
last one to change.)

[Ballot comment]
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"

[Ballot comment]
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.

[Ballot discuss]
Sec 6.1. I read this sentence several times and could not figure out what it is saying, and fear there could be interoperability problems.
"When performing an unclean termination, a
  transmitting node SHALL treat either sending or receiving a SESS_TERM
  message (i.e., before the final acknowledgment) as a failure of the
  transfer.  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."

First of all, "failure of the transfer" is ambiguous because there may be two transfers going on, one in each direction.

Second, I would like further clarity on what it means that nodes "SHALL" consider it "a failure of the transfer". What is actionable if it's a failure? If nothing is actionable, it shouldn't be a SHALL. Does this mean that in subsequent sessions I must resend the whole bundle?

Can you list some reasons why an endpoint would choose to close uncleanly? Some motivation might provide helpful context.

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

- But as a receiver, how do I know that the termination is unclean? Have I made an independent decision to close uncleanly? Am I to take the receipt of a SESS_TERM without my having sent XFER_ACK as an unclean close? If I sent XFER_ACK, how do I know that the sender sent it? And what does it mean, as a receiver, that the transfer "failed" if I have all the data?

[Ballot comment]
Thanks for this document. I have numerous minor concerns:

Sec 4.3. "the TCP connection SHALL be closed." Can you clarify if this is a clean close (FIN) or abort (RST)? In fact, if you always mean FIN, it might be good to clarify that in the terminology section to indicate that there are no RSTs anywhere.

Sec 4.3. VERSION_MISMATCH would benefit from being split into VERSION_TOO_HIGH and VERSION_TOO_LOW. For example, if the passive is at v4 only and the active supports v1, v2, and v3, it will take three tries to figure out that there is no way for these nodes to communicate. Even better would be a QUIC-style Version Negotiation message that would communicate the options in 1 RTT.

There are few items that seem to be artifacts of TLS happening after session negotiation in v3:

Sec 4.4.3. "If certificate validation
  fails or if security policy disallows a certificate for any reason,
  the entity SHALL terminate the session"

I don't understand this; certificate validation generally occurs during the TLS handshake, where there is no session?

Sec 4.4.3
"the active
  entity SHALL authenticate the DNS name (of the passive entity) used
  to initiate the TCP connection"
s/TCP Connection/TLS session. TCP connections don't consider DNS at all.

Sec 4.5.
"After the initial exchange of a Contact Header, all messages
  transmitted over the session are identified by a one-octet header
  with the following structure:"

Obviously, TLS handshake messages are after the Contact Header and are not prepended by these headers. Perhaps this is an artifact from v3?

Sec 4.7
"Once this process of parameter negotiation is completed (which
  includes a possible completed TLS handshake of the connection to use
  TLS),"

The TLS handshake occurs before parameter negotiation.

Sec 5.2.4 I find it odd that each CL would have its own set of reason codes that it will simply pass to the bundle layer. Far better for it to be a common set of CL-agnostic errors that the bundle layer implements, as they literally do not matter to the CL at all.

[Ballot comment]
Thanks for this document. I have numerous minor concerns:

Sec 4.3. "the TCP connection SHALL be closed." Can you clarify if this is a clean close (FIN) or abort (RST)? In fact, if you always mean FIN, it might be good to clarify that in the terminology section to indicate that there are no RSTs anywhere.

Sec 4.3. VERSION_MISMATCH would benefit from being split into VERSION_TOO_HIGH and VERSION_TOO_LOW. For example, if the passive is at v4 only and the active supports v1, v2, and v3, it will take three tries to figure out that there is no way for these nodes to communicate. Even better would be a QUIC-style Version Negotiation message that would communicate the options in 1 RTT.

There are few items that seem to be artifacts of TLS once happening after session negotiation:

Sec 4.4.3. "If certificate validation
  fails or if security policy disallows a certificate for any reason,
  the entity SHALL terminate the session"

I don't understand this; certificate validation generally occurs during the TLS handshake, where there is no session?

Sec 4.4.3
"the active
  entity SHALL authenticate the DNS name (of the passive entity) used
  to initiate the TCP connection"
s/TCP Connection/TLS session. TCP connections don't consider DNS at all.

Sec 4.5.
"After the initial exchange of a Contact Header, all messages
  transmitted over the session are identified by a one-octet header
  with the following structure:"

Obviously, TLS handshake messages are after the Contact Header and are not prepended by these headers. Perhaps this is an artifact from v3?

Sec 4.7
"Once this process of parameter negotiation is completed (which
  includes a possible completed TLS handshake of the connection to use
  TLS),"

The TLS handshake occurs before parameter negotiation.

Sec 5.2.4 I find it odd that each CL would have its own set of reason codes that it will simply pass to the bundle layer. Far better for it to be a common set of CL-agnostic errors that the bundle layer implements, as they literally do not matter to the CL at all.

Sec 6.1. I read this sentence several times and could not figure out what it is saying:
"When performing an unclean termination, a
  transmitting node SHALL treat either sending or receiving a SESS_TERM
  message (i.e., before the final acknowledgment) as a failure of the
  transfer.  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."

First of all, "failure of the transfer" is ambiguous because there may be two transfers going on, one in each direction.

Second, I would like further clarity on what it means that nodes "SHALL" consider it "a failure of the transfer". Does this mean that in subsequent sessions I must resend the whole bundle?

Can you list some reasons why an endpoint would choose to close uncleanly? Some motivation might provide helpful context.

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

But as a receiver, how do I know that the termination is unclean? Have I made an independent decision to close uncleanly? Am I to take the receipt of a SESS_TERM without my having sent XFER_ACK as an unclean close? If I sent XFER_ACK, how do I know that the sender sent it? And what does it mean, as a receiver, that the transfer "failed" if I have all the data?

[Ballot discuss]
[This is essentially a restatement of the comments at
https://mailarchive.ietf.org/arch/msg/dtn/jnafmsDt0OXUhYlBwT_U9PuNV5c/
but rephrased to be a standalone review rather than continuation of an
existing conversation.]

I'm really impressed by the new text about PKIX environments/CA policy,
and entity identification; thank you!

I suspect that, with one exception, we have similar understandings of
what is supposed to happen, but may need to wrangle the actual text on
the page a little more to get to the right place.

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

The one exception relates to the security properties of having the
certificate validation procedure be a prioritized list of steps with
which steps to use being dependent on the contents of the received
certificate.  Specifically, if we will end up letting a peer with a
DNS-ID cert authenticate as any node ID, then there is no security gain
from having the node ID in the cert in the first place, since the
attacker will just skip that step.  The value of NODE-ID comes into play
when we know, before we go into the validation procedure, that the
legitimate peer will have the expected NODE-ID in their certificate.
Obviously we cannot expect that to always be the case, given that we aim
to be compatible with DTN-Ignorant CAs, so we will need to specify some
granularity for when we do or do not require the NODE-ID to be present.
There are a number of possibilities here and I don't know which is going
to be best for the broadest group of deployments.  Some simple ideas for
consideration include:

(a) any given node either always or never requires NODE-ID
(b) any given interface either always or never requires NODE-ID
(c) push it to the discovery protocol/"out of band configuration"
(d) a trust-on-first-use-like option of "once you've seen a NODE-ID for
  a given node ID, always require NODE-ID in the future for that node
  ID.  (This has pretty significant risks without a way to "undo the
  latch" but if generating a new node ID is cheap they may be
  tolerable.)
(e) define new URI scheme(s) that have similar semantics to the current
  ones but require NODE-ID for authentication.
(f) similar to (e), apply additional granularity based on URI scheme or
  scheme-specific structure (e.g., certain prefixes/suffixes of names
  but not others

In theory there are similar considerations between DNS-ID and NETWORK-ID
(see below for comment about the "NETWORK-ID" name), but since they are
both expected to be coming from the Web PKI and both have similarly weak
models for node authentication it's not clear to me that we should spend
much effort on a complicated procedure for there.  Something simple like
"if you have a (stable) name for the peer, expect DNS-ID; if you only
have an IP address, use NETWORK-ID" should work quite well (and may even
be what you intended anyway).

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

The main place where I'm still seeing a need for wordsmithing is in the
authentication procedures in Section 4.4.3.  I see from the previous
discussion that the intent of "SHALL attempt to authenticate [...] If
and security policy disallows an unauthenticated ,
the entity SHALL terminate the session" is for security policy to be
able to say "yes, there's no -ID and I'm fine with that (or
potentially even "the -ID that is present failed validation and I'm
fine with that"), which is a surprising wording to me but I guess
technically okay.  (The current wording strongly implies, to me, that
if validation fails, the session gets terminated; maybe it's something
about the double negative in "disallows an unauthenticated" that makes
the "security policy" aspect feel very weak.)  What seems significantly
problematic to me, though, is the requirement as-written to attempt
validation of all three types of ID (NODE-ID, DNS-ID, and NETWORK-ID).
In the expected case where a peer's certificate contains only one of the
three (or, perhaps, a NODE-ID and one other name type), this means that
security policy would have to be some complex matrix with
interdependencies between the various types (allow unauthenticated host
by DNS-ID if NETWORK-ID present and valid, etc.) that prevents
validation of each type of name being performed independently.

In particular, this "must attempt all three types" logic seems at odds
with the first paragraph of the section that says that attempting host
name validation is optional.

So, I would have expected the text to flow more along the lines of (but
written less hastily) "security policy determines, for a given connection,
which identity type(s) is expected, and validation is attempted for
those specific type(s).  Failed authentication results in session
termination." It is okay with me for security policy to allow continuing
with the connection even when validation is attempted but fails, but I'm
not sure that we currently have a fully consistent picture about
how/when this happens.  In particular, I see a note in Section 8.10.1
that using TLS in a way which does not authenticate both peers is out of
scope of this document" along with a mention of similarities to
opportunistic security, yet letting security policy proceed with an
unauthenticated peer seems at odds with that "out of scope".  We should
have a clearer picture of whether opportunistic security with no or
failed authentication of one or both peers is permitted by this
document.


I think we can also wordsmith the setting of CAN_TLS a little more;
previous discussion indicated a desire to (e.g.) not require TLS when
operating over IPsec, but that's a different criterion than "capable of
exchanging messages [with TLS]".  It's also inconsistent with a desire
to make TLS support mandatory to implement (but not mandatory to use),
since mandatory to implement implies mandatory to be "capable of
exchanging messages with TLS", thus mandatory to use.

[Ballot comment]
Section 4.4.1

I probably would not have picked the name "NETWORK-ID" for the iPAddress
SAN (since identifying a "network" would call to mind an IP prefix or
similar).  If you're not tied to it, I would propose "IPADDR-ID".  (Full
disclosure: I also asked the saag@ietf.org about this topic; responses
so far seem to support IPADDR-ID.)

Section 4.4.2

Apparently I didn't find this remarkable the first time around, but "the
SNI text" is not a common phrase in the TLS community; we would
typically refer to 'the contents of the "server_name" extension' or
perhaps the 'HostName in the "server_name" extension'.  In this context
such verbosity may not be needed, with "the SNI contents holds the
network-layer name for the passive entity" seeming to suffice.

Section 4.6

  Keepalive Interval:  A 16-bit unsigned integer indicating the minimum
      interval, in seconds, to negotiate the Session Keepalive using the
      method of Section 4.7.

nit: maybe "to negotiate as"?  (The current wording sounds like the
Session Keepalive is negotiated periodically at some interval.)

Section 4.7

This still has some stale "contact header" references that should be
switched to SESS_INIT (for Keeplive Interval and the MTUs), as does
section 5.1.1.

Section 8.7

We mention "renegotiation of the TLS connection", which is only defined
for TLS 1.2 and older, but we now seem to only be referencing TLS 1.3,
so renegotiation is in that sense undefined.

[Ballot comment]
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

[Ballot 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?


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.

[Ballot 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.

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?

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?

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!

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?

6) sec 5.1.2:
What is the entity receiving the MSG_REJECT supposed to do?

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?

8) sec 5.2.4: Can you maybe explain why the XFER_REFUSE is a message/feature of the CL and not the BP?

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!

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?

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!

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!

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?

[Ballot comment]
[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 :

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.

[Ballot discuss]
In Section 4.2 we say that "If an entity is capable of [...] TLS 1.2 or
any successors [...], the CAN_TLS flag within its contanct [sic] header
SHALL be set to 1."  I don't understand why we should allow in the spec
for an entity to not be capable of TLS 1.2+.  Can you give me some
examples of situations when you would want to use a TCPCL but cannot use
TLS with it?  A new major version of TCPCL would be the least-bad time
to make a clean break and mandate TLS...

There's some good discussion in Section 4.4.2 of the mechanics of TLS
X.509 certificate authentication; thanks for that!  I do think that
there's a fairly critical omission, though, namely that the BP agent
needs to provide to the TCPCL Entity the Node ID of the expected next
hop from the routing decision (in addition to the hostname/IP address to
which to initiate a TCP connection), and this Node ID must also be
validated against the TLS certificate and the SESS_INIT from the peer.
Otherwise we are in effect falling back to an authorization policy of
"anyone with a cert with a uniformResourceIdentifier SAN of the expected
scheme is authorized to do anything", which is a pretty weak policy.
(In some sense, if we require this, then the Node ID in the SESS_INIT
becomes redundant, though I think there are some edge cases where it
would still be needed in order for both endpoints to agree on the
communicating identities.)

I also think we need to discuss the TLS X.509 authentication model that
will be used, i.e., "what PKI is being used?".  (To be clear, I don't
know that any changes to the text will be required, but do think we
should be sure we have a clear picture of what the expected deployment
strategies are.) The usage of SNI to pick a cert and the DNS-ID (RFC
6125) to authenticate a hostname might imply that the typical "Web PKI"
(that deals in hostnames) is intended, but the URIs we need to
authenticate Node IDs are not commonly certified by that PKI.  Since the
server has to present a single certificate even if it is attempting to
authenticate as both DNS-ID and the NodeID URI, it seems like it would
be challenging to use this scheme in practice against the Web PKI roots.
This hybrid of hostname and Node-ID authentication also suffers from an
awkward ordering issue when the TLS handshake occurs before the
SESS_INIT messages that convey what Node ID is intended to be
authenticated -- this requires implementations to use a TLS stack that
preserves the peer's certificate and perform name validation after a
completed TLS handshake, which is moving more of the complications out
of the TLS stack and into the application logic (which introduces risk
of security-relevant bugs).  It also means that certificate selection
must be based solely on SNI hostname and cannot involve the requested
Node ID.  [There is in theory the selectable name_type field in the TLS
server_name extension, but in practice that joint has rusted shut and it
seems unlikely that there would be much implementation traction to
define a name type for DTN Node ID; RFC 6066 also fails to give a clear
indication of the intended semantics when multiple name types are
present.]

Please double-check for lingering text that assumes the RFC 7242
behaviors where all parameters are in the contact header (vs. SESS_INIT)
and use of SDNV encoding vs. fixed-lengths.  I noted several instances
in the COMMENT section, but do not claim to have made an exhaustive
review.

[Ballot comment]
Please consider the comments from the secdir telechat review.

Abstract

  This document describes a TCP-based convergence layer (TCPCL) for
  Delay-Tolerant Networking (DTN).  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, encodings,
  and convergence layer requirements in BP Version 7.  Specifically,

nit: I would hope that it's the changes in this version that are
intended to resolve implementation issues from the previous version, and
not some explicitly-operations-unfriendly protocol that seeks to
maximize implementation issues in deployment ;)

Section 1.1

  o  Mechanisms for locating or identifying other bundle entities
      (peers) within a network or across an internet.  The mapping of
      Node ID to potential CL protocol and network address is left to

nit: I don't think even draft-ietf-dtn-bpbis even really defines "CL" as
an acronym (just "CLA"), so we should probably expand it somewhere.

  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.

In a similar vein to my Discuss points, I think I'm going to need some
more convincing that (some of) these are best left out of scope.  To
help me understand the current ecosystem, could you give me some
pointers to what has actually been used for deployments?  The security
of the system as a whole rests on the criteria used by CAs on whether to
certify a given public key as being associated with a Node ID (or host
name) and the trustworthiness of the CAs to apply those rules accurately
and without error.  (Perhaps this is not what you meant by "assigning
X.509 certificates", though.)

  o  Uses of TLS which are not based on X.509 certificate
      authentication (see Section 8.10.2) or in which authentication is
      not available (see Section 8.10.1).

Section 4.2 seems to describe "opportunistic TLS" and reference RFC
7435, so I don't think we need to say "or in which authentication is not
available" here.

Section 2.1

        A TCPCL Entity MAY support zero or more passive listening
        elements that listen for connection requests from other TCPCL
        Entities operating on other entitys in the network.

nit: "entities"

        A TCPCL Entity MAY passivley initiate any number of TCPCL
        Sessions from requests received by its passive listening
        element(s) if the entity uses such elements.

I'm not sure what "passively initiate" is supposed to mean.  Is this a
session initiation that's triggered by an incoming message in some
fashion?
Also, nit: "passively"

  TCPCL Session:  A TCPCL session (as opposed to a TCP connection) is a
      TCPCL communication relationship between two TCPCL entities.
      Within a single 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.
      The lifetime of a TCPCL session is bound to the lifetime of an
      underlying TCP connection.  A TCPCL session is terminated when the
      TCP connection ends, due either to one or both entities actively
      closing the TCP connection or due to network errors causing a
      failure of the TCP connection.  For the remainder of this
      document, the term "session" without the prefix "TCPCL" refers to
      a TCPCL session.

This leaves me confused as to whether there is one TCP connection or two
between interacting entities ("two possible transfer streams" vs. "the
TCP connection ends") -- are the two transfer streams just the two
directions of the single TCP connection?

  Idle Session:  A TCPCL session is idle while the only messages being
      transmitted or received are KEEPALIVE messages.

  Live Session:  A TCPCL session is live while any messages are being
      transmitted or received.

nit: any messages other than KEEPALIVE, I presume.


In Figure 2, are any of the respective sessions 1 through n targetting
the same "other TCPCL Entity's Listener" or is the idea that they're 1:1
session:other-entity?  If they're 1:1, it might be worth trying to make
the arrow from #n go to the box in the background instead of the one in
the foreground.  (This potentially holds true whether the Acks are TCP
ACKs or XFER_ACKs.)

In Figure 3, if there's actually only one (bidirectional) TCP
connection, we might want to think about indicating the sequencing
between Acks and Segments in the same direction.

Section 3.1

  Session State Changed:  The TCPCL supports indication when the
      session state changes.  The top-level session states indicated
      are:

Is this an indication from the TCPCL Entity to the BP agent?  (Similarly
for "Idle Changed", etc.)

      ongoing transfer.  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.

nit: run-on sentence.

  Begin Transmission:  The principal purpose of the TCPCL is to allow a
      BP agent to transmit bundle data over an established TCPCL
      session.  Transmission request is on a per-session basis, the CL
      does not necessarily perform any per-session or inter-session
      queueing.  Any queueing of transmissions is the obligation of the

nit: comma splice.

  Transmission Failure:  The TCPCL supports positive indication of
      certain reasons for bundle transmission failure, notably when the
      peer entity rejects the bundle or when a TCPCL session ends before
      transfer success.  The TCPCL itself does not have a notion of
      transfer timeout.

I'm sure there is a subtle distinction here between a "TCPCL notion of
transfer timeout" and the underlying TCP connection timing out on
retransmissions, but I'm not sure what it is, yet.

Section 3.2

  negotiate the use of TLS security (as described in Section 4).  Once
  contact negotiation is complete, TCPCL messaging is available and the
  session negotiation is used to set parameters of the TCPCL session.
  One of these parameters is a Node ID of each TCPCL Entity.  This is
  used to assist in routing and forwarding messages by the BP Agent and
  is part of the authentication capability provided by TLS.

I might phrase this as "the Node ID that each TCPCL Entity is acting
as".

  Once negotiated, the parameters of a TCPCL session cannot change and
  if there is a desire by either peer to transfer data under different
  parameters then a new session must be established.  This makes CL
  logic simpler but relies on the assumption that establishing a TCP
  connection is lightweight enough that TCP connection overhead is
  negligable compared to TCPCL data sizes.

(I assume this assumption holds true ~universally for DTN TCPCL
consumers?)

  There is no fundamental limit on the number of TCPCL sessions which a
  single node can establish beyond the limit imposed by the number of
  available (ephemeral) TCP ports of the passive entity.

"epehemeral TCP ports" on the passive entity seems like a typo, as
Section 4.1 suggests that the passive entity usually uses the assigned
port 4556 and the source port on the active entity is an ephemeral one.

  Section 4.3).  Regardless of the reason, session termination is
  initiated by one of the entities and responded-to by the other as
  illustrated by Figure 13 and Figure 14.  Even when there are no
  transfers queued or in-progress, the session termination procedure
  allows each entity to distinguish between a clean end to a session
  and the TCP connection being closed because of some underlying
  network issue.

[This is also useful for TLS connections, as proper usage of
bidirectional "close_notify" alerts is far from universal.]

Section 3.3

It would probably be worth expanding "PCH" and "PSI" on first use rather
than last use.

  Contact negotiation involves exchanging a Contact Header (CH) in both
  directions and deriving a negotiated state from the two headers.  The
  contact negotiation sequencing is performed either as the active or
  passive entity, and is illustrated in Figure 5 and Figure 6
  respectively which both share the data validation and analyze final
  states of the "[PCH]" activity of Figure 7 and the "[TCPCLOSE]"
  activity which indicates TCP connection close.  Successful

I'm not sure what "analyze final states" is intended to mean.  (It shows
up again later, in discussion of Figure 10.)

Where does [PCH] occur in Figure 6?  (Should the "[PSI]" be changed to
"[PCH]"?)

Several of the figures have "negotiate " steps that do not have
possible paths for failure of negotiation; only Figure 4 seems to have a
disclaimer that it only shows the "nominal" case.

  Session termination involves one entity initiating the termination of
  the session and the other entity acknowledging the termination.  For
  either entity, it is the sending of the SESS_TERM message which
  transitions the session to the ending substate.  While a session is
  being terminated only in-progress transfers can be completed and no
  new transfers can be started.

Would it be more clear to say "is in the ending substate" than the
current "is being terminated"?

Section 3.4

  Each TCPCL session allows a negotiated transfer segmentation polcy to

nit: "policy"

  be applied in each transfer direction.  A receiving node can set the
  Segment MRU in its contact header to determine the largest acceptable

nit: this is in SESS_INIT now, not the contact header.

  attempt, and it SHOULD use a (binary) exponential back-off mechanism

Thank you for specifying the base of the exponent!

Section 4.1

  established, the entity SHALL close the TCP connection.  The ordering
  of the contact header exchange allows the passive entity to avoid
  allocating resources to a potential TCPCL session until after a valid
  contact header has been received from the passive entity.  This

I'm pretty sure that the passive entity is not going to get a contact
header from itself.

Section 4.2

It might be worth discussing the invariants of the contact
header/protocol, akin to https://tools.ietf.org/html/rfc8446#section-9.3
(though presumably less complicated!), since we are changing how things
work between TCPCLv3 and TCPCLv4.

  If an entity is capable of exchanging messages according to TLS 1.2
  [RFC5246] or any successors [RFC8446] that are compatible with TLS
  1.2, the CAN_TLS flag within its contanct header SHALL be set to 1.
  This behavor prefers the use of TLS when possible, even if security
  policy does not allow or require authentication.  This follows the
  opportunistic security model of [RFC7435].

When possible and there is not an active attack, which is an important
difference!

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.

Is this on the same TCP connection or successive new ones?  (The next
paragraph implies the same one, but it would be good to be explicit
about this.)

Section 4.4

  session to non-TLS operation.  If this is desired, the entire TCPCL
  session MUST be terminated and a new non-TLS-negotiated session
  established.

Absent some reason why this might be desired, I don't think we need to
have this last sentence.

  Once established, the lifetime of a TLS session SHALL be bound to the
  lifetime of the underlying TCP connection.  Immediately prior to

As the secdir reviewer notes, "TLS session" is an existing term of art
for TLS-related state that can be persisted across underlying TCP
connections by means of "resumption".  Given my current understanding of
TCPCL (possibly flawed), I suggest avoiding the phrase and sticking with
the current TCPCL session semantics that are bound to the TCP
connection.

  actively ending a TLS session after TCPCL session termination, the
  peer which sent the original (non-reply) SESS_TERM message SHOULD
  follow the Closure Alert procedure of [RFC5246] to cleanly terminate
  the TLS session.  Because each TCPCL message is either fixed-length

RFC 8446 is the current reference
(https://tools.ietf.org/html/rfc8446#section-6.1).

Section 4.4.1

  session entities SHALL begin a TLS handshake in accordance with TLS
  1.2 [RFC5246] or any successors that are compatible with TLS 1.2.  By

I think we can just say "begin a TLS handshake", citing RFC 8446, drop
the "in accordance with..." text, and say that version 1.2 or higher
MUST be negotiated.

  convention, this protocol uses the node which initiated the
  underlying TCP connection as the "client" role of the TLS handshake
  request.

That is to say, the "active" endpoint is the TLS client?

  Server Certificate:  The passive entity SHALL supply a certificate
      within the TLS handshake to allow authentication of its side of
      the session.  When assigned a stable host name or address, the
      passive entity certificate SHOULD contain a subjectAltName entry
      which authenticates that host name or address.  The passive entity

The current best practice is to reference RFC 6125 and talk about the
"DNS-ID" of the certificate.

      certificate SHOULD contain a subjectAltName entry of type
      uniformResourceIdentifier which authenticates the Node ID of the

Is this "SHOULD" a "MUST (unless using opportunistic TLS)"?  I might
suggest a different phrasing if so.

      peer.  The passive entity MAY use the SNI host name to choose an
      appropriate server-side certificate which authenticates that host
      name and corresponding Node ID.

I'm not sure on how often there will be a unique "corresponding Node ID"
for a given hostname.  This seems like a new requirement that might be
worth documenting in a management considerations section.

  Client Certificate:  The active entity SHALL supply a certificate

[ditto about RFC 6125, even though technically it only claims to apply
to server certificates -- since the situation here is symmetric, I think
it's okay to reuse the terminology.]

  All certificates supplied during TLS handshake SHALL conform with the
  profile of [RFC5280], or any updates or successors to that profile.

nit: "profile of [RFC5280]" sounds like it's RFC 5280 that's being
profiled, not that RFC 5280 is itself a profile of X.509.  So, I'd say
either just "conform with [RFC5280]" or "confirm with the X.509 profile
of [RFC5280]".  (Well, I'd probably s/conform with/conform to/, too...)

  When a certificate is supplied during TLS handshake, the full
  certification chain SHOULD be included unless security policy
  indicates that is unnecessary.

Is this intended to say that the root (trust anchor) certificate should
also be sent, even when the peer is assumed to already have a copy?
(This is not typical in TLS usage in other scenarios.)

  If a TLS handshake cannot negotiate a TLS session, both entities of
  the TCPCL session SHALL close the TCP connection.  At this point the
  TCPCL session has not yet been established so there is no TCPCL
  session to terminate.  This also avoids any potential security issues
  assoicated with further TCP communication with an untrusted peer.

I'm not entirely sure what's intended by "potential security issues"
here -- how is this different from any other TCP connection not using
TLS?

Section 4.4.2

The procedure that we describe here has a fairly convoluted description
and may be a little hard to follow (roughly, it seems to be "try really
hard to validate Node ID, and try somewhat less hard to validate
hostname/IP, but if you can do the former but not the latter it's still
okay").  It might be worth restructuring to have something of a
prioritized list/procedure, along the lines of "attempt to validate the
Node ID; if that succeeds, you're done and all is good.  If all fields
for validation is present but validation still fails, abort.  Otherwise
(not all fields for Node-ID validation are present), if policy allows,
validate the hostname (possibly limited to some set known from
out-of-band information to be "trusted" to a higher extent than just
having a certificate might indicate).  Fallback to opportunistic TLS can
be allowed by local policy."

  Using X.509 certificates exchanged during the TLS handshake, each of
  the entities can attempt to authenticate its peer at the network
  layer (host name and address) and at the application layer (BP Node
  ID).  The Node ID exchanged in the Session Initialization is likely

I think it's perhaps subjective or controversial to say that the network
address is authenticated by the X.509 validation process (barring
iPAddress certificates) and would suggest just using "host name" if
there is no specific reason to also list address.

  By using the SNI host name (see Section 4.4.1) a single passive
  entity can act as a convergence layer for multiple BP agents with
  distinct Node IDs.  When this "virtual host" behavior is used, the
  host name is used as the indication of which BP Node the passive
  entity is attempting to communicate with.  A virtual host CL entity

nit: either "communicate as" or "active entity is attempting".

  entity is attempting to communicate with.  A virtual host CL entity
  can be authenticated by a certificate containing all of the host
  names and/or Node IDs being hosted or by several certificates each
  authenticating a single host name and/or Node ID.

I suggest to append ", using the SNI value from the client to select
which certificate to use".

  of the TCP connection.  The passive entity SHALL attempt to
  authenticate the IP address of the other side of the TCP connection.
  The passive entity MAY use the IP address to resolve one or more host
  names of the active entity and attempt to authenticate those.  If

Er, is this saying that we basically expect everyone to have IP-address
certificates?
Also, using reverse DNS like this is pretty risky security posture in
the absence of DNSSEC on the reverse zone.

I might note in the caption for Figure 17 that the closure procedures
can be initiated by either entity.

Section 4.5

  | SESS_TERM    | 0x05 |              Indicates that one of the      |
  |              |      | entities participating in the session      |
  |              |      | wishes to cleanly terminate the session, as |
  |              |      | described in            Section 6.        |

Is section 6.1 a better reference?

Section 4.6

  Keepalive Interval:  A 16-bit unsigned integer indicating the
      interval, in seconds, between any subsequent messages being
      transmitted by the peer.  The peer receiving this contact header
      uses this interval to determine how long to wait after any last-
      message transmission and a necessary subsequent KEEPALIVE message
      transmission.

It might be worth giving more clarity as to whether this is an
indication of "this is what I will do" vs. "this is what you should do
when talking to me".

  Node ID Length and Node ID Data:  Together these fields represent a
      [...]
      message.  Every Node ID SHALL be a URI consistent with the
      requirements of [RFC3986] and the URI schemes of
      [I-D.ietf-dtn-bpbis].  The Node ID itself can be authenticated as

It may be better to refer to the "Bundle Protocol URI scheme types"
registry established by bpbis than the hardcoded list of URI schemes
contained within bpbis.

Section 4.7

  An entity calculates the parameters for a TCPCL session by
  negotiating the values from its own preferences (conveyed by the
  contact header it sent to the peer) with the preferences of the peer
  node (expressed in the contact header that it received from the
  peer).  The negotiated parameters defined by this specification are

Aren't these from the SESS_INIT message rather than the contact header?

  Session Keepalive:  Negotiation of the Session Keepalive parameter is
      performed by taking the minimum of this two contact headers'
      Keepalive Interval.  The Session Keepalive interval is a parameter
      for the behavior described in Section 5.1.1.  If the Session
      Keepalive interval is unacceptable, the node SHALL terminate the
      session with a reason code of "Contact Failure".

It's probably worth mentioning that a value of zero means "keepalives
are disabled".  The procedure given here does seem consistent with the
discussion in Section 5.1.1 that indicates that either peer can
unilaterally disable keepalives (as opposed to the behavior one might
naively expect by having the encoded value zero reflect an effective
interval of "infinity").

Section 4.8

  Item Type:  A 16-bit unsigned integer field containing the type of
      the extension item.  This specification does not define any
      extension types directly, but does allocate an IANA registry for
      such codes (see Section 9.3).

nit: I think we typically say that we "allocate" codepoints from
registries but "create" registries themselves.

  choose a keepalive interval no shorter than 30 seconds.  There is no
  logical maximum value for the keepalive interval, but an idle TCP

It's a fixed-width field; there's a maximum.

  Note: The Keepalive Interval SHOULD NOT be chosen too short as TCP
  retransmissions MAY occur in case of packet loss.  Those will have to
  be triggered by a timeout (TCP retransmission timeout (RTO)), which
  is dependent on the measured RTT for the TCP connection so that
  KEEPALIVE messages MAY experience noticeable latency.

nit: s/MAY/may/; this statement is describing a property of TCP and not
granting implementations permission to engage in a particular behavior.

Section 5.2.1

  Each transfer entails the sending of a sequence of some number of
  XFER_SEGMENT and XFER_ACK messages; all are correlated by the same
  Transfer ID.

  Transfer IDs from each node SHALL be unique within a single TCPCL
  session.  The initial Transfer ID from each node SHALL have value
  zero.  Subsequent Transfer ID values SHALL be incremented from the
  prior Transfer ID value by one.  Upon exhaustion of the entire 64-bit
  Transfer ID space, the sending node SHALL terminate the session with
  SESS_TERM reason code "Resource Exhaustion".

I'd suggest adding some discussion that the sender of the XFER_SEGMENTs
allocates the Transfer ID and the XFER_ACKs respond to it; the current
text is potentially confusing since the ID in an XFER_ACK could be
considered to be a "transfer ID from [each] node" but is really in the
peer node's namespace.

Also, it's not entirely clear that there's a need for predictable IDs
starting from zero;
https://tools.ietf.org/html/draft-gont-numeric-ids-sec-considerations-04
has some further discussion about potential pitfalls of such predictable
identifiers.

Section 5.2.2

  The flags portion of the message contains two optional values in the
  two low-order bits, denoted 'START' and 'END' in Table 5.  The

I'm always a little wary of using "optional" for situations like these,
since "optional" can imply that they appear subject to the whims of the
implementation/higher-layer, but when they do/don't appear here is
actually tightly constrained by the protocol specification.  Perhaps
it's better to talk of information being conveyed by the value of these
bits than them containing optional values.

Section 5.2.3

  A receiving TCPCL node SHALL send an XFER_ACK message in response to
  each received XFER_SEGMENT message.  The flags portion of the
  XFER_ACK header SHALL be set to match the corresponding DATA_SEGMENT
  message being acknowledged.  The acknowledged length of each XFER_ACK

I don't think there is a DATA_SEGMENT (vs. XFER_SEGMENT) message
defined.

Also, is the receiver expected to echo flags from the XFER_SEGMENT that
it does not comprehend?

Section 5.2.4

  | Extension  | 0x01 | A failure processing the Transfer Extension  |
  | Failure    |      | Items ha occurred.                            |

nit: "has"

  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.  The beginning of the next bundle is identified by

nit: I think "might not" is more appropriate here, as this is describing
expectations and not some active choice the receiver can make.

Section 5.2.5.1

  Total Length:  A 64-bit unsigned integer indicating the size of the
      data-to-be-transferred.  The Total Length field SHALL be treated
      as authoritative by the receiver.  If, for whatever reason, the
      actual total length of bundle data received differs from the value
      indicated by the Total Length value, the receiver SHALL treat the
      transmitted data as invalid.

It seems like this might be setting things up for information skew
between endpoints, where the receiver has discarded a bundle but the
sender thinks it was successfully transmitted.  Would it make sense to
require an XFER_REFUSE in such a case?

Section 6.1

  Instead of following a clean shutdown sequence, after transmitting a
  SESS_TERM message an entity MAY immediately close the associated TCP
  connection.  When performing an unclean shutdown, a receiving node
  SHOULD acknowledge all received data segments before closing the TCP
  connection.  Not acknowledging received segments can result in
  unnecessary retransmission.  When performing an unclean shutodwn, a

I'm not sure I understand the nature of this indicated "unnecessary
retransmission".  My first thought was that there would be a way to
reestablish a new session between the same endpoints and reuse the
Transaction ID to "start in the middle" of the bundle, but I don't see
any mechanisms designed to allow that or to assign semantics to
transaction IDs across sessions.  So the only thing I can come up with
would be ordinary TCP-layer retransmissions, but those are within the
TCP stack's abstraction boundary, so I'm not sure if it makes sense to
talk about them.

  | Contact      | 0x04 | The node cannot interpret or negotiate      |
  | Failure      |      | contact header option.                      |

nit: I think there's a singular/plural mismatch here.

  connection without sending a SESS_TERM message.  If the content of
  the Session Extension Items data disagrees with the Session Extension
  Length (i.e. the last Item claims to use more octets than are present
  in the Session Extension Length), the reception of the contact header
  is considered to have failed.

nit: is it reception of the contact header or the SESS_INIT that is to
have failed?

Section 8

Thanks for the throrough security considerations; I really appreciate
the work that went into the discussion with the secdir reviewer.

Section 8.2

I think this text implies that a malicious or compromised node can view
bundle contents (which to some extent is a consideration for the core
bundle protocol and not the convergence layer anyway), so it's probably
okay to leave it as-is.

Section 8.3

I suggest noting that an active on-path attacker can also cause use of
an older/different TCPCL version.

  of TCPCL which does not support transport security.  It is up to
  security policies within each TCPCL node to ensure that the TCPCL
  version in use meets transport security requirements.

I'm not sure whether it's worth noting this in the document, but a
consequence of this is that if the security policy allows more than one
TCPCL version, the on-path attacker has control over which of those
versions gets used, even if that protocol itself nominally operats in a
secure fashion.

Section 8.4

  The purpose of the CAN_TLS flag is to allow the use of TCPCL on
  entities which simply do not have a TLS implementation available.
  When TLS is available on an entity, it is strongly encouraged that
  the security policy disallow non-TLS sessions.  This requires that

Is it only "strongly encouraged" or a "SHALL-level requirement" (per
Section 4.2)?

Section 8.6

  or using it after it has been revoked by its CA.  Validating a
  certificate is a complex task and may require network connectivity if
  a mechanism such as the Online Certificate Status Protocol (OCSP) is
  used by the CA.  The configuration and use of particular certificate

nit: I suggest "external network connectivity"; some level of network
connectivity has to be present in order for TCPCL to be used at all...

Section 8.7

  When permitted by the negotiated TLS version (see [RFC8446]), it is
  advisable to take advantage of session key updates to avoid those
  limits.  When key updates are not possible, establishing new TCPCL/
  TLS session is an alternative to limit session key use.

This is not necessarily a question that needs to be answered in the RFC,
but do you consider TLS 1.2 renegotiation to be a "session key update
mechanism"?

Section 8.8

  certificates can be guaranteed to validate the peer's Node ID.  In
  circumstances where certificates can only be issued to network host
  names, Node ID validation is not possible but it could be reasonable
  to assume that a trusted host is not going to present an invalid Node
  ID.

I think we should also say that determination of whether a given host is
trusted in this fashion is out of scope for this document (since it's a
very important consideration but we cannot give universal guidance on
it).

Section 8.9

TCP RST injection is also a DoS vector (potentially from off-path), as
boring as it is...

Section 8.10


  This specification makes use of public key infrastructure (PKI)
  certificate validation and authentication within TLS.  There are
  alternate uses of TLS which are not necessarily incompatible with the
  security goals of this specification, but are outside of the scope of
  this document.

There are other PKIs than X.509 PKIs, so I'd suggest "X.509 public key
infrastructure".

Also, I think it would be reasonable to give some examples of other
modes of using TLS ("e.g., non-X.509 certificates or raw public keys")
if you want.

Section 9

Should we make registries for the various flag words (vs. requiring an
RFC updating this one in order to allocate new values)?

Section 9.1

The IESG should perhaps talk (again) about updating the port
registration made by an IRTF-stream document.

Section 11.2

One could perhaps argue that [AEAD-LIMITS] is more properly normative,
but I don't feel very strongly about it.

[Ballot comment]
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.

[Ballot comment]
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

[Ballot comment]
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".

[Ballot comment]
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.

[Ballot discuss]

* Section 4.2:

" TLS 1.2 [RFC5246] or any successors [RFC8446] that are compatible with TLS 1.2"

Hopefully this is easy to resolve but I am not sure what exactly you intended to say with this phrase "that are compatible with TLS 1.2". Can you please expand and clarify? (I think going through Appendix D of RFC8446 may bring up specific things you might be looking for). A similar construct is also used in Section 4.4.1.

[Ballot discuss]

* Section 4.2:

" TLS 1.2 [RFC5246] or any successors [RFC8446] that are compatible with TLS 1.2"

Hopefully this is easy to resolve but I am not sure what exactly you intended to say with this phrase "that are compatible with TLS 1.2". Can you please clarify? (I think going through Appendix D of RFC8446 may bring up specific things you might be looking for). A similar construct is also used in Section 4.4.1.

[Ballot comment]
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.

(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Functions Operator has completed its review of draft-ietf-dtn-tcpclv4-15. If any part of this review is inaccurate, please let us know.

The IANA Functions Operator has a question about one of the actions requested in the IANA Considerations section of this document.

The IANA Functions Operator understands that, upon approval of this document, there are eight actions which we must complete.

First, IANA understands that port 4556 will continue to be used for TCPCL version 4.

IANA Question --> the reference for port 4556 for TCP, UDP, and DCCP is [RFC7242]. Should [ RFC-to-be ] be added to the reference for port 4556 in the port and service name registry?

Second, in the Bundle Protocol TCP Convergence-Layer Version Numbers registry on the Bundle Protocol registry page located at:

https://www.iana.org/assignments/bundle/

a single value will be added to the registry as follows:

Value: 4
Description: TCPCLv4
Reference: [ RFC-to-be ]

Third, a new registry is to be created called the Bundle Protocol TCP Convergence-Layer Version 4 Session Extension Types. The new registry will be created n the Bundle Protocol registry page located at:

https://www.iana.org/assignments/bundle/

Values will range between 0x0000 and 0xFFFF. For values between 0x001 and 0x7FFF the registry bill be managed via Expert Review as defined in RFC 8126. Values in the range 0x8000 and 0xFFFF are reserved for Private Use as defined in RFC 8126.

There are no initial registrations in the new registry. The initial registry is:

+----------------+--------------------------+
| Code | Session Extension Type |
+----------------+--------------------------+
| 0x0000 | Reserved |
| 0x0001--0x7FFF | Unassigned |
| 0x8000--0xFFFF | Private/Experimental Use |
+----------------+--------------------------+

Fourth, a new registry is to be created called the Bundle Protocol TCP Convergence-Layer Version 4 Transfer Extension Types. The new registry will be created on the Bundle Protocol registry page located at:

https://www.iana.org/assignments/bundle/

Values will range between 0x0000 and 0xFFFF. For values between 0x001 and 0x7FFF the registry bill be managed via Expert Review as defined in RFC 8126. Values in the range 0x8000 and 0xFFFF are reserved for Private Use as defined in RFC 8126.

There are initial registrations in the new registry as follows:

+----------------+---------------------------+---------------+
| Code | Transfer Extension Type | Reference |
+----------------+---------------------------+---------------+
| 0x0000 | Reserved | [ RFC-to-be ] |
| 0x0001 | Transfer Length Extension | [ RFC-to-be ] |
| 0x0002--0x7FFF | Unassigned | |
| 0x8000--0xFFFF | Private/Experimental Use | |
+----------------+---------------------------+---------------+

Fifth, a new registry is to be created called the Bundle Protocol TCP Convergence-Layer Version 4 Message Types. The new registry will be created on the Bundle Protocol registry page located at:

https://www.iana.org/assignments/bundle/

Values will range between 0x00 and 0xFF. Values between 0x01 and 0xEF are registered via RFC Required as defined in RFC 8126. Values in the range 0xF0 and 0xFF are reserved for private use as defined in RFC 8126.

There are initial registrations in the new registry as follows:

+------------+--------------------------+---------------+
| Code | Message Type | Reference |
+------------+--------------------------+---------------+
| 0x00 | Reserved | [ RFC-to-be ] |
| 0x01 | XFER_SEGMENT | [ RFC-to-be ] |
| 0x02 | XFER_ACK | [ RFC-to-be ] |
| 0x03 | XFER_REFUSE | [ RFC-to-be ] |
| 0x04 | KEEPALIVE | [ RFC-to-be ] |
| 0x05 | SESS_TERM | [ RFC-to-be ] |
| 0x06 | MSG_REJECT | [ RFC-to-be ] |
| 0x07 | SESS_INIT | [ RFC-to-be ] |
| 0x08--0xEF | Unassigned | |
| 0xF0--0xFF | Private/Experimental Use | |
+------------+--------------------------+---------------+

Sixth, a new registry is to be created called the Bundle Protocol TCP Convergence-Layer Version 4 XFER_REFUSE Reason Codes. The new registry will be created on the Bundle Protocol registry page located at:

https://www.iana.org/assignments/bundle/

Values will range between 0x00 and 0xFF. Values between 0x00 and 0xEF are registered via RFC Required as defined in RFC 8126. Values in the range 0xF0 and 0xFF are reserved for private use as defined in RFC 8126.

There are initial registrations in the new registry as follows:

+------------+--------------------------+---------------+
| Code | Refusal Reason | Reference |
+------------+--------------------------+---------------+
| 0x00 | Unknown | [ RFC-to-be ] |
| 0x01 | Extension Failure | [ RFC-to-be ] |
| 0x02 | Completed | [ RFC-to-be ] |
| 0x03 | No Resources | [ RFC-to-be ] |
| 0x04 | Retransmit | [ RFC-to-be ] |
| 0x05--0xEF | Unassigned | |
| 0xF0--0xFF | Private/Experimental Use | |
+------------+--------------------------+---------------+

Seventh, a new registry is to be created called the Bundle Protocol TCP Convergence-Layer Version 4 SESS_TERM Reason Codes. The new registry will be created on the Bundle Protocol registry page located at:

https://www.iana.org/assignments/bundle/

Values will range between 0x00 and 0xFF. Values between 0x00 and 0xEF are registered via RFC Required as defined in RFC 8126. Values in the range 0xF0 and 0xFF are reserved for private use as defined in RFC 8126.

There are initial registrations in the new registry as follows:

+------------+--------------------------+---------------+
| Code | Termination Reason | Reference |
+------------+--------------------------+---------------+
| 0x00 | Unknown | [ RFC-to-be ] |
| 0x01 | Idle timeout | [ RFC-to-be ] |
| 0x02 | Version mismatch | [ RFC-to-be ] |
| 0x03 | Busy | [ RFC-to-be ] |
| 0x04 | Contact Failure | [ RFC-to-be ] |
| 0x05 | Resource Exhaustion | [ RFC-to-be ] |
| 0x06--0xEF | Unassigned | |
| 0xF0--0xFF | Private/Experimental Use | |
+------------+--------------------------+---------------+

Eighth, a new registry is to be created called the Bundle Protocol TCP Convergence-Layer Version 4 MSG_REJECT Reason Code. The new registry will be created on the Bundle Protocol registry page located at:

https://www.iana.org/assignments/bundle/

Values will range between 0x00 and 0xFF. Values between 0x00 and 0xEF are registered via RFC Required as defined in RFC 8126. Values in the range 0xF0 and 0xFF are reserved for private use as defined in RFC 8126.

There are initial registrations in the new registry as follows:

+------------+--------------------------+---------------+
| Code | Rejection Reason | Reference |
+------------+--------------------------+---------------+
| 0x00 | reserved | |
| 0x01 | Message Type Unknown | [ RFC-to-be ] |
| 0x02 | Message Unsupported | [ RFC-to-be ] |
| 0x03 | Message Unexpected | [ RFC-to-be ] |
| 0x04--0xEF | Unassigned | |
| 0xF0--0xFF | Private/Experimental Use | |
+------------+--------------------------+---------------+

The IANA Functions Operator understands that these are the only actions required to be completed upon approval of this document.

Note:  The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is meant only to confirm the list of actions that will be performed.

Thank you,

Sabrina Tanamal
Senior IANA Services Specialist

The following Last Call announcement was sent out (ends 2019-11-06):

From: The IESG
To: IETF-Announce
CC: magnus.westerlund@ericsson.com, dtn-chairs@ietf.org, edward.birrane@jhuapl.edu, Edward Birrane , draft-ietf-dtn-tcpclv4@ietf.org, dtn@ietf.org
Reply-To: last-call@ietf.org
Sender:
Subject: Last Call:  (Delay-Tolerant Networking TCP Convergence Layer Protocol Version 4) to Proposed Standard


The IESG has received a request from the Delay/Disruption Tolerant Networking
WG (dtn) to consider the following document: - 'Delay-Tolerant Networking TCP
Convergence Layer Protocol Version 4'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
last-call@ietf.org mailing lists by 2019-11-06. Exceptionally, comments may
be sent to iesg@ietf.org instead. In either case, please retain the beginning
of the Subject line to allow automated sorting.

Abstract


  This document describes a revised protocol for the TCP-based
  convergence layer (TCPCL) for Delay-Tolerant Networking (DTN).  The
  protocol revision is based on implementation issues in the original
  TCPCL Version 3 of RFC7242 and updates to the Bundle Protocol
  contents, encodings, and convergence layer requirements in Bundle
  Protocol Version 7.  Specifically, the TCPCLv4 uses CBOR-encoded BPv7
  bundles as its service data unit being transported and provides a
  reliable transport of such bundles.  Several new IANA registries are
  defined for TCPCLv4 which define some behaviors inherited from
  TCPCLv3 but with updated encodings and/or semantics.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-dtn-tcpclv4/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-dtn-tcpclv4/ballot/


No IPR declarations have been submitted directly on this I-D.

Document Shepherd Write-Up for Delay-Tolerant Networking TCP Convergence
Layer Protocol Version 4

Ed Birrane
19 June 2019

(1) What type of RFC is being requested? Why is this the proper type of RFC?
    Is this type of RFC indicated in the title page header?

A Proposed Standard is being requested.  This is the appropriate type of RFC
because the specification documented in the current Internet Draft describes
a protocol that is being implemented and used on the Internet. The title page
header indicates that the intended status is Standards Track.


(2) The IESG approval announcement includes a Document Announcement Write-Up.   
    Please provide such a Document Announcement Write-Up.

DOCUMENT ANNOUNCEMENT
-------------------------------------------------------------------------------

Document Announcement Write-Up for Delay-Tolerant Networking TCP Convergence
Layer Protocol Version 4

Ed Birrane
18 June 2019

Technical Summary:

This document describes the Delay-Tolerant Networking TCP Convergence Layer
Protocol Version 4 (TCPCLv4) for use with the Bundle Protocol Version 7 (BPv7)
[I-D.ietf-dtn-bpbis].

The BPv7 implements a store-and-forward overlay network suitable for
delay-tolerant message exchange. The protocol data unit for the BPv7 is the
"bundle". BPv7 agents require convergence layer adapters (CLAs) to send and
receive "bundles" using the service of some "native" link, network, or
Internet protocol. Both the BPv7 and its CLAs reside at the application layer
of the Internet model protocol stack [RFC1122].

The TCPCLv4 describes a CLA that sends and received bundles using the well-known
Transmission Control Protocol (TCP). This specification describes the format and
processing of the protocol data units passed between entities participating in
TCPCLv4 communications. 


Working Group Summary:

TCPCLv4 is descended from an experimental IRTF specification TCPCLv3 [RFC7242].
Implementation experience with TCPCLv3 identified limitations such as ambiguity
in bundle acknowledgment and refusal, non-normative discussion on how to
incorporate TLS, and minor inefficiencies associated with sequencing. TCPCLv4
was created to address those limitations and prepare the specification for
non-experimental use. Technical discussions over the last 3 years have been
well informed and focused on TLS negotiations, overall protocol agent state
machines, and a protocol extension mechanism. There is no controversy related
to the adoption of the specification; DTNWG consensus on the draft is strong.

Document Quality:

The workflow for TCPCLv4 remained largely unchanged from that of TCPCLv3 for
which reference implementations exist. Co-author B. Sipos has created a
reference implementation of TCPCLv4 to demonstrate features and ensure the
clarity of the draft. Much of the recent review provided by the DTNWG focused
on increasing the overall clarity of the specification to ensure no ambiguities
exist for implementers. There have been no problems discovered with the
reference implementation for this draft.

Personnel:

The Document Shepherd is Ed Birrane.

The Responsible Area Director is Magnus Westerlund.

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



(3) Briefly describe the review of this document that was performed by the
    Document Shepherd.

The Document Shepherd has been reviewing and commenting on drafts of this
specification since March of 2017 (IETF 98).  The current edition of the
specification is considered ready for publication.



(4) Does the document Shepherd have any concerns about the depth or breadth of
    the reviews that have been performed?

No. Reviews have been performed by persons with a good understanding of the
Bundle Protocol and the concept of convergence layer adapters. Original authors
of the TCPCLv3 also reviewed and refined this specification, as have
implementers in the context of a reference implementation.



(5) Do portions of the document need review from a particular or from broader
    perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML,
    or internationalization? If so, describe the review that took place.

The Document Shepherd does not perceive any need for review from additional
perspectives. The DTNWG reviews have covered Bundle Protocol concepts, and the
use of TCP and TLS in this specification follows established norms.



(6) Describe any specific concerns or issues that the Document Shepherd has
    with this document that the Responsible Area Director and/or the IESG should
    be aware of.

The Document Shepherd has no specific concerns or issues with this document. 
Technical questions have been discussed at length and resolved by consensus
within the WG. Much of the recent discussion in the WG has focused on ensuring
that concepts are clear and this current revision of the specification has
accomplished that clarity.



(7) Has each author confirmed that any and all appropriate IPR disclosures
    required for full conformance with the provisions of BCP 78 and BCP 79 have
    already been filed. If not, explain why?

All authors have indicated no known IPR disclosures for this work.



(8) Has an IPR disclosure been filed that references this document? If so,
    summarize any WG discussion and conclusion regarding the IPR disclosures.

There is no known IPR disclosure that directly references this document.
However, the DTNWG mailing list indicated the existence of a patent
(USPTO #7,930,379)that may or may not have applicability to DTN systems in
general. This was brought to the attention of the DTNWG, DTNWG chairs, and
responsible AD.

The responsible AD has responded that unless additional IPR disclosures are
provided this document can progress.


(9) How solid is the WG consensus behind this document? Does it represent the
    strong concurrence of a few individuals, with others being silent, or does
    the WG as a whole understand and agree with it?

This document appears to the Document Shepherd to represent the solid consensus
of the WG. There have been no dissenting opinions relating to its most recent
specifications in the WG itself or on the WG mailing list. Several WG members
have experience with the preexisting TCPCLv3 that this specification replaces,
with using Bundle Protocol, and with the concept and use of convergence layer
adapters. The WG as a whole understands the intent, capabilities, design, and
approach presenting in this specification.



(10) Has anyone threatened an appeal or otherwise indicated extreme discontent?

No threatened appeal or extreme discontent has been evident in the WG meetings
or on the mailing list.



(11) Identify any ID nits the Document Shepherd has found in this document.

There are some nits in the document, but nothing serious and nothing than
cannot be easily remedied.

According to ID Nits check:

1 ERROR:

  1) Obsolete normative reference: RFC 5246 has been obsoleted by RFC 8446.

8 WARNINGS:

  1-6) Warnings identify a "missing reference" for items that are not meant to
      be references. These warning are considered false positives and refer to
      labels used in examples and illustrations.

  7) Warning for out of date reference to bpbis. The specification refers to
    draft-ietf-dtn-bpbis-12 and should refer to draft-ietf-dtn-bpbis-13. 

  8) Warning for out of date reference to bpsec. The specification refers to
    draft-ietf-dtn-bpsec-09 and should refer to draft-ietf-dtn-bpsec-10. 

2 COMMENTS:

  1) The draft header indicates this specification obsoletes RFC7242 (IRTF
    experimental specification of TCPClv3) but the abstract does not directly
    say this. The absence of Updates or Supersedes language in the Abstract
    seems appropriate because the superseded document was experimental.

  2) The document date (March 31, 2019) is 80 days in the past. This date
    references the publication date of the current version of the specification.

According to the Internet-Draft Checklist:

  Checklist 2.2.10: Verbatim replication of the IPR Disclosure is not provided.

  Checklist 2.2.11: Verbatim replication of the IPR Notice, and Copyright Notice
                    and Disclosure are not provided. 

  Checklist 3.8: The specification includes a section 7 "Implementation status"
                which details the TCPCLv4 reference implementation. This
                section should be removed prior to publication.

  Checklist 3.7.A: The specification includes an informative reference to a
                  GitHub link hosting the reference implementation. This
                  reference should be removed at the same time Section 7
                  "Implementation Status" is removed.



(12) Describe how the document meets any required formal review criteria, such
    as the MIB Doctor, media type, and URI type reviews.

No formal review criteria are known to be applicable.



(13) Have all references within this document been identified as either
    normative or informative?

Yes, with one error (detected by ID nits) as noted in section 11.



(14) Are there normative references to documents that are not ready for
    advancement or are otherwise in an unclear state? If such normative
    references exist, what is the plan for their completion?

The Internet-Draft for Bundle Protocol Version 7 (bpbis) is referenced as a
normative document.  The bpbis document is being forwarded to the IESG at the
same time as the TCPCLv4 document itself.



(15) Are there downward normative references (see RFC 3967)? If so, list these
    downward references to support the Area Director in the Last Call procedure.

There are no downward normative references, aside from the error (detected by
ID Nits) as noted in section 11.



(16) Will publication of this document change the status of any existing RFCs?

No.



(17) Describe the Document Shepherd's review of the IANA considerations section,
    especially with regard to its consistency with the body of the document.
    Confirm that all protocol extensions that the document makes are associated
    with the appropriate reservations in IANA registries. Confirm that any
    referenced IANA registries have been clearly identified. Confirm that newly
    created IANA registries include a detailed specification of the initial
    contents for the registry, that allocations procedures for future
    registrations are defined, and a reasonable name for the new registry has
    been suggested (see RFC 8126).

The IANA considerations section is consistent with the body of the document.
Referenced IANA registries are identified and new registries detailed to include
their initial contents. Registry names appear reasonable. Registration
procedures are provided.



(18) List any new IANA registries that require Expert Review for future
    allocations. Provide any public guidance that the IESG would find useful in
    selecting the IANA Experts for these new registries.

The session extension and transfer extension type sub-registries defined in this
specification would benefit from expert review for future allocations. Expert
review by people familiar with TCP and TLS would be useful to ensure that
extensions are not added that would impact the efficient operation of this
convergence layer adapter.



(19) Describe reviews and automated checks performed by the Document Shepherd
    to validate sections of the document written in a formal language, such as
    XML code, BNF rules, MIB definitions, etc.

No sections of the TCPCLv4 specification are written in any formal language.

Document Shepherd Write-Up for Delay-Tolerant Networking TCP Convergence
Layer Protocol Version 4

Ed Birrane
19 June 2019

(1) What type of RFC is being requested? Why is this the proper type of RFC?
    Is this type of RFC indicated in the title page header?

A Proposed Standard is being requested.  This is the appropriate type of RFC
because the specification documented in the current Internet Draft describes
a protocol that is being implemented and used on the Internet. The title page
header indicates that the intended status is Standards Track.


(2) The IESG approval announcement includes a Document Announcement Write-Up.   
    Please provide such a Document Announcement Write-Up.

DOCUMENT ANNOUNCEMENT
-------------------------------------------------------------------------------

Document Announcement Write-Up for Delay-Tolerant Networking TCP Convergence
Layer Protocol Version 4

Ed Birrane
18 June 2019

Technical Summary:

This document describes the Delay-Tolerant Networking TCP Convergence Layer
Protocol Version 4 (TCPCLv4) for use with the Bundle Protocol Version 7 (BPv7)
[I-D.ietf-dtn-bpbis].

The BPv7 implements a store-and-forward overlay network suitable for
delay-tolerant message exchange. The protocol data unit for the BPv7 is the
"bundle". BPv7 agents require convergence layer adapters (CLAs) to send and
receive "bundles" using the service of some "native" link, network, or
Internet protocol. Both the BPv7 and its CLAs reside at the application layer
of the Internet model protocol stack [RFC1122].

The TCPCLv4 describes a CLA that sends and received bundles using the well-known
Transmission Control Protocol (TCP). This specification describes the format and
processing of the protocol data units passed between entities participating in
TCPCLv4 communications. 


Working Group Summary:

TCPCLv4 is descended from an experimental IRTF specification TCPCLv3 [RFC7242].
Implementation experience with TCPCLv3 identified limitations such as ambiguity
in bundle acknowledgment and refusal, non-normative discussion on how to
incorporate TLS, and minor inefficiencies associated with sequencing. TCPCLv4
was created to address those limitations and prepare the specification for
non-experimental use. Technical discussions over the last 3 years have been
well informed and focused on TLS negotiations, overall protocol agent state
machines, and a protocol extension mechanism. There is no controversy related
to the adoption of the specification; DTNWG consensus on the draft is strong.

Document Quality:

The workflow for TCPCLv4 remained largely unchanged from that of TCPCLv3 for
which reference implementations exist. Co-author B. Sipos has created a
reference implementation of TCPCLv4 to demonstrate features and ensure the
clarity of the draft. Much of the recent review provided by the DTNWG focused
on increasing the overall clarity of the specification to ensure no ambiguities
exist for implementers. There have been no problems discovered with the
reference implementation for this draft.

Personnel:

The Document Shepherd is Ed Birrane.

The Responsible Area Director is Magnus Westerlund.

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



(3) Briefly describe the review of this document that was performed by the
    Document Shepherd.

The Document Shepherd has been reviewing and commenting on drafts of this
specification since March of 2017 (IETF 98).  The current edition of the
specification is considered ready for publication.



(4) Does the document Shepherd have any concerns about the depth or breadth of
    the reviews that have been performed?

No. Reviews have been performed by persons with a good understanding of the
Bundle Protocol and the concept of convergence layer adapters. Original authors
of the TCPCLv3 also reviewed and refined this specification, as have
implementers in the context of a reference implementation.



(5) Do portions of the document need review from a particular or from broader
    perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML,
    or internationalization? If so, describe the review that took place.

The Document Shepherd does not perceive any need for review from additional
perspectives. The DTNWG reviews have covered Bundle Protocol concepts, and the
use of TCP and TLS in this specification follows established norms.



(6) Describe any specific concerns or issues that the Document Shepherd has
    with this document that the Responsible Area Director and/or the IESG should
    be aware of.

The Document Shepherd has no specific concerns or issues with this document. 
Technical questions have been discussed at length and resolved by consensus
within the WG. Much of the recent discussion in the WG has focused on ensuring
that concepts are clear and this current revision of the specification has
accomplished that clarity.



(7) Has each author confirmed that any and all appropriate IPR disclosures
    required for full conformance with the provisions of BCP 78 and BCP 79 have
    already been filed. If not, explain why?

3 of 4 authors have indicated no known IPR disclosures for this work.



(8) Has an IPR disclosure been filed that references this document? If so,
    summarize any WG discussion and conclusion regarding the IPR disclosures.

There is no known IPR disclosure that directly references this document.
However, the DTNWG mailing list indicated the existence of a patent
(USPTO #7,930,379)that may or may not have applicability to DTN systems in
general. This was brought to the attention of the DTNWG, DTNWG chairs, and
responsible AD.



(9) How solid is the WG consensus behind this document? Does it represent the
    strong concurrence of a few individuals, with others being silent, or does
    the WG as a whole understand and agree with it?

This document appears to the Document Shepherd to represent the solid consensus
of the WG. There have been no dissenting opinions relating to its most recent
specifications in the WG itself or on the WG mailing list. Several WG members
have experience with the preexisting TCPCLv3 that this specification replaces,
with using Bundle Protocol, and with the concept and use of convergence layer
adapters. The WG as a whole understands the intent, capabilities, design, and
approach presenting in this specification.



(10) Has anyone threatened an appeal or otherwise indicated extreme discontent?

No threatened appeal or extreme discontent has been evident in the WG meetings
or on the mailing list.



(11) Identify any ID nits the Document Shepherd has found in this document.

There are some nits in the document, but nothing serious and nothing than
cannot be easily remedied.

According to ID Nits check:

1 ERROR:

  1) Obsolete normative reference: RFC 5246 has been obsoleted by RFC 8446.

8 WARNINGS:

  1-6) Warnings identify a "missing reference" for items that are not meant to
      be references. These warning are considered false positives and refer to
      labels used in examples and illustrations.

  7) Warning for out of date reference to bpbis. The specification refers to
    draft-ietf-dtn-bpbis-12 and should refer to draft-ietf-dtn-bpbis-13. 

  8) Warning for out of date reference to bpsec. The specification refers to
    draft-ietf-dtn-bpsec-09 and should refer to draft-ietf-dtn-bpsec-10. 

2 COMMENTS:

  1) The draft header indicates this specification obsoletes RFC7242 (IRTF
    experimental specification of TCPClv3) but the abstract does not directly
    say this. The absence of Updates or Supersedes language in the Abstract
    seems appropriate because the superseded document was experimental.

  2) The document date (March 31, 2019) is 80 days in the past. This date
    references the publication date of the current version of the specification.

According to the Internet-Draft Checklist:

  Checklist 2.2.10: Verbatim replication of the IPR Disclosure is not provided.

  Checklist 2.2.11: Verbatim replication of the IPR Notice, and Copyright Notice
                    and Disclosure are not provided. 

  Checklist 3.8: The specification includes a section 7 "Implementation status"
                which details the TCPCLv4 reference implementation. This
                section should be removed prior to publication.

  Checklist 3.7.A: The specification includes an informative reference to a
                  GitHub link hosting the reference implementation. This
                  reference should be removed at the same time Section 7
                  "Implementation Status" is removed.



(12) Describe how the document meets any required formal review criteria, such
    as the MIB Doctor, media type, and URI type reviews.

No formal review criteria are known to be applicable.



(13) Have all references within this document been identified as either
    normative or informative?

Yes, with one error (detected by ID nits) as noted in section 11.



(14) Are there normative references to documents that are not ready for
    advancement or are otherwise in an unclear state? If such normative
    references exist, what is the plan for their completion?

The Internet-Draft for Bundle Protocol Version 7 (bpbis) is referenced as a
normative document.  The bpbis document is being forwarded to the IESG at the
same time as the TCPCLv4 document itself.



(15) Are there downward normative references (see RFC 3967)? If so, list these
    downward references to support the Area Director in the Last Call procedure.

There are no downward normative references, aside from the error (detected by
ID Nits) as noted in section 11.



(16) Will publication of this document change the status of any existing RFCs?

No.



(17) Describe the Document Shepherd's review of the IANA considerations section,
    especially with regard to its consistency with the body of the document.
    Confirm that all protocol extensions that the document makes are associated
    with the appropriate reservations in IANA registries. Confirm that any
    referenced IANA registries have been clearly identified. Confirm that newly
    created IANA registries include a detailed specification of the initial
    contents for the registry, that allocations procedures for future
    registrations are defined, and a reasonable name for the new registry has
    been suggested (see RFC 8126).

The IANA considerations section is consistent with the body of the document.
Referenced IANA registries are identified and new registries detailed to include
their initial contents. Registry names appear reasonable. Registration
procedures are provided.



(18) List any new IANA registries that require Expert Review for future
    allocations. Provide any public guidance that the IESG would find useful in
    selecting the IANA Experts for these new registries.

The session extension and transfer extension type sub-registries defined in this
specification would benefit from expert review for future allocations. Expert
review by people familiar with TCP and TLS would be useful to ensure that
extensions are not added that would impact the efficient operation of this
convergence layer adapter.



(19) Describe reviews and automated checks performed by the Document Shepherd
    to validate sections of the document written in a formal language, such as
    XML code, BNF rules, MIB definitions, etc.

No sections of the TCPCLv4 specification are written in any formal language.