[dtn] Martin Duke's Discuss on draft-ietf-dtn-tcpclv4-22: (with DISCUSS and COMMENT)

[Martin Duke via Datatracker <[e-mail]>]

Martin Duke has entered the following ballot position for
draft-ietf-dtn-tcpclv4-22: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-dtn-tcpclv4/



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


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