Delay-Tolerant Networking TCP Convergence Layer Protocol Version 4
draft-ietf-dtn-tcpclv4-23

Summary: Has a DISCUSS. Needs 3 more YES or NO OBJECTION positions to pass.

Benjamin Kaduk Discuss

Discuss (2020-09-30 for -21)
[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
<validation fails> and security policy disallows an unauthenticated <X>,
the entity SHALL terminate the session" is for security policy to be
able to say "yes, there's no <X>-ID and I'm fine with that (or
potentially even "the <X>-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.
Comment (2020-09-30 for -21)
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.

(Mirja Kühlewind) Discuss

Discuss (2020-02-20 for -18)
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.
Comment (2020-02-20 for -18)
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?

Magnus Westerlund (was No Objection, Discuss, Yes, Discuss, Yes) Yes

Deborah Brungard No Objection

Roman Danyliw No Objection

Comment (2020-02-19 for -18)
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

Martin Duke (was Discuss, No Objection) No Objection

Comment (2020-11-23)
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.

(Suresh Krishnan) (was Discuss) No Objection

Comment (2020-03-13 for -19)
Thanks for addressing my DISCUSS points.

Barry Leiba No Objection

Comment (2020-02-13 for -18)
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.

(Alexey Melnikov) No Objection

Comment (2020-02-20 for -18)
[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 <bemasc@google.com>:

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.

(Adam Roach) No Objection

Comment (2020-02-19 for -18)
No email
send info
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.

Martin Vigoureux No Objection

Éric Vyncke No Objection

Comment (2020-02-20 for -18)
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

Alissa Cooper No Record

Erik Kline No Record

Murray Kucherawy No Record

Warren Kumari No Record

Alvaro Retana No Record

Robert Wilton No Record