Subject: [Lwip] Benjamin Kaduk's No Objection on draft-ietf-lwig-tcp-constrained-node-networks-11: (with COMMENT)

From: Benjamin Kaduk via Datatracker <[email-masked]>
Date: Wed, 21 Oct 2020 15:48:56 -0700

Benjamin Kaduk has entered the following ballot position for
draft-ietf-lwig-tcp-constrained-node-networks-11: 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-lwig-tcp-constrained-node-networks/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Mostly just editorial nits, but please see the comment on Section 5.3.

Section 2

(I believe the existence of the RFC 8174 version of the BCP 14
boilerplate has already been noted.)

Section 3.2

   or devices with a pool of multiple send/receive buffers.  In the
   latter case, it is possible that buffers also be shared for other
   protocols.

nit: s/be/are/ (or any number of other minor tweaks)

   One key use case for the use of TCP in CNNs is a model where

nit: "use case for the use" is probably redundant: "use case for TCP in
CNNs" seems like it would work okay.

   middlebox (e.g. a firewall, NAT, etc.).  Figure 1 illustrates such
   scenario.  Note that the scenario is asymmetric, as the unconstrained

nit: "such a scenario".

Section 3.3

   o  Unidirectional transfers: An IoT device (e.g. a sensor) can send
      (repeatedly) updates to the other endpoint.  Not in every case
      there is a need for an application response back to the IoT
      device.

(editorial) I suggest "There is not always a need for an application
response back to the IoT device".

Section 4.1.1

   smaller than 1220 bytes (e.g. not larger than 1200 bytes).  Note that
   it is advised for TCP implementations to consume payload space
   instead of increasing datagram size when including IP or TCP options
   in an IP packet to be sent [RFC6691].  Therefore, the suggestion of

[my reading of RFC 6691 is that it was required to consume payload
space, but only recommended to account for this behavior when
advertising MSS.  I guess Erik covered this in his Discuss point already, though.]

Section 5.3

   The message and latency overhead that stems from using a sequence of
   short-lived connections could be reduced by TCP Fast Open (TFO)
   [RFC7413], which is an experimental TCP extension, at the expense of
   increased implementation complexity and increased TCP Control Block
   (TCB) size.  TFO allows data to be carried in SYN (and SYN-ACK)

We should probably make at least a passing mention of the TFO security
considerations here, possibly with some discussion of why they are less
consequential for certain CNNs than in general.  (Note that the security
considerations for TFO are not limited to just the risk of replay, and
that there are privacy considerations for the TFO cookie being used to
link together multiple TCP connections between the same endpoints.)

Section 10.1

RFC 3819 may not need to be listed as normative, given the nature of the
one place in which it is referenced.

Similarly, we don't say much about TCP-AP other than it exists, so RFC
5925 may not need to be normative either.

Section 10.2

RFC 6092 appears to not be referenced from anywhere?
idnits notes a couple other reference-related issues.

---

From: "Carles Gomez Montenegro" <[email-masked]>
Date: Fri, 30 Oct 2020 09:38:38 +0100

Hi Benjamin,

Thank you very much for your review!

We just submitted revision -12, which aims at addressing the comments
received from the IESG and related reviewers:
https://tools.ietf.org/html/draft-ietf-lwig-tcp-constrained-node-networks-12

> https://datatracker.ietf.org/doc/draft-ietf-lwig-tcp-constrained-node-networks/

Thanks. In fact, since the document does not use normative language, we 
removed Section 2 in the last document revision.

> nit: s/be/are/ (or any number of other minor tweaks)

Done.

> CNNs" seems like it would work okay.

Done, thanks.

>    scenario.  Note that the scenario is asymmetric, as the unconstrained

Done.

> response back to the IoT device".

Done.

> advertising MSS.  I guess Erik covered this in his Discuss point already,

As per a subsequent discussion on the tcpm mailing list, we updated the
second paragraph of current Section 3.1.1 is as follows:

NEW:
   An IPv6 datagram size exceeding 1280 bytes can be avoided by setting
   the TCP MSS not larger than 1220 bytes.  Note that it is already a
   requirement that TCP implementations consume payload space instead of
   increasing datagram size when including IP or TCP options in an IP
   packet to be sent [RFC6691].  Therefore, it is not required to
   advertise an MSS smaller than 1220 bytes in order to accommodate TCP
   options.

> link together multiple TCP connections between the same endpoints.)

We made the following change:

OLD:
   The cookie needs to be refreshed (and obtained by the client) after a
   certain amount of time.  Nevertheless, TFO is more efficient than
   frequently opening new TCP connections with the traditional three-way
   handshake, as long as the cookie can be reused in subsequent
   connections.

NEW:
   The cookie needs to be refreshed (and obtained by the client) after a
   certain amount of time.  While a given cookie is used for multiple
   connections between the same two endpoints, the latter may become
   vulnerable to privacy threats.  In addition, a valid cookie may be
   stolen from a compromised host and may be used to perform SYN flood
   attacks, as well as amplified reflection attacks to victim hosts (see
   Section 5 of RFC 7413).  Nevertheless, TFO is more efficient than
   frequently opening new TCP connections with the traditional three-way
   handshake, as long as the cookie can be reused in subsequent
   connections.

> 5925 may not need to be normative either.

Done!

> RFC 6092 appears to not be referenced from anywhere?

We removed the reference (it was used in some older version of the draft).

> idnits notes a couple other reference-related issues.

We believe that we cleared those as well in -12.

Thanks,

Carles (on behalf of the authors)