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

[Carles Gomez Montenegro <[e-mail]>]

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

Please find below our inline responses:

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

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

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

Done.

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

Done, thanks.

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

Done.

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

Done.

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

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.

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

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.

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

Done!

> Section 10.2
>
> 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)