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

[Brian Sipos <[e-mail]>]

Martin,
My responses are in-line below with prefix "BS1".

On Sat, 2020-11-07 at 16:41 -0800, Martin Duke via Datatracker wrote:
> Martin Duke has entered the following ballot position for
> draft-ietf-dtn-tcpclv4-22: Discuss
> 
> 
> ---------------------------------------------------------------------
> -
> 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.
> 
BS1: This phrasing is a bit unclear because the statement applies to
the transfer itself. Instead of "a transmitting node" it should be "a
node transmitting a transfer" so the subject of the statement becomes
the outgoing transfer.

> 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?
> 
BS1: There are requirements about how a CLA interacts with its
overlaying BPA, and this requirement applies to what will be indicated
to the BPA about the formerly-in-progress transfer. Section 3.1
explains that CLA--BPA interface.

> Can you list some reasons why an endpoint would choose to close
> uncleanly? Some
> motivation might provide helpful context.
> 
BS1: The motivation here is that there are some reasons why the CLA
will know that it's about to lose connectivity and send a positive
indication of "I'm about to go away and cannot finish a transfer (in
either direction)" instead of waiting (potentially a long time) for a
CLA timeout or a TCP timeout. For example, a low battery starting into
a power saving mode and stopping a data link. This is as opposed to a
clean termination, which is not time-critical and more of a "I don't
want to start any more transfers, so don't attempt any new ones."

> 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.
> 
BS1: I can add a top-level requirement that closing a TCP connection
always means using a FIN. 

> - 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?
> 
BS1: Some of these requirements may be trying to overspecify behavior
and just get confusing. There is always the potential for the TCP
connection to close for some other reason outside the CLA's control.
Maybe a better set of requirements is to mention that a peer MAY close
the connection before a transfer is finished, and that a closed
connection before receiving the final XFER_ACK SHALL be treated as a
failed transfer (even outside of an unclean termination, because at
that point there is no possibility of ever receving that final ACK).

> 
> ---------------------------------------------------------------------
> -
> 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.
> 
BS1: as mentioned above, I will add a requirement that FIN is the
correct method.

> 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.
> 
BS1: This had been discussed in the WG somewhat and this is a carry-
over from the behavior of the TCPCLv3.
The current requirements on the actie entity are to start at the
highest supported version and on the passive entity are to begin
TLS/session negotiation on *any* acceptable TCPCL version, which
assumes that a later version will be more acceptable to an arbitrary
passive entity.
Adding a "supported versions set" to the Contact Header is possible,
but there needs to be WG discussion on whether this is a worthwile late
addition.

> 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?
> 
BS1: There is a bit of gray area when the TLS handshake is involved,
because it can either succeed or fail but after the handshake it is
possible to send TCPCL messages regardless of handshake success. I
suppose that if the TLS stack fails within the TLS handshake that there
will be a TLS-level message indicating this fact and the TCPCL-level
message is redundant. Using the SESS_TERM regardless of whether the TLS
stack rejected the handshake or the CLA rejected the peer certificate
guarantees that there is some over-the-wire indication of what went
wrong (as opposed to the connection just being closed after a seemingly
valid TLS handshake).

> 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.
> 
BS1: This may be a phrasing issue, maybe instead:
   Either during or immediately after the TLS handshake if the active 
   entity resolved a DNS name (of the passive entity) in order to 
   initiate the TCP connection, the active
   entity SHALL authenticate that DNS name using any DNS-ID of the peer
   certificate.

> 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?
> 
BS1: This is an artifact, it should be clarified as:
    After the initial exchange of a Contact Header and any TLS 
    handshake exchanges, ...

> 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.
> 
BS1: This is a vestigal behavior and needs to be rephrased to remove
that parenthetical.

> 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.
> 
BS1: There had been earlier WG discussion about a standardized CLA--BPA
interface and nomenclature, but the CLA capabilities are incredibly
link-layer dependent and not at all consistent, especially ways in
which a transfer can fail (some link layers are even unidirectional and
don't provide any feedback at all to the CLA).
This could be discussed in the WG to see if the consensus has evolved
in any way in the meanwhile.