Subject: [dtn] Erik Kline's No Objection on draft-ietf-dtn-tcpclv4-23: (with COMMENT)

From: Erik Kline via Datatracker <[email-masked]>
Date: Wed, 02 Dec 2020 22:34:27 -0800

Erik Kline has entered the following ballot position for
draft-ietf-dtn-tcpclv4-23: No Objection

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/

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

---

From: Benjamin Kaduk <[email-masked]>
Date: Thu, 3 Dec 2020 14:35:51 -0800

This is an attractive idea, but seems like it would be quite messy in
practice -- it is (I assume) a goal to retain compatibility with older
TCPCL versions and negotiate the older one if needed, so even if you can
get away with trying TLS first, you still have to have a fall back to
plaintext; that, in turn, eliminates much of the security benefit of always
trying TLS.  What you end up with (AFAICT) ends up having the same
security properties as the current scheme, where you can have local policy
to always require CAN_TLS to be set, but otherwise you end up in a case
where you allow non-TLS connections based solely on unauthenticated traffic
on the wire (that is subject to tampering).

It's also tempting to define the "dtn" ALPN value, but then you have to
specify error handling for when you do the contact header exchange and
agree to start TLS, but then don't negotiate the "dtn" ALPN.  It just adds
another way to fail, and doesn't provide much value since the context of
the conact header already gives a strong indication of what you intend to
speak.

-Ben

---

From: Brian Sipos <[email-masked]>
Date: Fri, 4 Dec 2020 14:05:56 +0000

Erik,
Thank you for the feedback. My comments are inline below with prefix
[BS1].

On Wed, 2020-12-02 at 22:34 -0800, Erik Kline via Datatracker wrote:
> Please refer to 
> https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fiesg%2Fstatement%2Fdiscuss-criteria.html&amp;data=04%7C01%7Cbsipos%40rkf-eng.com%7Ca4e2d2be41214ba8ef0a08d897557c38%7C4ed8b15b911f42bc8524d89148858535%7C1%7C0%7C637425740708242082%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=lnUG8dPA4OP2x6jGMrE8tbW25w756ZAge06q7QHrZJc%3D&amp;reserved=0
>  https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-ietf-dtn-tcpclv4%2F&amp;data=04%7C01%7Cbsipos%40rkf-eng.com%7Ca4e2d2be41214ba8ef0a08d897557c38%7C4ed8b15b911f42bc8524d89148858535%7C1%7C0%7C637425740708242082%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=Y%2BvuJGYxkkevXdW9YdewwB23OFu2nUaO52Dc%2BAaAE7Q%3D&amp;reserved=0
> 
> 
> 
[BS1] The intent of the contact header is to provide some backward
compatibility and version negotiation. As Ben also mentioned, because
there is no higher-level protocol negotiation, ALPN would not gain any
benefit to this use by TCPCL.

>   in order to maintain NAT binding state.
[BS1] This negotiation behavior is a carry-over from TCPCLv3 and as you
mentioned can be used by either side to disable keepalive. Technically,
because a receiver doesn't do anything with KEEPALIVE messages, an
entity could still send KEEPALIVE if they absolutely needed to for
local firewall/NAT purposes. The current requirements are about when to
send a KEEPALIVE but don't strictly prohibit sending if not negotiated.
In that situation the idle timeout logic just wouldn't apply, which is
really what the negotiated keepalive interval is for: to know when to
expect to see KEEPALIVE and when to terminate if not seen.

> * "entity MAY attempt use" -> "entity MAY attempt to use"
[BS1] I'm going to fix these typos.